On 10/06/2021 16:16, Kaz Kylheku wrote:
> On 2021-06-10, Bart <bc@freeuk.com> wrote:

>> What would:
>>
>> print(A)
>>
>> mean when A could exist in half a dozen different namespaces?
>
> Print the value of variable A.
>

OK, that is your choice to restrict a language in some ways, and to have
it totally unrestricted in others.

Presumably the value of A could include a reference to a function? In
that case, how does that reference get into the variable, since here:

A = F

you'd have the same problem: F can only be a variable. But presumably
the F in F() /can/ be a function. Which allows you do:

F = F()

Again, your choice.

I like the convenience and flexibility of having everything in one
namespace, and you like the idea of /reusing the same identifiers/ for
different purposes within each scope.

Personally I don't have that much of a problem with thinking up unique
names within a scope, as even with case-insensitity and no extra
namespaces, there are 6 quadrillion possible names up to 10 letters, or
2 billion even within 6 letters (like the Fortran and Algol I used to use).

On 10/06/2021 15:55, David Brown wrote:
> On 10/06/2021 16:18, Bart wrote:
>> On 10/06/2021 14:30, David Brown wrote:
>>> On 10/06/2021 13:38, Bart wrote:

> In a hypothetical new language, you could easily have the function name
> referring to the function, not its address, and it could be in a
> separate namespace. "Printing" the function would not make sense. If
> you really wanted to show its address (rarely a useful thing to do), you
> could write "print(function_address(foo))", or something like that.

When I print a function in my latest language, it shows its name. I can
do that even with an indirect reference from a variable (a 'function
pointer' in C).

However, I presume you mean (see my response to Kaz) that:

F In an expression is not a function but a variable
F() Here is a function

Which allows you to do:

F = F()

I don't know you'd set (variable) F up to be a pointer to (function) F.

To me it sounds like a nightmare language.

>>> The only time separate namespaces can be a disadvantage is if you might
>>> want to use items from the different namespaces in the same context,
>>> /and/ it is likely that there would be a conflict of names, /and/ there
>>> is no other convenient way to resolve the ambiguity.  If you expect
>>> "print(A)", given a type, to print the type's name, then you could say
>>> the "print" function takes an object, not a type - and in the rare cases
>>> where you want to print a type's name, you write "print(typename(A))".
>>
>> So you need special syntax - 'typename', which cannot be a regular
>> function - to disambiguate. A kind of Hungarian notation.
>
> No, it would be a function which takes a type and returns its name.

That's not going to work. Don't forget there is more than one namespace.

A by itself is a /variable/. The /type/ A is in a separate namespace and
cannot be refered to directly without special syntax or context. I
assumes 'typename' was that special syntax or context where its argument
was looked up in the type namespace.

Now, A might be a variable that /refers to/ a named type that exists in
that special namespace, in which case the problem, like F above, shifts
to how you'd get the type A into the variable A.

> I
> see nothing special about that (even though you can't write such
> functions in C.) It would be silly to create a new modern language that
> does not have at least that level of introspection.

I demonstrated that level of introspection in the example from my
language. It's got nothing to do with extra namespaces.

However in my example, you can't use F for both a function and a
variable name in the same scope, and you can't use A for both a type and
a variable name in the same scope. That sounds entirely sensible to me.

Namespaces as you propose are just a can of worms.

> Look, we know you don't like people to use a variety of names - you'd
> really be happier if we stuck to an old Fortran-era convention of
> all-caps identifiers of no more than 6 letters.

No limit on length and not all-caps. You just don't need identifiers
that differ only in case.

> We know you don't like
> structured programming.

Where did you get that idea?

> You don't like macros

No.

> you don't like types

Not gratuitous ones that makes my life harder.

> you don't like generic programming

I get generic programming with my dynamic language. Doing it in static
languages makes those languages difficult and inefficient (eg. C++ and
Rust).

> you don't like object oriented
> programming

I can take it or leave it. I've part implemented OOP features in dynamic
code, and sometimes use them. But elsehwhere people go overboard with it.

, you don't like strong typing, you don't like anything
> popularised since the ZX Spectrum was at its peak.
>
> Basically, you want a cross between assembly and BASIC.

Rubbish. My two languages lie on this line:

ASM--C--M-----Q------------Python

> That's okay - you make whatever language suits you. Just don't expect
> anyone else to think you've got the perfect language, or that you can
> judge what features of a language would be practical or useful to others.

At least I have created languages, implemented them, and successfully
used them to write commercial software. Some characteristics of mine:

* Case-insensitive (like Fortran and Ada and the Algols)
* Algol68-style block syntax (like Algol68 and Ada and Lua)
* 1-based and N-based arrays (like Ada, Pascal, modern Fortran)
* No silly separate namespaces (like most languages)
* No textual macro system (like most languages)

So, none of this is unique to what I'm doing. It's just not fashionable.

I wouldn't like to use one of yours where you'd tie yourself up in knots
with elaborate type systems and namespaces.

On 2021-06-10, Bart <bc@freeuk.com> wrote:
> On 10/06/2021 16:16, Kaz Kylheku wrote:
>> On 2021-06-10, Bart <bc@freeuk.com> wrote:
>
>>> What would:
>>>
>>> print(A)
>>>
>>> mean when A could exist in half a dozen different namespaces?
>>
>> Print the value of variable A.
>>
>
> OK, that is your choice to restrict a language in some ways, and to have
> it totally unrestricted in others.
>
> Presumably the value of A could include a reference to a function? In
> that case, how does that reference get into the variable, since here:
>
> A = F

A = function F // insert syntactic sugar

A = &F; // C-like, with syntactic sugar.

The sugared version is already valid C, and C programs already do this,
even though it's not required.

In ANSI Lisp:

(let ((a (function f))
...)

Sugared with #'

(let ((a #'f))
...)

In code that does a lot of manipulation with higher order functions,
all the #' and funcall contributes to noise. ANSI CL has been often
criticized for that.

If you have a separate var/function namespace, then there is an abiguity
in calling. If F is both a variable and a function, how do you know
which one you are calling?

A = call F (args ...)
A = F(arsgs ...)

C has an existing sugar for this which is currently unnecessary, but has
been used in programs anyway, for clarity.

A = (*F)(args);

A = F(args)

Effectively C simulates two namespaces by the fact that if fun is a
function, &fun and fun are the same pointer, and also fun, *fun, **fun,
***fun, ***fun, .... are all the same.

There are some noteworthy situations in C++. In C++, the & operator
*must* be used for lifting a pointer to a static member function:

void (*pfun)(int) = &foo::fun; // cannot just be foo::fun

I can't remmeber what the rationale is; I can't think of a reason why
foo::fun shouldn't just work.

In C++ there is a feature called pointer-to-member for pointing to
non-static member functions. That must use not only explicit address
lifting, but explicit dereferencing. The operator for declaring
the pointer and for taking the address contain a class resolution
part, which indicates the namespace:

void (foo::*pmemb)(int) = &foo::fun;

pmemb must be used with an object because fun is non-static:

(obj.*pmemb)(42); // parens required like (*pfn)(42);

> I like the convenience and flexibility of having everything in one
> namespace, and you like the idea of /reusing the same identifiers/ for
> different purposes within each scope.

No, I don't. The different namespaces are in fact different scopes.
Nothing is reused in one scope; that is a logical impossibilty.

If ever in the same program you use the same identifier for two
different purposes in two differen places, you are supporting the idea
of multiple namespaces.

The only way to cling to a pure single namespace view is to insist that
there is only a global dictionary for all identifiers for the entire
program, so that once i is used somewhere, that name refers only to that
i and cannot be reused.

On 10/06/2021 17:56, Kaz Kylheku wrote:
> On 2021-06-10, Bart <bc@freeuk.com> wrote:

>> I like the convenience and flexibility of having everything in one
>> namespace, and you like the idea of /reusing the same identifiers/ for
>> different purposes within each scope.
>
> No, I don't. The different namespaces are in fact different scopes.
> Nothing is reused in one scope; that is a logical impossibilty.

Here, A is used for 3 purposes /in the same scope/:

{A:; struct A{}; int A;}

>
> If ever in the same program you use the same identifier for two
> different purposes in two differen places, you are supporting the idea
> of multiple namespaces.

Yes, namespaces created by an enclosing class, function** or module.

To access the public names from one of those from one place, you usually
name a qualifier (the name of the class, function or module), which must
itself exist in namespace visible from that location.

You can't use 'A' for different things at the same location. You either
need a qualifier, or you need to be in a scope where the particular A
you want can be used without a qualifier.

> The only way to cling to a pure single namespace view is to insist that
> there is only a global dictionary for all identifiers for the entire
> program, so that once i is used somewhere, that name refers only to that
> i and cannot be reused.

Nobody is talking about a single global namespace. As I said, each
module has its own namespace: each class has one; each function has one;
and even each program/library can have one.

I'm talking about the ridiculous idea that the collection of unique
identifiers visible as top-level names from any one location in source
code, should be split up into multiple namespaces, which will also allow
you to have multiple versions of any particular name.

(** Functions are not usually considered to be collections of things
like a class. But in my stuff, they can be used like that: you can
access names (not local variables but statics, types, enums etc) inside
a function, from outside.)

On 10/06/2021 17:23, Manfred wrote:
> On 6/10/2021 4:55 PM, David Brown wrote:
>> No, it would be a function which takes a type and returns its name.  I
>> see nothing special about that (even though you can't write such
>> functions in C.)  It would be silly to create a new modern language that
>> does not have at least that level of introspection.
>
> I'm going to make a note about this, although extrapolated from context.
>
> I don't think it would be silly.
> I mean, introspection is well known, and quite popular in /some/ kind of
> programming, but IMO it is not a "must have" feature that would be silly
> to miss.
> Nor makes a language modern per se - it is rather a feature that comes
> cheap with interpreted and JIT languages, which have gotten popular
> because of their perception of being easy to use.

A basic level of introspection is free (in the sense of no cost to the
programmer or to the run-time speed or size - clearly it takes time for
the tool implementer) in a language - compiled, interpreted, JIT, or
whatever. C has very limited support - things like sizeof, __func__,
__LINE__. C++ has more, though the RTTI is run-time rather than
compile-time. Things like the names of types, details of structures
(something that has been under discussion in a thread here recently),
and names of enumerator constants would all be very simple to have in a
language and would be useful for programmers. Yes, I would say it would
be silly to make a new language without such features.

But there are older languages that have them - Ada being an example
where you have quite a lot of introspection through attributes.

On 10/06/2021 15:55, David Brown wrote:
> On 10/06/2021 16:18, Bart wrote:
>> On 10/06/2021 14:30, David Brown wrote:
>>> On 10/06/2021 13:38, Bart wrote:
>>
>>> That would depend on how "print" is defined.  For most possible kind of
>>> identifiers, printing makes no sense - you don't "print" a label, a
>>> function, or a type.  You only print things with values, and those would
>>> be in the same namespace.
>>
>>> If you have a language for which it makes sense to "print" a function
>>
>> You mean like C:
>>
>>  #include <stdio.h>
>>  #include <stdint.h>
>>
>>  void fn(void){}
>>
>>  int main(void){
>>      printf("%p\n",(void*)(intptr_t)fn);
>>  }
>
> That is not "printing" a function. It is taking the /address/ of a
> function - something entirely different (the address of your house is
> not the same thing as your house). Then you are casting it to a pointer
> (in a way that is not actually defined by the C standards - but let's
> skip that for now).

What's wrong with it? How would /you/ turn a function pointer into a
void* type?

> All in all, you are printing an object that refers
> to a function, you are not printing the function.

Because 'printing the function' means what instead? If I try 'printing
an array':

char A[] = {0x48,0x83,0xec,0x08,0x48,0x83,0xc4,0x08,0xc3};
printf("%p\n",A);

I just get its address too.

On 11/06/2021 10:52, Bart wrote:
> On 10/06/2021 15:55, David Brown wrote:
>> On 10/06/2021 16:18, Bart wrote:
>>> On 10/06/2021 14:30, David Brown wrote:
>>>> On 10/06/2021 13:38, Bart wrote:
>>>
>>>> That would depend on how "print" is defined.  For most possible kind of
>>>> identifiers, printing makes no sense - you don't "print" a label, a
>>>> function, or a type.  You only print things with values, and those
>>>> would
>>>> be in the same namespace.
>>>
>>>> If you have a language for which it makes sense to "print" a function
>>>
>>> You mean like C:
>>>
>>>   #include <stdio.h>
>>>   #include <stdint.h>
>>>
>>>   void fn(void){}
>>>
>>>   int main(void){
>>>       printf("%p\n",(void*)(intptr_t)fn);
>>>   }
>>
>> That is not "printing" a function.  It is taking the /address/ of a
>> function - something entirely different (the address of your house is
>> not the same thing as your house).  Then you are casting it to a pointer
>> (in a way that is not actually defined by the C standards - but let's
>> skip that for now).
>
> What's wrong with it? How would /you/ turn a function pointer into a
> void* type?

Generally, I wouldn't. There simply isn't much use of inspecting a
function pointer, other than perhaps curiosity.

In my line of work, it can occasionally be useful to know exactly where
a function is. Maybe I want to check if the function is in ram or
flash, perhaps during testing and debugging. There I know /exactly/ the
details of the target, the implementation, the particular compiler, etc.
And I know that on that particular implementation, it is fine to cast
the function pointer to (uintptr_t) or (uint32_t), and use the value.
(Who uses "intptr_t" ? A /signed/ pointer?)

The conversions you used are allowed, but they are implementation dependent.

(I believe we have been through this before - you wanted to store your
function pointers as "void *" instead of something a little better such
as "void (*)(void)". There is no need to redo that here.)

>
>> All in all, you are printing an object that refers
>> to a function, you are not printing the function.
>
> Because 'printing the function' means what instead?

That is precisely my point - it does not have a meaning. It /might/
make sense to print the address, but printing the name is likely to be
more useful. Perhaps printing the assembly listing, or the RTL
intermediate code, or the source code would be more useful. Perhaps the
size. Perhaps all these. In C, with casts (or a very lenient
compiler), you get the address - that does not mean you are "printing
the function". You are printing the /address/ of the function.

> If I try 'printing
> an array':
>
>     char A[] = {0x48,0x83,0xec,0x08,0x48,0x83,0xc4,0x08,0xc3};
>     printf("%p\n",A);
>
> I just get its address too.

Yes, that's the way C works. But you are not printing the array - C
does not have built-in (or standard library) support to do that.

Bart <bc@freeuk.com> writes:
[...]
> What's wrong with it? How would /you/ turn a function pointer into a
> void* type?

Most likely I wouldn't.

If I actually needed to convert a function pointer to void*, I'd
use a cast. I'd be aware that the C standard doesn't define the
behavior of such a conversion, and that it might not work or might
be rejected by a conforming C compiler on some implementations.
For example, a function pointer might be bigger than a void*, so
the conversion would lose information. I'd probably also reread
the section of the standard that discusses pointer conversions.
I can imagine wanting to do such a conversion in non-portable code
(most likely temporary throwaway code), and a cast is likely to do
what I want for the system I'm using at the moment. Sometimes that's
good enough.

If I wanted to examine the representation of a function ponter in
a completely portable manner, I'd copy it to an array of unsigned
char of the appropriate size.

Or perhaps I'd store the address of a function pointer object in
a void* object, which might qualify as "turning it into" a void*,
but probably isn't what you meant.

But before doing any of that, I'd carefully consider *why* I want
to turn a function pointer into a void* (or why somebody else wants
me to) and what I want to do with the result, and work to define
the actual requirement precisely.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Le 11/06/2021 à 21:00, Keith Thompson a écrit :
> Bart <bc@freeuk.com> writes:
> [...]
>> What's wrong with it? How would /you/ turn a function pointer into a
>> void* type?
>
> Most likely I wouldn't.

According to C99, a pointer to a function is compatible with a pointer
to a function of a different type. Compatibility with a pointer to any
other object is not defined indeed. That can suggest, for instance, that
pointers to functions may have a different size than others pointers,
making a conversion impossible on some platforms.

Now in the "J.5 Common extensions" section, you can find "J.5.7
Function pointer casts". It's of course completely
implementation-specific, but as defined in the "common extensions"
section, is very likely to be found on a large range of platforms. So if
you want your code to be 100% portable, it's obviously to be avoided,
but assuming this in your code is still likely to be portable on a
pretty large range of systems. Your call.

Now even when this is allowed, it's still a slippery feature. Assigning
any pointer to a void * or conversely essentially bypasses any type
checking (except for the qualifiers).

In article <s9iea5$n5c$1@dont-email.me>,
James Harris <james.harris.1@gmail.com> wrote:

> So could C's struct tags be omitted from the language? If not, what does
> a struct tag add? Is it something to do with forward declarations or
> syntactic consistency with union tags, etc?

As explained in Algol 68 a recursive type must be built of one of
two forms: T = struct (ref T) and T = proc(T)T. The latter cannot
be constructed easily in C because C doesn't have forward
function declaration.

The former in C would be
typedef struct {T *t;} T;
but doesn't work because C doesn't allow forward declarations.

Struct tags provide enough information to allow forward
declarations while not looking like a forward declaration.

typedef struct T {struct T *t;} T;
-------- -------- -- -
| | | \- Declaration of T.
| | \----- Makes finite storage.
| \----------- Recursive T.
\--------------------- Forward declaration.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

On 2021-06-11, Guillaume <message@bottle.org> wrote:
> Le 11/06/2021 à 21:00, Keith Thompson a écrit :
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> What's wrong with it? How would /you/ turn a function pointer into a
>>> void* type?
>>
>> Most likely I wouldn't.
>
> According to C99, a pointer to a function is compatible with a pointer
> to a function of a different type. Compatibility with a pointer to any
> other object is not defined indeed. That can suggest, for instance, that
> pointers to functions may have a different size than others pointers,
> making a conversion impossible on some platforms.

Those platforms wouldn't have a GetProcAddress or dlopen function,
which means they are either specialized DSPs running very specialized,
single-purpose firmware, very tiny microcontrollers also running
very specialized firmware, or else museum machines.

On 11/06/2021 20:00, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> What's wrong with it? How would /you/ turn a function pointer into a
>> void* type?
>
> Most likely I wouldn't.
>
> If I actually needed to convert a function pointer to void*, I'd
> use a cast. I'd be aware that the C standard doesn't define the
> behavior of such a conversion, and that it might not work or might
> be rejected by a conforming C compiler on some implementations.
> For example, a function pointer might be bigger than a void*, so
> the conversion would lose information. I'd probably also reread
> the section of the standard that discusses pointer conversions.
> I can imagine wanting to do such a conversion in non-portable code
> (most likely temporary throwaway code), and a cast is likely to do
> what I want for the system I'm using at the moment. Sometimes that's
> good enough.
>
> If I wanted to examine the representation of a function ponter in
> a completely portable manner,

Not everyone needs to write 100% portable code. They might have some
targets in mind that they've used for years, and are likely to continue
using them for years to come.

At the minute I'be surprised if any contemporary /computer/ (not some
device that by some miracle someone has adapted a C compiler for),
doesn't use 64-bit functions and 64-bit object pointers, or 32-bit
equivalents.

I'd copy it to an array of unsigned
> char of the appropriate size.
>
> Or perhaps I'd store the address of a function pointer object in
> a void* object, which might qualify as "turning it into" a void*,
> but probably isn't what you meant.
>
> But before doing any of that, I'd carefully consider *why* I want
> to turn a function pointer into a void* (or why somebody else wants
> me to)

How about a table of function pointers which needs to hold pointers to
functions with arbitrary, mixed signatures. (Eg. the return values of
dlsym or GetProcAddress.)

Guillaume <message@bottle.org> writes:
> Le 11/06/2021 à 21:00, Keith Thompson a écrit :
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> What's wrong with it? How would /you/ turn a function pointer into a
>>> void* type?
>> Most likely I wouldn't.
>
> According to C99, a pointer to a function is compatible with a pointer
> to a function of a different type. Compatibility with a pointer to any
> other object is not defined indeed. That can suggest, for instance,
> that pointers to functions may have a different size than others
> pointers, making a conversion impossible on some platforms.

Quibble: the standard uses the word "compatible" in a very narrow sense.
Different function pointer types are not compatible in that sense. What
the standard does say is that you can convert from one pointer type to
another and back again and get the original value (or at least
something that compares equal to it).

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Guillaume <message@bottle.org> writes:
> Le 11/06/2021 à 21:00, Keith Thompson a écrit :
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> What's wrong with it? How would /you/ turn a function pointer into a
>>> void* type?
>> Most likely I wouldn't.
>
> According to C99, a pointer to a function is compatible with a pointer
> to a function of a different type. Compatibility with a pointer to any
> other object is not defined indeed. That can suggest, for instance,
> that pointers to functions may have a different size than others
> pointers, making a conversion impossible on some platforms.

Quibble: the standard uses the word "compatible" in a very narrow sense.
Different function pointer types are not compatible in that sense. What
the standard does say is that you can convert from one pointer type to
another and back again and get the original value (or at least
something that compares equal to it).

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
> On 11/06/2021 20:00, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> What's wrong with it? How would /you/ turn a function pointer into a
>>> void* type?
>> Most likely I wouldn't.
>> If I actually needed to convert a function pointer to void*, I'd
>> use a cast. I'd be aware that the C standard doesn't define the
>> behavior of such a conversion, and that it might not work or might
>> be rejected by a conforming C compiler on some implementations.
>> For example, a function pointer might be bigger than a void*, so
>> the conversion would lose information. I'd probably also reread
>> the section of the standard that discusses pointer conversions.
>> I can imagine wanting to do such a conversion in non-portable code
>> (most likely temporary throwaway code), and a cast is likely to do
>> what I want for the system I'm using at the moment. Sometimes that's
>> good enough.
>> If I wanted to examine the representation of a function ponter in
>> a completely portable manner,
>
> Not everyone needs to write 100% portable code. They might have some
> targets in mind that they've used for years, and are likely to
> continue using them for years to come.

Yes, I've repeatedly acknowledged that.

> At the minute I'be surprised if any contemporary /computer/ (not some
> device that by some miracle someone has adapted a C compiler for),
> doesn't use 64-bit functions and 64-bit object pointers, or 32-bit
> equivalents.

So would I. I still prefer to write portable code when practical.

> I'd copy it to an array of unsigned
>> char of the appropriate size.
>> Or perhaps I'd store the address of a function pointer object in
>> a void* object, which might qualify as "turning it into" a void*,
>> but probably isn't what you meant.
>> But before doing any of that, I'd carefully consider *why* I want
>> to turn a function pointer into a void* (or why somebody else wants
>> me to)
>
> How about a table of function pointers which needs to hold pointers to
> functions with arbitrary, mixed signatures. (Eg. the return values of
> dlsym or GetProcAddress.)

I'd implement that as a table of function pointers. The standard
guarantees that you can safely convert any pointer-to-function to any
pointer-to-function type and back again. It makes no such guarantee for
converting function pointers to void*.

Now if you decide to use void*, I won't tell you not to. I might not
even tell you it's not 100% portable unless you ask.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-06-11, Guillaume <message@bottle.org> wrote:
>> Le 11/06/2021 à 21:00, Keith Thompson a écrit :
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> What's wrong with it? How would /you/ turn a function pointer into a
>>>> void* type?
>>>
>>> Most likely I wouldn't.
>>
>> According to C99, a pointer to a function is compatible with a pointer
>> to a function of a different type. Compatibility with a pointer to any
>> other object is not defined indeed. That can suggest, for instance, that
>> pointers to functions may have a different size than others pointers,
>> making a conversion impossible on some platforms.
>
> Those platforms wouldn't have a GetProcAddress or dlopen function,
> which means they are either specialized DSPs running very specialized,
> single-purpose firmware, very tiny microcontrollers also running
> very specialized firmware, or else museum machines.

dlopen (defined by POSIX, not by C) return a void* that's a handle to a
dynamic library. You can pass that handle, along with a pointer to a
string to dlsym() to get the address of an object or function.

POSIX requires that a void* value *returned by dlsym()* can be converted
to the appropriate function pointer type and used to call the function.
As far as I can tell, it imposes no such requirement for pointer
conversions in general (I think that might be a relatively recent change
in POSIX). An implementation where, for example, function pointers are
bigger than void* could still support dlsym() with some special case
code. (It's very likely that there are no actual implementations that
need to do this.)

I'm less familiar with GetProcAddress (a Windows thing), but it returns
a result of type FARPROC, which apparently is actually defined as a
function pointer type. There are probably no Windows implementations
where function pointers are bigger than object pointers, but
GetProcAddress isn't what prevents that.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

On 11/06/2021 23:17, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:

>> How about a table of function pointers which needs to hold pointers to
>> functions with arbitrary, mixed signatures. (Eg. the return values of
>> dlsym or GetProcAddress.)
>
> I'd implement that as a table of function pointers.

Yeah, maybe. But that lets you call such a pointer without a cast, while
a void* or intptr_t entry always requires a cast.

Somebody looking at the code and seeing, say, an array of void(*)(void)
might also assume the elements are actual void(*)(void) pointers.

On 11/06/2021 21:14, Guillaume wrote:
> Le 11/06/2021 à 21:00, Keith Thompson a écrit :
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> What's wrong with it? How would /you/ turn a function pointer into a
>>> void* type?
>>
>> Most likely I wouldn't.
>
> According to C99, a pointer to a function is compatible with a pointer
> to a function of a different type. Compatibility with a pointer to any
> other object is not defined indeed. That can suggest, for instance, that
> pointers to functions may have a different size than others pointers,
> making a conversion impossible on some platforms.

Conversion between function pointers and object pointers is not defined
explicitly. But conversions between function pointers and integer
types, and between object pointers and integer types, are
implementation-defined. This means that you /can/ convert between a
function pointer and an object pointer (like void*) if you go via an
integer type. It is all implementation-defined, and may lead to traps,
invalid values, lost data (i.e., you can't necessarily reverse the
sequence and get the same pointer back), etc.

And yes, different sizes for different kinds of pointers is indeed
allowed in C - and does indeed exist in some implementations.

>
> Now in the "J.5 Common extensions" section, you can find "J.5.7 Function
> pointer casts". It's of course completely implementation-specific, but
> as defined in the "common extensions" section, is very likely to be
> found on a large range of platforms. So if you want your code to be 100%
> portable, it's obviously to be avoided, but assuming this in your code
> is still likely to be portable on a pretty large range of systems. Your
> call.
>
> Now even when this is allowed, it's still a slippery feature. Assigning
> any pointer to a void * or conversely essentially bypasses any type
> checking (except for the qualifiers).
>
>

On 2021-06-11, Bart <bc@freeuk.com> wrote:
> On 11/06/2021 23:17, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> How about a table of function pointers which needs to hold pointers to
>>> functions with arbitrary, mixed signatures. (Eg. the return values of
>>> dlsym or GetProcAddress.)
>>
>> I'd implement that as a table of function pointers.
>
> Yeah, maybe. But that lets you call such a pointer without a cast, while
> a void* or intptr_t entry always requires a cast.

That isn't true if the pointers are prototyped; the call would have to
match the type signature by dumb luck, the probability of which you can
reduce to close to zero somehow, one of the ways being this:

void (*fptr)(int, int, int, int, int, int, int, int, int, int, int,
int, int, int, int, int, int, int, int, int, int, int);

It's probably pretty hard to accidentally call a function pointer with
exactly 24 arguments.

Another way would be to define some struct type which is not known
outside of the declaration, such as because it specifies a struct
without a tag:

void (*fptr)(struct { int x; });

There is no way to call this function; it requires an argument of a type
which is not known outside of the declration.

I'm not sure if this is conforming code without diving into ISO C
scripture, but the on-by-default GCC diagnostic that it elicits is
enough to render this unattractive.

> Somebody looking at the code and seeing, say, an array of void(*)(void)
> might also assume the elements are actual void(*)(void) pointers.

To simply dissuade someone from calling the functions, without making
it a compiler error:

// do not directly call function pointers marked with this;
// the pointers must be converted to the matching type.
typedef void donotcall

struct whatever {
void (*fptr[13])(donotcall);
}

And then there is always:

#define donotcall int, int, int // umpteen times

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Kaz Kylheku <563-365-8930@kylheku.com> writes:

> On 2021-06-11, Bart <bc@freeuk.com> wrote:
>> On 11/06/2021 23:17, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> How about a table of function pointers which needs to hold pointers to
>>>> functions with arbitrary, mixed signatures. (Eg. the return values of
>>>> dlsym or GetProcAddress.)
>>>
>>> I'd implement that as a table of function pointers.
>>
>> Yeah, maybe. But that lets you call such a pointer without a cast, while
>> a void* or intptr_t entry always requires a cast.
>
> That isn't true if the pointers are prototyped; the call would have to
> match the type signature by dumb luck, the probability of which you can
> reduce to close to zero somehow, one of the ways being this:
>
> void (*fptr)(int, int, int, int, int, int, int, int, int, int, int,
> int, int, int, int, int, int, int, int, int, int, int);
>
> It's probably pretty hard to accidentally call a function pointer with
> exactly 24 arguments.
>
> Another way would be to define some struct type which is not known
> outside of the declaration, such as because it specifies a struct
> without a tag:
>
> void (*fptr)(struct { int x; });
>
> There is no way to call this function; it requires an argument of a type
> which is not known outside of the declration.
>
> I'm not sure if this is conforming code without diving into ISO C
> scripture, but the on-by-default GCC diagnostic that it elicits is
> enough to render this unattractive.

You can avoid the diagnostic at the expense of a struct type that could,
in theory, be completed. I've done this in the past:

typedef struct dont_complete_me dont_call_me_without_a_cast;
typedef void function(dont_call_me_without_a_cast);

(I prefer not to include the pointer in the function type.)

--
Ben.

On 12/06/2021 00:39, Ben Bacarisse wrote:
> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>
>> On 2021-06-11, Bart <bc@freeuk.com> wrote:
>>> On 11/06/2021 23:17, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> How about a table of function pointers which needs to hold pointers to
>>>>> functions with arbitrary, mixed signatures. (Eg. the return values of
>>>>> dlsym or GetProcAddress.)
>>>>
>>>> I'd implement that as a table of function pointers.
>>>
>>> Yeah, maybe. But that lets you call such a pointer without a cast, while
>>> a void* or intptr_t entry always requires a cast.
>>
>> That isn't true if the pointers are prototyped; the call would have to
>> match the type signature by dumb luck, the probability of which you can
>> reduce to close to zero somehow, one of the ways being this:
>>
>> void (*fptr)(int, int, int, int, int, int, int, int, int, int, int,
>> int, int, int, int, int, int, int, int, int, int, int);
>>
>> It's probably pretty hard to accidentally call a function pointer with
>> exactly 24 arguments.
>>
>> Another way would be to define some struct type which is not known
>> outside of the declaration, such as because it specifies a struct
>> without a tag:
>>
>> void (*fptr)(struct { int x; });

Another way is just to do this:

void* functable[]={printf, malloc, fwrite};

and specify the compiler options to be used or not used. Just don't
anyone about it on comp.lang.c.

On 2021-06-12, Bart <bc@freeuk.com> wrote:
> On 12/06/2021 00:39, Ben Bacarisse wrote:
>> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>>
>>> On 2021-06-11, Bart <bc@freeuk.com> wrote:
>>>> On 11/06/2021 23:17, Keith Thompson wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>>> How about a table of function pointers which needs to hold pointers to
>>>>>> functions with arbitrary, mixed signatures. (Eg. the return values of
>>>>>> dlsym or GetProcAddress.)
>>>>>
>>>>> I'd implement that as a table of function pointers.
>>>>
>>>> Yeah, maybe. But that lets you call such a pointer without a cast, while
>>>> a void* or intptr_t entry always requires a cast.
>>>
>>> That isn't true if the pointers are prototyped; the call would have to
>>> match the type signature by dumb luck, the probability of which you can
>>> reduce to close to zero somehow, one of the ways being this:
>>>
>>> void (*fptr)(int, int, int, int, int, int, int, int, int, int, int,
>>> int, int, int, int, int, int, int, int, int, int, int);
>>>
>>> It's probably pretty hard to accidentally call a function pointer with
>>> exactly 24 arguments.
>>>
>>> Another way would be to define some struct type which is not known
>>> outside of the declaration, such as because it specifies a struct
>>> without a tag:
>>>
>>> void (*fptr)(struct { int x; });
>
> Another way is just to do this:
>
> void* functable[]={printf, malloc, fwrite};
>
> and specify the compiler options to be used

Wow, that went downhill fast!

From:

"But that lets you call such a pointer without a cast"

To:

Let's use compiler options that lets you stick these pointers
into that table without casts.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 12/06/2021 01:51, Kaz Kylheku wrote:
> On 2021-06-12, Bart <bc@freeuk.com> wrote:

>> Another way is just to do this:
>>
>> void* functable[]={printf, malloc, fwrite};
>>
>> and specify the compiler options to be used
>
> Wow, that went downhill fast!
>
> From:
>
> "But that lets you call such a pointer without a cast"
>
> To:
>
> Let's use compiler options that lets you stick these pointers
> into that table without casts.

Huh? I'm taking about not being able to /call/ them. This doesn't work
using my table:

functable[2]();

If you use a table of function pointers:

void(*functable[])(void)={(void(*)(void))printf, NULL, NULL};

This has several problems:

(1) I couldn't for the life of me figure out the type syntax. (I had to
go back two generations in my language to a version with a C target;
then write this declaration: '[]ref proc functable', and look at the
generated C)

(2) Each initialisation element needs the right cast (not sure why those
NULLs don't need it, as I thought they had void* type)

(3) You can now call any element like this: functable[0]().

Alternatively we can go with your idea of using a function pointer type
that cannot be called by accident:

typedef void(*fnptr)(int,int,int,int,int,int);

fnptr functable[]={(fnptr)printf, (fnptr)malloc, (fnptr)fwrite};

Except now gcc complains of casts between incompatible pointer types.
And it has a point. It needs to go through an intermediate type:

fnptr functable[]={(fnptr)(uintptr_t)printf,
(fnptr)(uintptr_t)malloc, (fnptr)(uintptr_t)fwrite};

Sheesh... you don't think this is going around the houses a little for
something that you should just be done with in a couple of seconds?

----------------

This is a bit of generated C code that needs to use such a table of
pointers (here as a table of structs):

--------------------------------------------------
struct osnos_os_getdllprocaddr_rec {
uint8_t * name;
void * addr;
};

void (*osnos_os_getdllprocaddr(int64_t hinst,uint8_t * name))(void) {
static struct osnos_os_getdllprocaddr_rec table[23] = {
{(uint8_t*)"malloc",(void *)(&malloc)},
{(uint8_t*)"realloc",(void *)(&realloc)},
{(uint8_t*)"free",(void *)(&free)},
{(uint8_t*)"printf",(void *)(&printf)},
{(uint8_t*)"puts",(void *)(&puts)},
{(uint8_t*)"fgetc",(void *)(&fgetc)},
{(uint8_t*)"fputc",(void *)(&fputc)},
{(uint8_t*)"getchar",(void *)(&getchar)},
{(uint8_t*)"fopen",(void *)(&fopen)},
{(uint8_t*)"fclose",(void *)(&fclose)},
{(uint8_t*)"fseek",(void *)(&fseek)},
{(uint8_t*)"ftell",(void *)(&ftell)},
{(uint8_t*)"fread",(void *)(&fread)},
{(uint8_t*)"fwrite",(void *)(&fwrite)},
{(uint8_t*)"clock",(void *)(&clock)},
{(uint8_t*)"isalpha",(void *)(&isalpha)},
{(uint8_t*)"tolower",(void *)(&tolower)},
{(uint8_t*)"feof",(void *)(&feof)},
{(uint8_t*)"memset",(void *)(&memset)},
{(uint8_t*)"memcpy",(void *)(&memcpy)},
{(uint8_t*)"ungetc",(void *)(&ungetc)},
{(uint8_t*)"remove",(void *)(&remove)},
{(uint8_t*)"system",(void *)(&system)}
};
int64_t av_1;
int64_t i;
L1 :;
for (i=(int64_t)1;i<=(int64_t)23;i+=(int64_t)1) {
L2 :;
if (!!(mlib_eqstring(table[(i)-1].name,name))) {
return (void (*)(void))(table[(i)-1].addr);
};
L3 :;
}L4 :;
;
return (void (*)(void))(0);
}

--------------------------------------------------

Such a table allows me to write a limited version of an interpreter,
that normally would rely on GetProcAddress or dlsym, as an OS-neutral
version that compiles on either OS.

This is the original source:

global function os_getdllprocaddr(intm hinst,ichar name)ref proc=
record rec=
ichar name
ref void addr
end
static []rec table=(
("malloc", &malloc),
("realloc", &realloc),
("free", &free),
("printf", &printf),
("puts", &puts),
("fgetc", &fgetc),
("fputc", &fputc),
("getchar", &getchar),
("fopen", &fopen),
("fclose", &fclose),
("fseek", &fseek),
("ftell", &ftell),
("fread", &fread),
("fwrite", &fwrite),
("clock", &clock),
("isalpha", &isalpha),
("tolower", &tolower),
("feof", &feof),
("memset", &memset),
("memcpy", &memcpy),
("ungetc", &ungetc),
("remove", &remove),
("system", &system))

for i to table.len do
if eqstring(table[i].name,name) then
return table[i].addr
fi
od

return nil
end

On 12/06/2021 00:29, Bart wrote:
> On 11/06/2021 23:17, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> How about a table of function pointers which needs to hold pointers to
>>> functions with arbitrary, mixed signatures. (Eg. the return values of
>>> dlsym or GetProcAddress.)
>>
>> I'd implement that as a table of function pointers.
>
> Yeah, maybe. But that lets you call such a pointer without a cast, while
> a void* or intptr_t entry always requires a cast.
>
> Somebody looking at the code and seeing, say, an array of void(*)(void)
> might also assume the elements are actual void(*)(void) pointers.

So make your own type:

typedef struct {
void (*)(void) pf;
} function_pointer_t;

(Use whatever typedef, struct tags, naming conventions, etc., that you
like.)

That keeps it all clear in the code (you have a specific named type for
the job), and it keeps it safe - any attempt to use values of that type
directly as function pointers or object pointers will fail.

On 2021-06-12, Bart <bc@freeuk.com> wrote:
> On 12/06/2021 01:51, Kaz Kylheku wrote:
>> On 2021-06-12, Bart <bc@freeuk.com> wrote:
>
>>> Another way is just to do this:
>>>
>>> void* functable[]={printf, malloc, fwrite};
>>>
>>> and specify the compiler options to be used
>>
>> Wow, that went downhill fast!
>>
>> From:
>>
>> "But that lets you call such a pointer without a cast"
>>
>> To:
>>
>> Let's use compiler options that lets you stick these pointers
>> into that table without casts.
>
> Huh? I'm taking about not being able to /call/ them. This doesn't work
> using my table:
>
> functable[2]();
>
> If you use a table of function pointers:
>
> void(*functable[])(void)={(void(*)(void))printf, NULL, NULL};
>
> This has several problems:
>
> (1) I couldn't for the life of me figure out the type syntax.

Right; that's why there is this comp.lang.c newsgroup where getting
help with that is topical.

You could make a typedef:

typedef void (*any_fun_t)(int, int, int, ..., int);

This exists in precisely one place in the entire program. Then
it's just:

any_fun_t funtab[] = { (any_fun_t) printf, ... };

If there are many functions and/or tables, and have to be
frequently maintained, C99 preprocessing features could be used to
create a variadic initializer macro for this which looks like:

any_fun_t funtab3[] = fun_tab_init(foo, bar, xyzzy);

My main concern here would be this: the table records no type
information about the functions, which have arbitrary signatures.
Thus, if there is any intent to use the table to make calls,
there is no obvious way to do so correctly. Information about the
functions must be in some parallel table or other structure, which has
to track the functions accurately.

You're using a strawman example to make an unclear point.

> (2) Each initialisation element needs the right cast (not sure why those
> NULLs don't need it, as I thought they had void* type)
>
> (3) You can now call any element like this: functable[0]().
>
> Alternatively we can go with your idea of using a function pointer type
> that cannot be called by accident:
>
> typedef void(*fnptr)(int,int,int,int,int,int);
>
> fnptr functable[]={(fnptr)printf, (fnptr)malloc, (fnptr)fwrite};
>
> Except now gcc complains of casts between incompatible pointer types.
> And it has a point.

Now you're evidently just making things up:

$ gcc -Wall -W -pedantic -ansi fptr.c -c
$ gcc -Wall -W -pedantic -std=c99 fptr.c -c # silence
$ cat fptr.c
#include <stdio.h>

void (*fptr)(void) = (void (*)(void)) printf;

$ gcc --version
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0

> void (*osnos_os_getdllprocaddr(int64_t hinst,uint8_t * name))(void) {
> static struct osnos_os_getdllprocaddr_rec table[23] = {
> {(uint8_t*)"malloc",(void *)(&malloc)},
> {(uint8_t*)"realloc",(void *)(&realloc)},
> {(uint8_t*)"free",(void *)(&free)},

This is supposed to show how to do it more succinctly with fewer casts?

Why would you not just use "char *", for one thing.

> {(uint8_t*)"printf",(void *)(&printf)},
^ gratuitous operator
^ unnecessary parens

The cast notation and & are both unary operators: they go on the left
side of the operand and consequently associate right to left.

Parentheses are never needed to disambiguate between the same category
of operators; that's not what they are for.

> This is the original source:
>
> global function os_getdllprocaddr(intm hinst,ichar name)ref proc=
> record rec=
> ichar name
> ref void addr
> end

Now *that*'s a low-effort way to write a table of function pointers in C.
Write another language first, then capture the output.

Where is the risk in any of this code that a table entry could be called
directly?

The gaping risk is that something will call the function to look up
a name, and then misuse it by casting it to the wrong type before
calling it.

Obtaining an address from a name with the nicest C code is the least
important aspect of the whole interpreter design situation.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal