On 01/08/2026 10:25, Chris M. Thomasson wrote:
On 7/30/2026 7:44 PM, Chris M. Thomasson wrote:
On 7/30/2026 7:43 PM, Dan Cross wrote:
In article <114h1v7$2b0po$2@dont-email.me>,Afait uintptr_t can be set to the NULL and any pointer? Then compared?
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 7/30/2026 2:00 PM, Lawrence DrCOOliveiro wrote:
On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:
... the value of a pointer is the location that it points at. It's >>>>>>> value is never a number.
In C, its value is never *directly compatible* with a number.
Well, uintptr_t?
That's a type, not a value.
I think, humm... uintptr_t can be set to a function pointer as well?
You are not making sense here.
Any pointer (object pointer or function pointer) can be converted to any integer type.-a Whether or not the resulting integer value can be
converted back to the same pointer is implementation dependent, as is
the way the conversions are done.
But /if/ any void* pointer can be converted to an integer type without
loss of information, then uintptr_t and intptr_t are unsigned and signed types that can be used for the task.
-a They may or may not be able to
represent function pointers.-a In practice, on most systems, uintptr_t
works for any data or function pointer.-a But you have to explicitly
convert pointers to the uintptr_t integer type.
Can void* always hold a function pointer? I think not.
On Sun, 2 Aug 2026 14:37:20 -0700, Chris M. Thomasson wrote:
Can void* always hold a function pointer? I think not.
Even on architectures with separate instruction/data spaces, I would
say it is reasonable to require that void* can indeed hold a function pointer.
This is because you are likely to need a pointer to some environment
context for the function to execute in anyway, so the function pointer wonrCOt point directly to the code, but to a descriptor that contains
the pointer to the code.
On 8/2/2026 2:14 PM, David Brown wrote:
On 01/08/2026 10:25, Chris M. Thomasson wrote:
On 7/30/2026 7:44 PM, Chris M. Thomasson wrote:
On 7/30/2026 7:43 PM, Dan Cross wrote:
In article <114h1v7$2b0po$2@dont-email.me>,Afait uintptr_t can be set to the NULL and any pointer? Then compared?
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 7/30/2026 2:00 PM, Lawrence DrCOOliveiro wrote:
On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:
... the value of a pointer is the location that it points at. It's >>>>>>>> value is never a number.
In C, its value is never *directly compatible* with a number.
Well, uintptr_t?
That's a type, not a value.
I think, humm... uintptr_t can be set to a function pointer as well?
You are not making sense here.
Any pointer (object pointer or function pointer) can be converted to
any integer type.-a Whether or not the resulting integer value can be
converted back to the same pointer is implementation dependent, as is
the way the conversions are done.
uintptr_t can help us here. They are very useful.
But /if/ any void* pointer can be converted to an integer type without
loss of information, then uintptr_t and intptr_t are unsigned and
signed types that can be used for the task.
right.
-a They may or may not be able to represent function pointers.-a In
practice, on most systems, uintptr_t works for any data or function
pointer.-a But you have to explicitly convert pointers to the uintptr_t
integer type.
Can void* always hold a function pointer? I think not. So, that means
that uintptr_t cannot always hold a function pointer... Right?
However, uintptr_t can always hold a void*
On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:
... the value of a pointer is the location that it points at. It's
value is never a number.
In C, its value is never *directly compatible* with a number.
On 8/2/2026 2:14 PM, David Brown wrote:
On 01/08/2026 10:25, Chris M. Thomasson wrote:
On 7/30/2026 7:44 PM, Chris M. Thomasson wrote:
On 7/30/2026 7:43 PM, Dan Cross wrote:
In article <114h1v7$2b0po$2@dont-email.me>,Afait uintptr_t can be set to the NULL and any pointer? Then compared?
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 7/30/2026 2:00 PM, Lawrence DrCOOliveiro wrote:
On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:
... the value of a pointer is the location that it points at. It's >>>>>>>> value is never a number.
In C, its value is never *directly compatible* with a number.
Well, uintptr_t?
That's a type, not a value.
I think, humm... uintptr_t can be set to a function pointer as well?
You are not making sense here.
Any pointer (object pointer or function pointer) can be converted to
any integer type.-a Whether or not the resulting integer value can be
converted back to the same pointer is implementation dependent, as is
the way the conversions are done.
uintptr_t can help us here. They are very useful.
But /if/ any void* pointer can be converted to an integer type without
loss of information, then uintptr_t and intptr_t are unsigned and
signed types that can be used for the task.
right.
-a They may or may not be able to represent function pointers.-a In
practice, on most systems, uintptr_t works for any data or function
pointer.-a But you have to explicitly convert pointers to the uintptr_t
integer type.
Can void* always hold a function pointer? I think not. So, that means
that uintptr_t cannot always hold a function pointer... Right?
However, uintptr_t can always hold a void*
On 02/08/2026 23:37, Chris M. Thomasson wrote:
On 8/2/2026 2:14 PM, David Brown wrote:
On 01/08/2026 10:25, Chris M. Thomasson wrote:
On 7/30/2026 7:44 PM, Chris M. Thomasson wrote:
On 7/30/2026 7:43 PM, Dan Cross wrote:I think, humm... uintptr_t can be set to a function pointer as well?
In article <114h1v7$2b0po$2@dont-email.me>,Afait uintptr_t can be set to the NULL and any pointer? Then compared? >>>>
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 7/30/2026 2:00 PM, Lawrence DrCOOliveiro wrote:
On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:
... the value of a pointer is the location that it points at. It's >>>>>>>>> value is never a number.
In C, its value is never *directly compatible* with a number.
Well, uintptr_t?
That's a type, not a value.
You are not making sense here.
Any pointer (object pointer or function pointer) can be converted to
any integer type.-a Whether or not the resulting integer value can be
converted back to the same pointer is implementation dependent, as is
the way the conversions are done.
uintptr_t can help us here. They are very useful.
Yes, uintptr_t is the type you want to use if you need to handle an
object pointer as an integer.-a Use it for two reasons.
First, if the implementation does not support an integer type big enough
to hold a void*, then the type "uintptr_t" will not exist in <stdint.h>.
-aI don't know of any such platforms, but if one is made, then a hard compile-time error is far better than hidden problems.
Secondly, assuming the type exists, it is the ideal size for the job.
So always use "const uintptr_t address = (uintptr_t) pointer;", rather
than using "unsigned long" or other guessed type that will be
appropriate on some targets and not others.
But /if/ any void* pointer can be converted to an integer type
without loss of information, then uintptr_t and intptr_t are unsigned
and signed types that can be used for the task.
right.
-a They may or may not be able to represent function pointers.-a In
practice, on most systems, uintptr_t works for any data or function
pointer.-a But you have to explicitly convert pointers to the
uintptr_t integer type.
Can void* always hold a function pointer? I think not. So, that means
that uintptr_t cannot always hold a function pointer... Right?
However, uintptr_t can always hold a void*
That is all correct (if uintptr_t exists, of course).
On most targets, function pointers are the same size as void* pointers.
But there are exceptions, with some small microcontrollers and DSPs
having different kinds of pointers with different sizes, depending on
the memory space involved.-a I have yet to see a situation where there
was any reason for storing a function address in a "void*" rather than a more appropriate typedef, such as :
-a-a-a-atypedef void (*FVoid)(void);
Function pointers can safely be converted to other function pointer
types and back again, as long as you have converted to the correct type before calling the function.-a You have no such guarantees with void* or uintptr_t for function pointers.
(You might occasionally need to convert a function pointer to a specific sized integer type on very low-level code, such as setting up interrupt vector tables - but that is all highly non-portable code.)
There have been experimental systems designed with wider pointers for
data and functions, where the pointers might not fit in any integer type because they contain information about the range of memory section, or security or access control information.-a And there are systems (either
very old, quite niche DSPs, or some microcontrollers) where pointers to different types of data can have different sizes or contain additional address space, memory bank, or byte offset information.-a Generally speaking, don't convert pointer types to integers unless you actually
need to.
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void*
pointers. But there are exceptions, with some small microcontrollers
and DSPs having different kinds of pointers with different sizes,
depending on the memory space involved.-a I have yet to see a situation
where there was any reason for storing a function address in a "void*"
rather than a more appropriate typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void*
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void*
pointers. But there are exceptions, with some small microcontrollers
and DSPs having different kinds of pointers with different sizes,
depending on the memory space involved.-a I have yet to see a
situation where there was any reason for storing a function address
in a "void*" rather than a more appropriate typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void*
As I say, I have yet to see a situation where using void* for function pointers was more appropriate than using a function pointer type.-a If
the OS system calls or standard OS libraries makes it a requirement that function pointers are converted to or from void* for some calls, then of course you need to follow those requirements - it's the people who
designed the interfaces that made questionable design choices.
On 03/08/2026 6:28 PM, David Brown wrote:
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void*
pointers. But there are exceptions, with some small microcontrollers
and DSPs having different kinds of pointers with different sizes,
depending on the memory space involved.-a I have yet to see a
situation where there was any reason for storing a function address
in a "void*" rather than a more appropriate typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void*
As I say, I have yet to see a situation where using void* for function
pointers was more appropriate than using a function pointer type.-a If
the OS system calls or standard OS libraries makes it a requirement
that function pointers are converted to or from void* for some calls,
then of course you need to follow those requirements - it's the people
who designed the interfaces that made questionable design choices.
Nope, you're wrong.-a You're dead wrong.-a The world isn't built on C,
even though here in comp.lang.c we like to pretend it is.
Several language environments allow function generation on the fly,
these functions need to be garbage collected.-a Common Lisp is an
example, therefore comp.lang.lisp is added to this discussion.
I've also added comp.theory so Mild Shock can comment.
You will have to go out of your way to make a computer architecture incompatible with garbage collected and heap allocated binary code,
something I've been told SBCL does internally [1] to create an archi-
tecture that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
and when you do that, I'll just claim you're making a /malicious
computer architecture/ and refuse to use it.
[1] I've not looked at the code, but told the garbage collector can
and will at least move the code around, if not collect it.
First, if the implementation does not support an integer type big
enough to hold a void*, then the type "uintptr_t" will not exist in <stdint.h>. I don't know of any such platforms, but if one is made,
then a hard compile-time error is far better than hidden problems.
Secondly, assuming the type exists, it is the ideal size for the job.
So always use "const uintptr_t address = (uintptr_t) pointer;", rather
than using "unsigned long" or other guessed type that will be
appropriate on some targets and not others.
dlsym requires that pointer-to-function is compatible with a void*
David Brown <david.brown@hesbynett.no> writes:
[...]
First, if the implementation does not support an integer type big
enough to hold a void*, then the type "uintptr_t" will not exist in
<stdint.h>. I don't know of any such platforms, but if one is made,
then a hard compile-time error is far better than hidden problems.
Secondly, assuming the type exists, it is the ideal size for the job.
Almost certainly, but that's not guaranteed by the standard.
The requirement is that converting a void* to [u]intptr_t and back
again yields a result that compares equal to the original pointer.
A conforming implementation could have 32-bit pointers and 64-bit [u]intptr_t, even of 32-bit integer types are available. I can't
think of a good reason for an implementation to do that.
So always use "const uintptr_t address = (uintptr_t) pointer;", rather
than using "unsigned long" or other guessed type that will be
appropriate on some targets and not others.
But first think carefully whether storing pointer values in integer
objects is really an appropriate thing to do. Sometimes it is,
but I've seen code that did so needlessly and incorrectly.
Let pointers be pointers (unless there's a specific reason not to).
On 03/08/2026 6:28 PM, A respected comp.lang.c poster wrote:
Nope, you're wrong. You're dead wrong. The world isn't built on C,
even though here in comp.lang.c we like to pretend it is.
On 03/08/2026 13:23, Johann 'Myrkraverk' Oskarsson wrote:
Would you /please/ stop adding bunches of random newsgroups to posts?
You are making a mess of many newsgroups here, filling them with drivel
of no interest to the regulars in the groups.-a Regulars in
comp.lang.lisp care about Lisp, not C.-a Regulars in comp.theory, I
presume, care about the theory of computation - not C or Lisp.
Usenet groups are not controlled or governed, and no one can stop you
making the posts you make.-a But be very clear on this - your behaviour
is seriously anti-social, rude, and counter-productive.-a A discussion community, such as a Usenet group, "belongs" to the people that follow
the group and post there regularly.-a Filling a group with cross-posts
that inevitably fall off-topic is nothing short of vandalism.-a I am
going to make the assumption that your bad habits here are because you genuinely believe the cross-posting to be a good idea and you simply
don't understand the consequences, but I sincerely hope that you reconsider.-a So I will answer your C points below.-a But you have already alienated several of the C experts in this group - failing to follow the style and standards of a community means you will not get the
information or discussions you came here for.
If you want to post here on the C language - that would be great, and
it's always need to see new people joining in.
On 03/08/2026 6:28 PM, David Brown wrote:
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void*
pointers. But there are exceptions, with some small
microcontrollers and DSPs having different kinds of pointers with
different sizes, depending on the memory space involved.-a I have
yet to see a situation where there was any reason for storing a
function address in a "void*" rather than a more appropriate
typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void*
As I say, I have yet to see a situation where using void* for
function pointers was more appropriate than using a function pointer
type.-a If the OS system calls or standard OS libraries makes it a
requirement that function pointers are converted to or from void* for
some calls, then of course you need to follow those requirements -
it's the people who designed the interfaces that made questionable
design choices.
Nope, you're wrong.-a You're dead wrong.-a The world isn't built on C,
even though here in comp.lang.c we like to pretend it is.
You can't jump into a group for a week and pretend to speak for it.
People in comp.lang.c do not think the world is built on C - they /know/ that a great deal of key software is built in and on C, they /know/ that
a great of cross-language interfaces, APIs, ABIs, and libraries are
build around C and C concepts.-a They know that discussions about C, such
as the thread here, are about C.-a They know that Lisp is not C, nor is C the only programming language, and they know things are done differently
in different languages.
In C, function pointers and object pointers are different concepts and
good design keeps those different concepts separate.-a Most, but not all, targets for C have a single simple flat memory model in which addresses
of data and addresses of code have the same underlying implementation in
the hardware - that does not mean it is a good idea to mix these types
of pointer at the C language level - especially as there is rarely
anything to be gained by it.
Several language environments allow function generation on the fly,
these functions need to be garbage collected.-a Common Lisp is an
example, therefore comp.lang.lisp is added to this discussion.
Several languages are not C, and are not relevant to C.-a There are
hundreds of real-world programming languages that are not C, and which
may or may not allow function generation on the fly - none of them, including Lisp, are relevant here, nor are any of their newsgroups appropriate.
And there is no relation between having a common format for data and
code pointers, and having support for generating functions at run-time. Python allows run-time function generation, but has no concept of either function pointers or data pointers.-a C++ allows run-time function generation, but has a clear distinction between data pointers and
function pointers (with the same model there as C).
I've also added comp.theory so Mild Shock can comment.
Please don't.-a This is not about computation theory.-a If someone else wants to join in a C discussion in a C group, talking about C, then
that's fine.
You will have to go out of your way to make a computer architecture
incompatible with garbage collected and heap allocated binary code,
something I've been told SBCL does internally [1] to create an archi-
tecture that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
and when you do that, I'll just claim you're making a /malicious
computer architecture/ and refuse to use it.
[1] I've not looked at the code, but told the garbage collector can
and will at least move the code around, if not collect it.
C does not use garbage collection.-a C does not use "heap allocated
binary code".-a Other languages may do, and may have different ways of addressing or identifying the code.-a We are talking here about C.
And in C, even if function pointers have the same size as void* on most platforms, the two classes of pointers are entirely distinct.-a You need
to go out of your way (via explicit casts) to mix them in some way, and
that is very rarely a useful thing to do.
I've also added comp.theory so Mild Shock can comment.
that has different
* sizeof ( void * ), and
* sizeof ( void (*)( void ) ),
On 03/08/2026 6:28 PM, David Brown wrote:
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void*
pointers. But there are exceptions, with some small microcontrollers
and DSPs having different kinds of pointers with different sizes,
depending on the memory space involved.-a I have yet to see a
situation where there was any reason for storing a function address
in a "void*" rather than a more appropriate typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void*
As I say, I have yet to see a situation where using void* for function
pointers was more appropriate than using a function pointer type.-a If
the OS system calls or standard OS libraries makes it a requirement
that function pointers are converted to or from void* for some calls,
then of course you need to follow those requirements - it's the people
who designed the interfaces that made questionable design choices.
Nope, you're wrong.-a You're dead wrong.-a The world isn't built on C,
even though here in comp.lang.c we like to pretend it is.
Several language environments allow function generation on the fly,
these functions need to be garbage collected.-a Common Lisp is an
example, therefore comp.lang.lisp is added to this discussion.
I've also added comp.theory so Mild Shock can comment.
You will have to go out of your way to make a computer architecture incompatible with garbage collected and heap allocated binary code,
something I've been told SBCL does internally [1] to create an archi-
tecture that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
and when you do that, I'll just claim you're making a /malicious
computer architecture/ and refuse to use it.
[1] I've not looked at the code, but told the garbage collector can
and will at least move the code around, if not collect it.
Hi,
I've also added comp.theory so Mild Shock can comment.
that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
Could indicate a data RAM and code ROM model.
Which has then the advantage of:
Modern operating systems like Windows 11
enforce strict Data Execution Prevention (DEP)
(or NX/XD bit security features) to prevent
malicious programs from injecting and executing
code inside data-only memory regions. https://root-nation.com/en/soft-en/lifehacks/en-dep-windows-all-about/
I adopted data RAM and code ROM model for
pi-WAM from Hack, which has the same separation:
Slide 58, Hack Computer https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view
But my motivation was not Johnny Depp prevention.
Rather the caching of GPUs. Because WGSL
allows storage annotations read_write and
read. I use read_write for the data RAM
of my Hack VM variant, and read for the
code ROM of my Hack VM variant. You can
see that here, its open source:
@group(0) @binding(0) var<storage, read> code: array<i32>;
@group(0) @binding(1) var<storage, read_write> state: array<i32>;
11.4 Giga Lips with a Budget Laptop https://github.com/Jean-Luc-Picard-2021/gigabudget
Hope this Helps!
Bye
Johann 'Myrkraverk' Oskarsson schrieb:
On 03/08/2026 6:28 PM, David Brown wrote:
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void*
pointers. But there are exceptions, with some small
microcontrollers and DSPs having different kinds of pointers with
different sizes, depending on the memory space involved.-a I have
yet to see a situation where there was any reason for storing a
function address in a "void*" rather than a more appropriate
typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void*
As I say, I have yet to see a situation where using void* for
function pointers was more appropriate than using a function pointer
type.-a If the OS system calls or standard OS libraries makes it a
requirement that function pointers are converted to or from void* for
some calls, then of course you need to follow those requirements -
it's the people who designed the interfaces that made questionable
design choices.
Nope, you're wrong.-a You're dead wrong.-a The world isn't built on C,
even though here in comp.lang.c we like to pretend it is.
Several language environments allow function generation on the fly,
these functions need to be garbage collected.-a Common Lisp is an
example, therefore comp.lang.lisp is added to this discussion.
I've also added comp.theory so Mild Shock can comment.
You will have to go out of your way to make a computer architecture
incompatible with garbage collected and heap allocated binary code,
something I've been told SBCL does internally [1] to create an archi-
tecture that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
and when you do that, I'll just claim you're making a /malicious
computer architecture/ and refuse to use it.
[1] I've not looked at the code, but told the garbage collector can
and will at least move the code around, if not collect it.
On 03/08/2026 8:01 PM, David Brown wrote:
On 03/08/2026 13:23, Johann 'Myrkraverk' Oskarsson wrote:
Would you /please/ stop adding bunches of random newsgroups to posts?
You are making a mess of many newsgroups here, filling them with
drivel of no interest to the regulars in the groups.-a Regulars in
comp.lang.lisp care about Lisp, not C.-a Regulars in comp.theory, I
presume, care about the theory of computation - not C or Lisp.
No.-a The reason being, assholes like Scott Lurndal owe me an apology.
There are more of them.-a When you get the "regulars" to behave like
normal human beings, I might too.
But that said, none of you know how to behave like regular humans,
so why should I bother to respect your "rules."
Jut add me to your killfile and be done with it.
On 03/08/2026 6:28 PM, David Brown wrote:
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void* pointers. >>> But there are exceptions, with some small microcontrollers and DSPs
having different kinds of pointers with different sizes, depending on >>> the memory space involved.-a I have yet to see a situation where there >>> was any reason for storing a function address in a "void*" rather than a >>> more appropriate typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void*
As I say, I have yet to see a situation where using void* for function pointers was more appropriate than using a function pointer type.-a If the OS system calls or standard OS libraries makes it a requirement that function pointers are converted to or from void* for some calls, then of course you need to follow those requirements - it's the people who designed the interfaces that made questionable design choices.
Nope, you're wrong. You're dead wrong. The world isn't built on C,
even though here in comp.lang.c we like to pretend it is.
Several language environments allow function generation on the fly,
these functions need to be garbage collected. Common Lisp is an
example, therefore comp.lang.lisp is added to this discussion.
I've also added comp.theory so Mild Shock can comment.
You will have to go out of your way to make a computer architecture incompatible with garbage collected and heap allocated binary code, something I've been told SBCL does internally [1] to create an archi- tecture that has different
* sizeof ( void * ), and
* sizeof ( void (*)( void ) ),
and when you do that, I'll just claim you're making a /malicious
computer architecture/ and refuse to use it.
[1] I've not looked at the code, but told the garbage collector can--
and will at least move the code around, if not collect it.
On Sun, 2 Aug 2026 14:37:20 -0700, Chris M. Thomasson wrote:
Can void* always hold a function pointer? I think not.
Even on architectures with separate instruction/data spaces, I would
say it is reasonable to require that void* can indeed hold a function pointer.
This is because you are likely to need a pointer to some environment
context for the function to execute in anyway, so the function pointer wonrCOt point directly to the code, but to a descriptor that contains
the pointer to the code.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:
... the value of a pointer is the location that it points at. It's
value is never a number.
In C, its value is never *directly compatible* with a number.
Lawrence, you've never explained what you mean here by "directly
compatible". Will you please do so?
On 03/08/2026 09:16, David Brown wrote:Shit, off the top of my head I cannot remember if that function is
On 02/08/2026 23:37, Chris M. Thomasson wrote:
On 8/2/2026 2:14 PM, David Brown wrote:
On 01/08/2026 10:25, Chris M. Thomasson wrote:
On 7/30/2026 7:44 PM, Chris M. Thomasson wrote:
On 7/30/2026 7:43 PM, Dan Cross wrote:
In article <114h1v7$2b0po$2@dont-email.me>,Afait uintptr_t can be set to the NULL and any pointer? Then
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 7/30/2026 2:00 PM, Lawrence DrCOOliveiro wrote:
On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:Well, uintptr_t?
... the value of a pointer is the location that it points at. >>>>>>>>>> It's
value is never a number.
In C, its value is never *directly compatible* with a number. >>>>>>>>
That's a type, not a value.
compared?
I think, humm... uintptr_t can be set to a function pointer as well?
You are not making sense here.
Any pointer (object pointer or function pointer) can be converted to
any integer type.-a Whether or not the resulting integer value can be >>>> converted back to the same pointer is implementation dependent, as
is the way the conversions are done.
uintptr_t can help us here. They are very useful.
Yes, uintptr_t is the type you want to use if you need to handle an
object pointer as an integer.-a Use it for two reasons.
First, if the implementation does not support an integer type big
enough to hold a void*, then the type "uintptr_t" will not exist in
<stdint.h>. -a-aI don't know of any such platforms, but if one is made,
then a hard compile-time error is far better than hidden problems.
Secondly, assuming the type exists, it is the ideal size for the job.
So always use "const uintptr_t address = (uintptr_t) pointer;", rather
than using "unsigned long" or other guessed type that will be
appropriate on some targets and not others.
But /if/ any void* pointer can be converted to an integer type
without loss of information, then uintptr_t and intptr_t are
unsigned and signed types that can be used for the task.
right.
-a They may or may not be able to represent function pointers.-a In
practice, on most systems, uintptr_t works for any data or function
pointer.-a But you have to explicitly convert pointers to the
uintptr_t integer type.
Can void* always hold a function pointer? I think not. So, that means
that uintptr_t cannot always hold a function pointer... Right?
However, uintptr_t can always hold a void*
That is all correct (if uintptr_t exists, of course).
On most targets, function pointers are the same size as void*
pointers. But there are exceptions, with some small microcontrollers
and DSPs having different kinds of pointers with different sizes,
depending on the memory space involved.-a I have yet to see a situation
where there was any reason for storing a function address in a "void*"
rather than a more appropriate typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void*
On 03/08/2026 8:01 PM, David Brown wrote:[...]
On 03/08/2026 13:23, Johann 'Myrkraverk' Oskarsson wrote:
Would you /please/ stop adding bunches of random newsgroups to posts?
You are making a mess of many newsgroups here, filling them with
drivel of no interest to the regulars in the groups.-a Regulars in
comp.lang.lisp care about Lisp, not C.-a Regulars in comp.theory, I
presume, care about the theory of computation - not C or Lisp.
No.-a The reason being, assholes like Scott Lurndal owe me an apology.
David Brown <david.brown@hesbynett.no> writes:
[...]
First, if the implementation does not support an integer type big
enough to hold a void*, then the type "uintptr_t" will not exist in
<stdint.h>. I don't know of any such platforms, but if one is made,
then a hard compile-time error is far better than hidden problems.
Secondly, assuming the type exists, it is the ideal size for the job.
Almost certainly, but that's not guaranteed by the standard.
The requirement is that converting a void* to [u]intptr_t and back
again yields a result that compares equal to the original pointer.
A conforming implementation could have 32-bit pointers and 64-bit [u]intptr_t, even of 32-bit integer types are available. I can't
think of a good reason for an implementation to do that.
So always use "const uintptr_t address = (uintptr_t) pointer;", rather
than using "unsigned long" or other guessed type that will be
appropriate on some targets and not others.
But first think carefully whether storing pointer values in integer
objects is really an appropriate thing to do. Sometimes it is,
but I've seen code that did so needlessly and incorrectly.
Let pointers be pointers (unless there's a specific reason not to).
[...]
On 8/2/2026 3:51 PM, Lawrence DrCOOliveiro wrote:
On Sun, 2 Aug 2026 14:37:20 -0700, Chris M. Thomasson wrote:
Can void* always hold a function pointer? I think not.
Even on architectures with separate instruction/data spaces, I
would say it is reasonable to require that void* can indeed hold a
function pointer.
This is because you are likely to need a pointer to some
environment context for the function to execute in anyway, so the
function pointer wonrCOt point directly to the code, but to a
descriptor that contains the pointer to the code.
Well, a struct with function pointers in it, yes. We can hold a
pointer to said struct in a uintptr_t. That's fine.
On 7/30/2026 7:44 PM, Chris M. Thomasson wrote:
On 7/30/2026 7:43 PM, Dan Cross wrote:
In article <114h1v7$2b0po$2@dont-email.me>,Afait uintptr_t can be set to the NULL and any pointer? Then compared?
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 7/30/2026 2:00 PM, Lawrence DrCOOliveiro wrote:
On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:
... the value of a pointer is the location that it points at. It's >>>>>> value is never a number.
In C, its value is never *directly compatible* with a number.
Well, uintptr_t?
That's a type, not a value.
I think, humm... uintptr_t can be set to a function pointer as well?
Shit, off the top of my head I cannot remember if that function is
POSIX.
On 01/08/2026 10:25, Chris M. Thomasson wrote:
On 7/30/2026 7:44 PM, Chris M. Thomasson wrote:
On 7/30/2026 7:43 PM, Dan Cross wrote:
In article <114h1v7$2b0po$2@dont-email.me>,Afait uintptr_t can be set to the NULL and any pointer? Then compared?
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 7/30/2026 2:00 PM, Lawrence DrCOOliveiro wrote:
On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:
... the value of a pointer is the location that it points at. It's >>>>>>> value is never a number.
In C, its value is never *directly compatible* with a number.
Well, uintptr_t?
That's a type, not a value.
I think, humm... uintptr_t can be set to a function pointer as well?
If uintptr_t is supported, then any pointer value can be converted to
that type, The result of the conversion is implementation-defined
integer value. It does not mean that the pointer's value was an integer before the conversion - it's the conversion itself that produced the
integer. And conversely, it also does not mean that the integer's value after the conversion was the pointer's value before the conversion.
On Mon, 3 Aug 2026 12:03:27 -0700, Chris M. Thomasson wrote:
On 8/2/2026 3:51 PM, Lawrence DrCOOliveiro wrote:
On Sun, 2 Aug 2026 14:37:20 -0700, Chris M. Thomasson wrote:
Can void* always hold a function pointer? I think not.
Even on architectures with separate instruction/data spaces, I
would say it is reasonable to require that void* can indeed hold a
function pointer.
This is because you are likely to need a pointer to some
environment context for the function to execute in anyway, so the
function pointer wonrCOt point directly to the code, but to a
descriptor that contains the pointer to the code.
Well, a struct with function pointers in it, yes. We can hold a
pointer to said struct in a uintptr_t. That's fine.
In case it wasnrCOt clear, I was talking about how the underlying implementation has to handle function pointers,
not how C programmers
might use them in an application program.
All function pointer types are convertible to all (other) function
pointer types without loss of information -- but not to or from
integer or object pointer types.
The standard doesn't say that function pointers can be converted to
object pointer types or vice versa -- no does it say that they can't.
My conclusion is that the behavior of such a conversion is undefined
by omission. (There was a lengthy and unproductive discussion about
this here a few years ago.) IMHO it would be better for the standard
to say that such conversions yield implementation-defined results.
On 03/08/2026 6:28 PM, David Brown wrote:
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void*
pointers. But there are exceptions, with some small microcontrollers
and DSPs having different kinds of pointers with different sizes,
depending on the memory space involved.-a I have yet to see a
situation where there was any reason for storing a function address
in a "void*" rather than a more appropriate typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void*
As I say, I have yet to see a situation where using void* for function
pointers was more appropriate than using a function pointer type.-a If
the OS system calls or standard OS libraries makes it a requirement
that function pointers are converted to or from void* for some calls,
then of course you need to follow those requirements - it's the people
who designed the interfaces that made questionable design choices.
Nope, you're wrong.-a You're dead wrong.-a The world isn't built on C,
even though here in comp.lang.c we like to pretend it is.
Several language environments allow function generation on the fly,
these functions need to be garbage collected.-a Common Lisp is an
example, therefore comp.lang.lisp is added to this discussion.
I've also added comp.theory so Mild Shock can comment.
You will have to go out of your way to make a computer architecture incompatible with garbage collected and heap allocated binary code,
something I've been told SBCL does internally [1] to create an archi-
tecture that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
and when you do that, I'll just claim you're making a /malicious
computer architecture/ and refuse to use it.
[1] I've not looked at the code, but told the garbage collector can
and will at least move the code around, if not collect it.
Hi,
How it started:
The Applied Pi Calculus: Mobile Values,
New Names, and Secure Communication
Mart|!n Abadi et al. - Google Brain
https://arxiv.org/abs/1609.03003
How its going:
Dynamic Control Flow in
Large-Scale Machine Learning
Mart|!n Abadi et al. - Google Brain https://research.google/pubs/dynamic-control-flow-in-large-scale-machine-learning/
Have Fun!
Bye
Johann 'Myrkraverk' Oskarsson schrieb:
On 03/08/2026 6:28 PM, David Brown wrote:
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void*
pointers. But there are exceptions, with some small
microcontrollers and DSPs having different kinds of pointers with
different sizes, depending on the memory space involved.-a I have
yet to see a situation where there was any reason for storing a
function address in a "void*" rather than a more appropriate
typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void*
As I say, I have yet to see a situation where using void* for
function pointers was more appropriate than using a function pointer
type.-a If the OS system calls or standard OS libraries makes it a
requirement that function pointers are converted to or from void* for
some calls, then of course you need to follow those requirements -
it's the people who designed the interfaces that made questionable
design choices.
Nope, you're wrong.-a You're dead wrong.-a The world isn't built on C,
even though here in comp.lang.c we like to pretend it is.
Several language environments allow function generation on the fly,
these functions need to be garbage collected.-a Common Lisp is an
example, therefore comp.lang.lisp is added to this discussion.
I've also added comp.theory so Mild Shock can comment.
You will have to go out of your way to make a computer architecture
incompatible with garbage collected and heap allocated binary code,
something I've been told SBCL does internally [1] to create an archi-
tecture that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
and when you do that, I'll just claim you're making a /malicious
computer architecture/ and refuse to use it.
[1] I've not looked at the code, but told the garbage collector can
and will at least move the code around, if not collect it.
On Mon, 3 Aug 2026 13:04:50 -0700, Chris M. Thomasson wrote:
Shit, off the top of my head I cannot remember if that function is
POSIX.
This is usually mentioned in the man pages.
Ar an tri|| l|i de m|! L||nasa, scr|!obh Johann Oskarsson:
> On 03/08/2026 6:28 PM, David Brown wrote:
> > On 03/08/2026 11:41, Richard Harnden wrote:
> >> On 03/08/2026 09:16, David Brown wrote:
> >
> >>> On most targets, function pointers are the same size as void* pointers.
> >>> But there are exceptions, with some small microcontrollers and DSPs
> >>> having different kinds of pointers with different sizes, depending on
> >>> the memory space involved.-a I have yet to see a situation where there
> >>> was any reason for storing a function address in a "void*" rather than a
> >>> more appropriate typedef, such as :
> >>>
> >>> -a-a-a-a-atypedef void (*FVoid)(void);
> >>
> >> dlsym requires that pointer-to-function is compatible with a void*
> >
> > As I say, I have yet to see a situation where using void* for function
> > pointers was more appropriate than using a function pointer type.-a If the
> > OS system calls or standard OS libraries makes it a requirement that
> > function pointers are converted to or from void* for some calls, then of
> > course you need to follow those requirements - it's the people who
> > designed the interfaces that made questionable design choices.
>
> Nope, you're wrong. You're dead wrong. The world isn't built on C,
> even though here in comp.lang.c we like to pretend it is.
The habit when I read comp.lang.c it was to assert that standard C was all that
was worth discussing (yes, yes, itrCOs phrased as standard C is on topic, everything else isnrCOt; but there wasnrCOt the activity in the architecture-specific groups for them to be helpful when I was reading it). This is even more ridiculous; almost all the C infrastructure out there relies
on what is undefined behaviour by the letter of the standard. But itrCOs still C,
and itrCOs worth understanding and worth writing.
Oh well, thank you the autoconf maintainers, thank you the cmake maintainers, shame about the difficulty with cross-compiling.
> Several language environments allow function generation on the fly,
> these functions need to be garbage collected. Common Lisp is an
> example, therefore comp.lang.lisp is added to this discussion.
>
> I've also added comp.theory so Mild Shock can comment.
>
> You will have to go out of your way to make a computer architecture
> incompatible with garbage collected and heap allocated binary code,
> something I've been told SBCL does internally [1] to create an archi-
> tecture that has different
I havenrCOt gone into the weeds of the GNU Emacs native-compiled function implementation, but it has to be doing something similar. The functions are not
in the data segment, theyrCOre not in BSS, theyrCOre not on the stack; that leaves
the heap.
> * sizeof ( void * ), and
> * sizeof ( void (*)( void ) ),
>
> and when you do that, I'll just claim you're making a /malicious
> computer architecture/ and refuse to use it.
Note that GCC on AMD64 produces function pointers that are one-byte aligned, which to me is a similar philosophy. There cannot be any performance advantage
to that.
> [1] I've not looked at the code, but told the garbage collector can
> and will at least move the code around, if not collect it.
And not to mention the operating system interfaces.-a I'll name mmap(),
and Win32 has its equivalent, and while I'm not sure, OpenVMS might be different too.
All of them return the equivalent of void *.-a So what are the program-
mers of the JVM, CLR, and other virtual machines to do?-a They'll have
to rely on this "undefined behaviour."
On 04/08/2026 17:22, Johann 'Myrkraverk' Oskarsson wrote:
And not to mention the operating system interfaces.-a I'll name mmap(),
and Win32 has its equivalent, and while I'm not sure, OpenVMS might be
different too.
All of them return the equivalent of void *.-a So what are the program-
mers of the JVM, CLR, and other virtual machines to do?-a They'll have
to rely on this "undefined behaviour."
I suspect its because I'm not a genius like you, but ...
malloc(3) also returns a void* and that is perfectly well defined, is
used everywhere and never caused anybody any problems.
... it seems to me you are, as usual, talking bollocks.
Yes, I remember that. I believe I came across a FAQ, probably comp.os. msdos.programmer, that said because comp.lang.c was full of standard
thumping trolls, a lot of regular programming, even Win32 got discussed there. Yes, I'll quote.
So my take on it, is that the standard thumping trolls in comp.lang.c
were already a problem in the 90s. They just didn't know it, didn't
care, and nobody challenged them about it. Until now.
On 04/08/2026 2:51 AM, Aidan Kehoe wrote:
Hello Aidan,
We haven't spoken for a long time, and I guess we're moving in different social circles now.
You will find it amusing that my patch to the FreeBSD kernel, the one
that kind of tunes the TCP/IP stack, is presumably used by Whatsapp as
well.
At least, that's the rumor I heard; I wouldn't know the truth as I don't work for Whatsapp. I thought only 5ch and Netflix had sites large
enough to make use of it. Well, sites both large enough, and hosted on FreeBSD.
I promised myself to look into it later, and if I'm right -- at least,
that my patch is still there and all -- I'll let you know.
It's always fun to know that whenever someone streams from Netflix, the TCP/IP patch I applied is being used; though I cannot say that it
streams through my code; it wasn't that kind of patch.
And I didn't, and don't work for Netflix either.
I hope you're also leaving trails of patches in various operating
systems that everyone on the planet, more or less, makes use of.
Ar an tri|| l|i de m|! L||nasa, scr|!obh Johann Oskarsson:
> On 03/08/2026 6:28 PM, David Brown wrote:
> > On 03/08/2026 11:41, Richard Harnden wrote:
> >> On 03/08/2026 09:16, David Brown wrote:
> >
> >>> On most targets, function pointers are the same size as void*
> >>> pointers. But there are exceptions, with some small
> >>> microcontrollers and DSPs having different kinds of pointers with
> >>> different sizes, depending on the memory space involved.-a I have
> >>> yet to see a situation where there was any reason for storing a
> >>> function address in a "void*" rather than a more appropriate
> >>> typedef, such as :
> >>>
> >>> -a-a-a-a-atypedef void (*FVoid)(void);
> >>
> >> dlsym requires that pointer-to-function is compatible with a void*
> >
> > As I say, I have yet to see a situation where using void* for
> > function pointers was more appropriate than using a function pointer
> > type.-a If the OS system calls or standard OS libraries makes it a
> > requirement that function pointers are converted to or from void*
> > for some calls, then of course you need to follow those requirements
> > - it's the people who designed the interfaces that made questionable
> > design choices.
>
> Nope, you're wrong. You're dead wrong. The world isn't built on C,
> even though here in comp.lang.c we like to pretend it is.
The habit when I read comp.lang.c it was to assert that standard C was
all that was worth discussing (yes, yes, itrCOs phrased as standard C is on
topic, everything else isnrCOt; but there wasnrCOt the activity in the architecture-specific groups for them to be helpful when I was reading it). This is even more ridiculous; almost all the C infrastructure out there relies on what is undefined behaviour by the letter of the
standard. But itrCOs still C, and itrCOs worth understanding and worth writing.
Yes, I remember that. I believe I came across a FAQ, probably comp.os. msdos.programmer, that said because comp.lang.c was full of standard thumping trolls, a lot of regular programming, even Win32 got discussed there. Yes, I'll quote.
> Why does the newsgroup seem to be so C-oriented sometimes?
> There are two reasons. First, comp.lang.c and
> comp.lang.pascal have evolved in different
> directions. Comp.lang.pascal has split into discussions
> about individual Pascal compilers. comp.lang.pascal.borland
> welcomes discussion specific to Turbo Pascal, and the other
> new groups likewise. Turbo Pascal programmers tend to find
> DOS questions welcomed in comp.lang.pascal.borland, so that
> comp.os.msdos.programmer gets less of the "DOS in Turbo
> Pascal" traffic. On the other hand, comp.lang.c has stayed
> closer to talking only about the C language, and
> vendor-specific or operating-system-specific questions are
> not welcome. This tends to push questions about disks, DOS
> file structure, video, the keyboard, TSRs, etc. to
> comp.os.msdos.programmer even when those programs are
> written in C.
So my take on it, is that the standard thumping trolls in comp.lang.c were already a problem in the 90s. They just didn't know it, didn't care, and nobody challenged them about it. Until now.
I am challenging their rule. And they can whine, and they can bluster,
but nobody cares about their mistaken sense of prestige and power.
They claim my cross posting is annoying. As far as I'm aware, I'm
basically screaming into the void with my cross posts, because there
isn't enough traffic in the other groups to warrant complaints about it.
Oh well, thank you the autoconf maintainers, thank you the cmake maintainers, shame about the difficulty with cross-compiling.
On that subject, I have to agree. I've largely given up on both for my own projects. The problems with these tools isn't when they work, it's when they don't. It can be a nightmare to get to the first build on a platform where the build system doesn't work.
I currently believe both tools make porting to a /different enough platform/ basically impossible. And that's based on hard earned experience.
> Several language environments allow function generation on the fly,
> these functions need to be garbage collected. Common Lisp is an
> example, therefore comp.lang.lisp is added to this discussion.
>
> I've also added comp.theory so Mild Shock can comment.
>
> You will have to go out of your way to make a computer architecture
> incompatible with garbage collected and heap allocated binary code,
> something I've been told SBCL does internally [1] to create an archi-
> tecture that has different
I havenrCOt gone into the weeds of the GNU Emacs native-compiled function implementation, but it has to be doing something similar. The functions are not in the data segment, theyrCOre not in BSS, theyrCOre not on the stack; that leaves the heap.
And not to mention the operating system interfaces. I'll name mmap(),
and Win32 has its equivalent, and while I'm not sure, OpenVMS might be different too.
All of them return the equivalent of void *. So what are the programmers of the JVM, CLR, and other virtual machines to do? They'll have to rely on
this "undefined behaviour."
> * sizeof ( void * ), and
> * sizeof ( void (*)( void ) ),
>
> and when you do that, I'll just claim you're making a /malicious
> computer architecture/ and refuse to use it.
Note that GCC on AMD64 produces function pointers that are one-byte aligned, which to me is a similar philosophy. There cannot be any performance advantage to that.
Can you please expand on that? I'm not sure what you mean, and I hope
it doesn't create function pointers at strictly odd addresses, because that's what it sounds like to me.
On 2026-08-04, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
So my take on it, is that the standard thumping trolls in comp.lang.c
were already a problem in the 90s. They just didn't know it, didn't
care, and nobody challenged them about it. Until now.
On the contrary, standard-thumping in comp.lang.c has been regularly challenged for decades by numerous visitors; everyone who tried it so
far bounced off, and came down with an unpleasant bump. :)
Hi,
Well there are two viewpoint, the "client"
of the GPU, which is the CPU, and the "server"
of the GPU, which is the command processor
queue of the GPU device. So basically as
a CPU client I can write the memory area,
that is later mapped to my GPU code storage.
And this way have a compiler, even written
in Prolog, that compiles pi-WAM to my Hack VM,
that can then be then deployed to GPU.
You could also try the same with a Tiny
LISP VM. And a grown up LISP to act as
the compiler. Would be a similar exercise.
Have Fun!
Bye
Mild Shock schrieb:
Hi,
I've also added comp.theory so Mild Shock can comment.
that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
Could indicate a data RAM and code ROM model.
Which has then the advantage of:
Modern operating systems like Windows 11
enforce strict Data Execution Prevention (DEP)
(or NX/XD bit security features) to prevent
malicious programs from injecting and executing
code inside data-only memory regions.
https://root-nation.com/en/soft-en/lifehacks/en-dep-windows-all-about/
I adopted data RAM and code ROM model for
pi-WAM from Hack, which has the same separation:
Slide 58, Hack Computer
https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view
But my motivation was not Johnny Depp prevention.
Rather the caching of GPUs. Because WGSL
allows storage annotations read_write and
read. I use read_write for the data RAM
of my Hack VM variant, and read for the
code ROM of my Hack VM variant. You can
see that here, its open source:
@group(0) @binding(0) var<storage, read> code: array<i32>;
@group(0) @binding(1) var<storage, read_write> state: array<i32>;
11.4 Giga Lips with a Budget Laptop
https://github.com/Jean-Luc-Picard-2021/gigabudget
Hope this Helps!
Bye
Johann 'Myrkraverk' Oskarsson schrieb:
On 03/08/2026 6:28 PM, David Brown wrote:
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void*
pointers. But there are exceptions, with some small
microcontrollers and DSPs having different kinds of pointers with >>>>>> different sizes, depending on the memory space involved.-a I have >>>>>> yet to see a situation where there was any reason for storing a
function address in a "void*" rather than a more appropriate
typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void*
As I say, I have yet to see a situation where using void* for
function pointers was more appropriate than using a function pointer
type.-a If the OS system calls or standard OS libraries makes it a
requirement that function pointers are converted to or from void*
for some calls, then of course you need to follow those requirements
- it's the people who designed the interfaces that made questionable
design choices.
Nope, you're wrong.-a You're dead wrong.-a The world isn't built on C,
even though here in comp.lang.c we like to pretend it is.
Several language environments allow function generation on the fly,
these functions need to be garbage collected.-a Common Lisp is an
example, therefore comp.lang.lisp is added to this discussion.
I've also added comp.theory so Mild Shock can comment.
You will have to go out of your way to make a computer architecture
incompatible with garbage collected and heap allocated binary code,
something I've been told SBCL does internally [1] to create an archi-
tecture that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
and when you do that, I'll just claim you're making a /malicious
computer architecture/ and refuse to use it.
[1] I've not looked at the code, but told the garbage collector can
and will at least move the code around, if not collect it.
Hi,
How it started, NVIDIA being cool:
NCCL provides routines such as all-gather,
all-reduce, broadcast, reduce, reduce-scatter,
and point-to-point send and receive. These
routines are optimized to achieve high
bandwidth and low latency over PCIe,
NVIDIA NVLinkrao, and other high-speed
interconnects within a node and over
NVIDIA networking across nodes.
https://developer.nvidia.com/nccl
How its going, vLLM trying to be cool:
[RFC]: Native Weight Syncing APIs
However, there are no standardized methods for
performing online weight syncing. Open source projects
like SkyRL, VeRL, and TRL need to include their
own implementations of the weight syncing
infrastructure, leading to added complexity
for developers seeking to adopt vLLM as their
inference server for post-training workloads. https://github.com/vllm-project/vllm/issues/31848
How much Workers are enough? I guess it depends
on I/O parallelism, CPU Memory parallelism, CPU
Processing parallelism, and now also
GPU Memory parallelism and GPU Processing
parallelism, and last but least you might have
a couple DMAs sitting here and there,
or even invoking a sort of RDMA. Quite amazing!
Bye
Mild Shock schrieb:
Hi,
Well there are two viewpoint, the "client"
of the GPU, which is the CPU, and the "server"
of the GPU, which is the command processor
queue of the GPU device. So basically as
a CPU client I can write the memory area,
that is later mapped to my GPU code storage.
And this way have a compiler, even written
in Prolog, that compiles pi-WAM to my Hack VM,
that can then be then deployed to GPU.
You could also try the same with a Tiny
LISP VM. And a grown up LISP to act as
the compiler. Would be a similar exercise.
Have Fun!
Bye
Mild Shock schrieb:
Hi,
I've also added comp.theory so Mild Shock can comment.
that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
Could indicate a data RAM and code ROM model.
Which has then the advantage of:
Modern operating systems like Windows 11
enforce strict Data Execution Prevention (DEP)
(or NX/XD bit security features) to prevent
malicious programs from injecting and executing
code inside data-only memory regions.
https://root-nation.com/en/soft-en/lifehacks/en-dep-windows-all-about/
I adopted data RAM and code ROM model for
pi-WAM from Hack, which has the same separation:
Slide 58, Hack Computer
https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view
But my motivation was not Johnny Depp prevention.
Rather the caching of GPUs. Because WGSL
allows storage annotations read_write and
read. I use read_write for the data RAM
of my Hack VM variant, and read for the
code ROM of my Hack VM variant. You can
see that here, its open source:
@group(0) @binding(0) var<storage, read> code: array<i32>;
@group(0) @binding(1) var<storage, read_write> state: array<i32>;
11.4 Giga Lips with a Budget Laptop
https://github.com/Jean-Luc-Picard-2021/gigabudget
Hope this Helps!
Bye
Johann 'Myrkraverk' Oskarsson schrieb:
On 03/08/2026 6:28 PM, David Brown wrote:
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void*
pointers. But there are exceptions, with some small
microcontrollers and DSPs having different kinds of pointers with >>>>>>> different sizes, depending on the memory space involved.-a I have >>>>>>> yet to see a situation where there was any reason for storing a >>>>>>> function address in a "void*" rather than a more appropriate
typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void* >>>>>>
As I say, I have yet to see a situation where using void* for
function pointers was more appropriate than using a function
pointer type.-a If the OS system calls or standard OS libraries
makes it a requirement that function pointers are converted to or
from void* for some calls, then of course you need to follow those
requirements - it's the people who designed the interfaces that
made questionable design choices.
Nope, you're wrong.-a You're dead wrong.-a The world isn't built on C, >>>> even though here in comp.lang.c we like to pretend it is.
Several language environments allow function generation on the fly,
these functions need to be garbage collected.-a Common Lisp is an
example, therefore comp.lang.lisp is added to this discussion.
I've also added comp.theory so Mild Shock can comment.
You will have to go out of your way to make a computer architecture
incompatible with garbage collected and heap allocated binary code,
something I've been told SBCL does internally [1] to create an archi-
tecture that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
and when you do that, I'll just claim you're making a /malicious
computer architecture/ and refuse to use it.
[1] I've not looked at the code, but told the garbage collector can
and will at least move the code around, if not collect it.
Hi,
Recently there was a paper somebody mentioning
a flit doing a ACK or NACK, to express
backpressure inside a Network on a Chip.
But what is a flit? It seems multiple
flits can be used to create the message
passing in one directiob before the
ACK or NACK in the other direction?
"The growing need for performance from
computing systems drove the industry into
the multi-core and many-core arena. In this
setup, the execution of a kernel (a program)
is split across multiple processors and the
computation happens in parallel
Flits represent logical units of information,
while phits represent the physical domain,
that is, phits represent the number of bits
that can be transferred in parallel in a
single cycle. Consider the Cray T3D. It has
an interconnection network which uses
flit level message flow control wherein each
flit is composed of eight 16-bit phits. That
means its flit size is 128bits and phit size
is 16bits. Also consider the IBM SP2 switch.
It also uses the flit level message flow
control, but its flit size is equal to its
phit size, which is set to 8 bits." https://en.wikipedia.org/wiki/Flit_(computer_networking)#Example
Well my idea how this is realized in silicon
is rather foggy, I mean even the Hack project
from Nand 2 Tetris, does not show some gate level
schemes for flits and phits.
Could be an interesting extension. But somehow
the image of flits and phits inspired my channel
objects here below. But I am afraid they are fire
and forget, no ACK and NACK:
-C-WAM Contest: 1 Million Packets with Prolog https://medium.com/2989/ec3e91551773
Its amazing that a max_size(1) buffer
can beat an unbounded buffer!
LoL
Bye
Mild Shock schrieb:
Hi,
How it started, NVIDIA being cool:
NCCL provides routines such as all-gather,
all-reduce, broadcast, reduce, reduce-scatter,
and point-to-point send and receive. These
routines are optimized to achieve high
bandwidth and low latency over PCIe,
NVIDIA NVLinkrao, and other high-speed
interconnects within a node and over
NVIDIA networking across nodes.
https://developer.nvidia.com/nccl
How its going, vLLM trying to be cool:
[RFC]: Native Weight Syncing APIs
However, there are no standardized methods for
performing online weight syncing. Open source projects
like SkyRL, VeRL, and TRL need to include their
own implementations of the weight syncing
infrastructure, leading to added complexity
for developers seeking to adopt vLLM as their
inference server for post-training workloads.
https://github.com/vllm-project/vllm/issues/31848
How much Workers are enough? I guess it depends
on I/O parallelism, CPU Memory parallelism, CPU
Processing parallelism, and now also
GPU Memory parallelism and GPU Processing
parallelism, and last but least you might have
a couple DMAs sitting here and there,
or even invoking a sort of RDMA. Quite amazing!
Bye
Mild Shock schrieb:
Hi,
Well there are two viewpoint, the "client"
of the GPU, which is the CPU, and the "server"
of the GPU, which is the command processor
queue of the GPU device. So basically as
a CPU client I can write the memory area,
that is later mapped to my GPU code storage.
And this way have a compiler, even written
in Prolog, that compiles pi-WAM to my Hack VM,
that can then be then deployed to GPU.
You could also try the same with a Tiny
LISP VM. And a grown up LISP to act as
the compiler. Would be a similar exercise.
Have Fun!
Bye
Mild Shock schrieb:
Hi,
I've also added comp.theory so Mild Shock can comment.
that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
Could indicate a data RAM and code ROM model.
Which has then the advantage of:
Modern operating systems like Windows 11
enforce strict Data Execution Prevention (DEP)
(or NX/XD bit security features) to prevent
malicious programs from injecting and executing
code inside data-only memory regions.
https://root-nation.com/en/soft-en/lifehacks/en-dep-windows-all-about/ >>>>
I adopted data RAM and code ROM model for
pi-WAM from Hack, which has the same separation:
Slide 58, Hack Computer
https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view >>>>
But my motivation was not Johnny Depp prevention.
Rather the caching of GPUs. Because WGSL
allows storage annotations read_write and
read. I use read_write for the data RAM
of my Hack VM variant, and read for the
code ROM of my Hack VM variant. You can
see that here, its open source:
@group(0) @binding(0) var<storage, read> code: array<i32>;
@group(0) @binding(1) var<storage, read_write> state: array<i32>;
11.4 Giga Lips with a Budget Laptop
https://github.com/Jean-Luc-Picard-2021/gigabudget
Hope this Helps!
Bye
Johann 'Myrkraverk' Oskarsson schrieb:
On 03/08/2026 6:28 PM, David Brown wrote:
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void* >>>>>>>> pointers. But there are exceptions, with some small
microcontrollers and DSPs having different kinds of pointers
with different sizes, depending on the memory space involved.-a I >>>>>>>> have yet to see a situation where there was any reason for
storing a function address in a "void*" rather than a more
appropriate typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void* >>>>>>>
As I say, I have yet to see a situation where using void* for
function pointers was more appropriate than using a function
pointer type.-a If the OS system calls or standard OS libraries
makes it a requirement that function pointers are converted to or >>>>>> from void* for some calls, then of course you need to follow those >>>>>> requirements - it's the people who designed the interfaces that
made questionable design choices.
Nope, you're wrong.-a You're dead wrong.-a The world isn't built on C, >>>>> even though here in comp.lang.c we like to pretend it is.
Several language environments allow function generation on the fly,
these functions need to be garbage collected.-a Common Lisp is an
example, therefore comp.lang.lisp is added to this discussion.
I've also added comp.theory so Mild Shock can comment.
You will have to go out of your way to make a computer architecture
incompatible with garbage collected and heap allocated binary code,
something I've been told SBCL does internally [1] to create an archi- >>>>> tecture that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
and when you do that, I'll just claim you're making a /malicious
computer architecture/ and refuse to use it.
[1] I've not looked at the code, but told the garbage collector can
and will at least move the code around, if not collect it.
Hi,
Recently there was a paper somebody mentioning
a flit doing a ACK or NACK, to express
backpressure inside a Network on a Chip.
But what is a flit? It seems multiple
flits can be used to create the message
passing in one directiob before the
ACK or NACK in the other direction?
"The growing need for performance from
computing systems drove the industry into
the multi-core and many-core arena. In this
setup, the execution of a kernel (a program)
is split across multiple processors and the
computation happens in parallel
Flits represent logical units of information,
while phits represent the physical domain,
that is, phits represent the number of bits
that can be transferred in parallel in a
single cycle. Consider the Cray T3D. It has
an interconnection network which uses
flit level message flow control wherein each
flit is composed of eight 16-bit phits. That
means its flit size is 128bits and phit size
is 16bits. Also consider the IBM SP2 switch.
It also uses the flit level message flow
control, but its flit size is equal to its
phit size, which is set to 8 bits." https://en.wikipedia.org/wiki/Flit_(computer_networking)#Example
Well my idea how this is realized in silicon
is rather foggy, I mean even the Hack project
from Nand 2 Tetris, does not show some gate level
schemes for flits and phits.
Could be an interesting extension. But somehow
the image of flits and phits inspired my channel
objects here below. But I am afraid they are fire
and forget, no ACK and NACK:
-C-WAM Contest: 1 Million Packets with Prolog https://medium.com/2989/ec3e91551773
Its amazing that a max_size(1) buffer
can beat an unbounded buffer!
LoL
Bye
Mild Shock schrieb:
Hi,
How it started, NVIDIA being cool:
NCCL provides routines such as all-gather,
all-reduce, broadcast, reduce, reduce-scatter,
and point-to-point send and receive. These
routines are optimized to achieve high
bandwidth and low latency over PCIe,
NVIDIA NVLinkrao, and other high-speed
interconnects within a node and over
NVIDIA networking across nodes.
https://developer.nvidia.com/nccl
How its going, vLLM trying to be cool:
[RFC]: Native Weight Syncing APIs
However, there are no standardized methods for
performing online weight syncing. Open source projects
like SkyRL, VeRL, and TRL need to include their
own implementations of the weight syncing
infrastructure, leading to added complexity
for developers seeking to adopt vLLM as their
inference server for post-training workloads.
https://github.com/vllm-project/vllm/issues/31848
How much Workers are enough? I guess it depends
on I/O parallelism, CPU Memory parallelism, CPU
Processing parallelism, and now also
GPU Memory parallelism and GPU Processing
parallelism, and last but least you might have
a couple DMAs sitting here and there,
or even invoking a sort of RDMA. Quite amazing!
Bye
Mild Shock schrieb:
Hi,
Well there are two viewpoint, the "client"
of the GPU, which is the CPU, and the "server"
of the GPU, which is the command processor
queue of the GPU device. So basically as
a CPU client I can write the memory area,
that is later mapped to my GPU code storage.
And this way have a compiler, even written
in Prolog, that compiles pi-WAM to my Hack VM,
that can then be then deployed to GPU.
You could also try the same with a Tiny
LISP VM. And a grown up LISP to act as
the compiler. Would be a similar exercise.
Have Fun!
Bye
Mild Shock schrieb:
Hi,
I've also added comp.theory so Mild Shock can comment.
that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
Could indicate a data RAM and code ROM model.
Which has then the advantage of:
Modern operating systems like Windows 11
enforce strict Data Execution Prevention (DEP)
(or NX/XD bit security features) to prevent
malicious programs from injecting and executing
code inside data-only memory regions.
https://root-nation.com/en/soft-en/lifehacks/en-dep-windows-all-about/ >>>>
I adopted data RAM and code ROM model for
pi-WAM from Hack, which has the same separation:
Slide 58, Hack Computer
https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view >>>>
But my motivation was not Johnny Depp prevention.
Rather the caching of GPUs. Because WGSL
allows storage annotations read_write and
read. I use read_write for the data RAM
of my Hack VM variant, and read for the
code ROM of my Hack VM variant. You can
see that here, its open source:
@group(0) @binding(0) var<storage, read> code: array<i32>;
@group(0) @binding(1) var<storage, read_write> state: array<i32>;
11.4 Giga Lips with a Budget Laptop
https://github.com/Jean-Luc-Picard-2021/gigabudget
Hope this Helps!
Bye
Johann 'Myrkraverk' Oskarsson schrieb:
On 03/08/2026 6:28 PM, David Brown wrote:
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void* >>>>>>>> pointers. But there are exceptions, with some small
microcontrollers and DSPs having different kinds of pointers
with different sizes, depending on the memory space involved.-a I >>>>>>>> have yet to see a situation where there was any reason for
storing a function address in a "void*" rather than a more
appropriate typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void* >>>>>>>
As I say, I have yet to see a situation where using void* for
function pointers was more appropriate than using a function
pointer type.-a If the OS system calls or standard OS libraries
makes it a requirement that function pointers are converted to or >>>>>> from void* for some calls, then of course you need to follow those >>>>>> requirements - it's the people who designed the interfaces that
made questionable design choices.
Nope, you're wrong.-a You're dead wrong.-a The world isn't built on C, >>>>> even though here in comp.lang.c we like to pretend it is.
Several language environments allow function generation on the fly,
these functions need to be garbage collected.-a Common Lisp is an
example, therefore comp.lang.lisp is added to this discussion.
I've also added comp.theory so Mild Shock can comment.
You will have to go out of your way to make a computer architecture
incompatible with garbage collected and heap allocated binary code,
something I've been told SBCL does internally [1] to create an archi- >>>>> tecture that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
and when you do that, I'll just claim you're making a /malicious
computer architecture/ and refuse to use it.
[1] I've not looked at the code, but told the garbage collector can
and will at least move the code around, if not collect it.
Hi,
Now I implemented some multiple producer
and multiple consumer channel objects for
WebGPU. The only API to integrate it user
facing into pi-WAM is this single predicate:
/**
-a* flit(C):
-a* The predicate succeeds in C with a new channel. The channel
-a* can be used from within GPU backed -C-WAM logical threads.
-a*/
The Mac Neo is a Budget Monster. While the
Ryzen AI Laptop cost around 1300.- CHF.
The Mac Neo was around 600.- CHF with all
extras. Here some performance results,
checking out whether channel objects scale,
when increasing their number to
communicate the same 1 millon packets:
Java performance:
AI Laptop-a-a-a Single-a-a-a Double
Ryzen-a-a-a 705.1-a-a-a 337.4
Neo-a-a-a 669.4-a-a-a 239.9
WebGPU performance:
AI Laptop-a-a-a Single-a-a-a Double
Ryzen-a-a-a 731.8-a-a-a 392.9
Neo-a-a-a 932.8-a-a-a 483.5
Cool! Java is also pretty cool, their
semaphore library is top notch. I couldn't
replicate the resulst with JavaScript yet,
seems their Atomics.wait() resp. Atomics.waitAsync()
is totally broken, using futex is mutex for
fools somehow. I also found some gremlins
attacking one of the GPUs. The Intel AI Laptop
fails the above experiment. Maybe its a driver
Vulkan versus OpenCL or something problem,
or the Lunar lake architecture is nonsense.
Bye
Mild Shock schrieb:
Hi,
Recently there was a paper somebody mentioning
a flit doing a ACK or NACK, to express
backpressure inside a Network on a Chip.
But what is a flit? It seems multiple
flits can be used to create the message
passing in one directiob before the
ACK or NACK in the other direction?
"The growing need for performance from
computing systems drove the industry into
the multi-core and many-core arena. In this
setup, the execution of a kernel (a program)
is split across multiple processors and the
computation happens in parallel
Flits represent logical units of information,
while phits represent the physical domain,
that is, phits represent the number of bits
that can be transferred in parallel in a
single cycle. Consider the Cray T3D. It has
an interconnection network which uses
flit level message flow control wherein each
flit is composed of eight 16-bit phits. That
means its flit size is 128bits and phit size
is 16bits. Also consider the IBM SP2 switch.
It also uses the flit level message flow
control, but its flit size is equal to its
phit size, which is set to 8 bits."
https://en.wikipedia.org/wiki/Flit_(computer_networking)#Example
Well my idea how this is realized in silicon
is rather foggy, I mean even the Hack project
from Nand 2 Tetris, does not show some gate level
schemes for flits and phits.
Could be an interesting extension. But somehow
the image of flits and phits inspired my channel
objects here below. But I am afraid they are fire
and forget, no ACK and NACK:
-C-WAM Contest: 1 Million Packets with Prolog
https://medium.com/2989/ec3e91551773
Its amazing that a max_size(1) buffer
can beat an unbounded buffer!
LoL
Bye
Mild Shock schrieb:
Hi,
How it started, NVIDIA being cool:
NCCL provides routines such as all-gather,
all-reduce, broadcast, reduce, reduce-scatter,
and point-to-point send and receive. These
routines are optimized to achieve high
bandwidth and low latency over PCIe,
NVIDIA NVLinkrao, and other high-speed
interconnects within a node and over
NVIDIA networking across nodes.
https://developer.nvidia.com/nccl
How its going, vLLM trying to be cool:
[RFC]: Native Weight Syncing APIs
However, there are no standardized methods for
performing online weight syncing. Open source projects
like SkyRL, VeRL, and TRL need to include their
own implementations of the weight syncing
infrastructure, leading to added complexity
for developers seeking to adopt vLLM as their
inference server for post-training workloads.
https://github.com/vllm-project/vllm/issues/31848
How much Workers are enough? I guess it depends
on I/O parallelism, CPU Memory parallelism, CPU
Processing parallelism, and now also
GPU Memory parallelism and GPU Processing
parallelism, and last but least you might have
a couple DMAs sitting here and there,
or even invoking a sort of RDMA. Quite amazing!
Bye
Mild Shock schrieb:
Hi,
Well there are two viewpoint, the "client"
of the GPU, which is the CPU, and the "server"
of the GPU, which is the command processor
queue of the GPU device. So basically as
a CPU client I can write the memory area,
that is later mapped to my GPU code storage.
And this way have a compiler, even written
in Prolog, that compiles pi-WAM to my Hack VM,
that can then be then deployed to GPU.
You could also try the same with a Tiny
LISP VM. And a grown up LISP to act as
the compiler. Would be a similar exercise.
Have Fun!
Bye
Mild Shock schrieb:
Hi,
I've also added comp.theory so Mild Shock can comment.
that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
Could indicate a data RAM and code ROM model.
Which has then the advantage of:
Modern operating systems like Windows 11
enforce strict Data Execution Prevention (DEP)
(or NX/XD bit security features) to prevent
malicious programs from injecting and executing
code inside data-only memory regions.
https://root-nation.com/en/soft-en/lifehacks/en-dep-windows-all-about/ >>>>>
I adopted data RAM and code ROM model for
pi-WAM from Hack, which has the same separation:
Slide 58, Hack Computer
https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view >>>>>
But my motivation was not Johnny Depp prevention.
Rather the caching of GPUs. Because WGSL
allows storage annotations read_write and
read. I use read_write for the data RAM
of my Hack VM variant, and read for the
code ROM of my Hack VM variant. You can
see that here, its open source:
@group(0) @binding(0) var<storage, read> code: array<i32>;
@group(0) @binding(1) var<storage, read_write> state: array<i32>;
11.4 Giga Lips with a Budget Laptop
https://github.com/Jean-Luc-Picard-2021/gigabudget
Hope this Helps!
Bye
Johann 'Myrkraverk' Oskarsson schrieb:
On 03/08/2026 6:28 PM, David Brown wrote:
On 03/08/2026 11:41, Richard Harnden wrote:
On 03/08/2026 09:16, David Brown wrote:
On most targets, function pointers are the same size as void* >>>>>>>>> pointers. But there are exceptions, with some small
microcontrollers and DSPs having different kinds of pointers >>>>>>>>> with different sizes, depending on the memory space involved. >>>>>>>>> I have yet to see a situation where there was any reason for >>>>>>>>> storing a function address in a "void*" rather than a more
appropriate typedef, such as :
-a-a-a-a-atypedef void (*FVoid)(void);
dlsym requires that pointer-to-function is compatible with a void* >>>>>>>>
As I say, I have yet to see a situation where using void* for
function pointers was more appropriate than using a function
pointer type.-a If the OS system calls or standard OS libraries >>>>>>> makes it a requirement that function pointers are converted to or >>>>>>> from void* for some calls, then of course you need to follow
those requirements - it's the people who designed the interfaces >>>>>>> that made questionable design choices.
Nope, you're wrong.-a You're dead wrong.-a The world isn't built on C, >>>>>> even though here in comp.lang.c we like to pretend it is.
Several language environments allow function generation on the fly, >>>>>> these functions need to be garbage collected.-a Common Lisp is an
example, therefore comp.lang.lisp is added to this discussion.
I've also added comp.theory so Mild Shock can comment.
You will have to go out of your way to make a computer architecture >>>>>> incompatible with garbage collected and heap allocated binary code, >>>>>> something I've been told SBCL does internally [1] to create an archi- >>>>>> tecture that has different
*-a sizeof ( void * ), and
*-a sizeof ( void (*)( void ) ),
and when you do that, I'll just claim you're making a /malicious
computer architecture/ and refuse to use it.
[1] I've not looked at the code, but told the garbage collector can >>>>>> and will at least move the code around, if not collect it.
Note that the requirement for all-bits-zero to be a valid
representation for zero in all integer types was added, without
much fanfare, in a technical corrigendum to C99, [...]
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 47:45:44 |
| Calls: | 1,100 |
| Files: | 1,339 |
| Messages: | 275,630 |