When "1" is cast to a function type and then this is called,
one would expect this call to have undefined behavior. But
I can only find this in the C specification:

|If a converted pointer is used to call a function whose type
|is not compatible with the referenced type, the behavior is
|undefined.

. At the address "1" there is not "a function whose type is not
compatible", but no function at all. Is "no function at all" also
"a function whose type is not compatible with the referenced type"
or is there some other part of the specification by which a call
to an address where there is no function at all has UB?

Then, when "f()" is being evaluated and there is no UB, I'd
expect the control to temporarily be transfered to f. The C
spec has a section "Function Calls" under "Postfix Operators",
but I cannot find anything there that actually says this.

On 2023-09-22, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> When "1" is cast to a function type and then this is called,
> one would expect this call to have undefined behavior. But
> I can only find this in the C specification:
>
>|If a converted pointer is used to call a function whose type
>|is not compatible with the referenced type, the behavior is
>|undefined.

Because ISO C supports conversions between function pointer types,
above, the document is addressing what happens in the situation
when the address of a function is converted to a different pointer type,
which is then called. E.g. int puts(const char *) is misused as
a void (double) function:

void (*fptr)(double) = (void (*)(double)) puts;

So far, the behavior is defined: the conversion is valid.
The pointer could be converted to the correct type and used:

So, the above remarks make it clear that

fptr(3.14);

isn't defined.

> . At the address "1" there is not "a function whose type is not
> compatible", but no function at all.

The conversion is not supported by ISO C, and so itself has
undefined behavior:

void (*fptr)(double) = (void (*)(double)) 1;

There is no need to make remarks about the consequences of
using a pointer which was obtained by undefined behavior.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 9/22/23 11:21, Kaz Kylheku wrote:
> On 2023-09-22, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>> When "1" is cast to a function type and then this is called,
>> one would expect this call to have undefined behavior. But
>> I can only find this in the C specification:
>>
>> |If a converted pointer is used to call a function whose type
>> |is not compatible with the referenced type, the behavior is
>> |undefined.
>
> Because ISO C supports conversions between function pointer types,
> above, the document is addressing what happens in the situation
> when the address of a function is converted to a different pointer type,
> which is then called. E.g. int puts(const char *) is misused as
> a void (double) function:
>
> void (*fptr)(double) = (void (*)(double)) puts;
>
> So far, the behavior is defined: the conversion is valid.
> The pointer could be converted to the correct type and used:
>
> So, the above remarks make it clear that
>
> fptr(3.14);
>
> isn't defined.
>
>> . At the address "1" there is not "a function whose type is not
>> compatible", but no function at all.
>
> The conversion is not supported by ISO C, and so itself has
> undefined behavior:
>
> void (*fptr)(double) = (void (*)(double)) 1;
"An integer may be converted to any pointer type. Except as previously
specified, the result is implementation-defined, might not be correctly
aligned, might not point to an entity of the referenced type, and might
be a trap representation." (6.3.2.3p5).

The conversion itself is supported, it's just not guaranteed to result
in a pointer to "an entity of the referenced type". I would expect that
calling a function through a pointer that does not point at a function
would result in undefined behavior - but I think Stefan has a point -
I'm having trouble locating the part of the standard that explicitly
says so. I suppose that such a pointer could be considered to be a trap
representation. But even so, it's what you do with the resulting pointer
value that has undefined behavior, not the conversion itself.

On 2023-09-22, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 9/22/23 11:21, Kaz Kylheku wrote:
>> The conversion is not supported by ISO C, and so itself has
>> undefined behavior:
>>
>> void (*fptr)(double) = (void (*)(double)) 1;
> "An integer may be converted to any pointer type. Except as previously
> specified, the result is implementation-defined, might not be correctly
> aligned, might not point to an entity of the referenced type, and might
> be a trap representation." (6.3.2.3p5).
>
> The conversion itself is supported, it's just not guaranteed to result
> in a pointer to "an entity of the referenced type". I would expect that
> calling a function through a pointer that does not point at a function
> would result in undefined behavior - but I think Stefan has a point -
> I'm having trouble locating the part of the standard that explicitly
> says so. I suppose that such a pointer could be considered to be a trap
> representation. But even so, it's what you do with the resulting pointer
> value that has undefined behavior, not the conversion itself.

Thanks for the correction.

You would think that the description of function call expressions covers
this. E.g. in C99 we had the wording:

If the function is defined with a type that is not compatible with the
type (of the expression) pointed to by the expression that denotes the
called function, the behavior is undefined.

Whatever is at the address arising from the conversion of 1, if that is
an address, it is not a function defined with a type pointed to by the
pointer expression.

Also, this is tangentially relevant from Address and indirection
operators:

The unary * operator denotes indirection. If the operand points to a
function, the result is a function designator; if it points to an
object, the result is an lvalue designating the object. If the operand
has type ‘‘pointer to type’’, the result has type ‘‘type’’. If an
invalid value has been assigned to the pointer, the behavior of the
unary * operator is undefined.

An invalid function pointer cannot be deferenced using * in order
to designate a function. So that rules out (*f)() from being
well-defined, which casts doubt on f().

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-09-22, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>> When "1" is cast to a function type and then this is called,
>> one would expect this call to have undefined behavior. But
>> I can only find this in the C specification:
>>
>>|If a converted pointer is used to call a function whose type
>>|is not compatible with the referenced type, the behavior is
>>|undefined.
>
> Because ISO C supports conversions between function pointer types,
> above, the document is addressing what happens in the situation
> when the address of a function is converted to a different pointer type,
> which is then called. E.g. int puts(const char *) is misused as
> a void (double) function:
>
> void (*fptr)(double) = (void (*)(double)) puts;
>
> So far, the behavior is defined: the conversion is valid.
> The pointer could be converted to the correct type and used:
>
> So, the above remarks make it clear that
>
> fptr(3.14);
>
> isn't defined.
>
>> . At the address "1" there is not "a function whose type is not
>> compatible", but no function at all.
>
> The conversion is not supported by ISO C, and so itself has
> undefined behavior:
>
> void (*fptr)(double) = (void (*)(double)) 1;

The original post used "1", a string literal. You assumed it was an
integer constant in quotes. The point is the same either way, but
Stefan, it might have been clearer if you had shown sample code.

> There is no need to make remarks about the consequences of
> using a pointer which was obtained by undefined behavior.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 9/22/23 12:47, Kaz Kylheku wrote:
> On 2023-09-22, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 9/22/23 11:21, Kaz Kylheku wrote:
>>> The conversion is not supported by ISO C, and so itself has
>>> undefined behavior:
>>>
>>> void (*fptr)(double) = (void (*)(double)) 1;
>> "An integer may be converted to any pointer type. Except as previously
>> specified, the result is implementation-defined, might not be correctly
>> aligned, might not point to an entity of the referenced type, and might
>> be a trap representation." (6.3.2.3p5).
>>
>> The conversion itself is supported, it's just not guaranteed to result
>> in a pointer to "an entity of the referenced type". I would expect that
>> calling a function through a pointer that does not point at a function
>> would result in undefined behavior - but I think Stefan has a point -
>> I'm having trouble locating the part of the standard that explicitly
>> says so. I suppose that such a pointer could be considered to be a trap
>> representation. But even so, it's what you do with the resulting pointer
>> value that has undefined behavior, not the conversion itself.
>
> Thanks for the correction.
>
> You would think that the description of function call expressions covers
> this. E.g. in C99 we had the wording:
>
> If the function is defined with a type that is not compatible with the
> type (of the expression) pointed to by the expression that denotes the
> called function, the behavior is undefined.

That's 6.5.2.2p9 in the latest version of the standard that I have
access to.

> Whatever is at the address arising from the conversion of 1, if that is
> an address, it is not a function defined with a type pointed to by the
> pointer expression.

Correct. What the pointer points at is NOT a function, and is therefore,
in particular, not a function "defined with a type that is not
compatible ...". Therefore, 6.5.2.2p9 doesn't apply, and is therefore
not the reasons the behavior is undefined.

I've come to the conclusion that it's undefined by the omission of any
applicable explicit definition of the behavior (4p2).

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-09-22, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
>> On 9/22/23 11:21, Kaz Kylheku wrote:
>>
>>> The conversion is not supported by ISO C, and so itself has
>>> undefined behavior:
>>>
>>> void (*fptr)(double) = (void (*)(double)) 1;
>>
>> "An integer may be converted to any pointer type. Except as previously
>> specified, the result is implementation-defined, might not be correctly
>> aligned, might not point to an entity of the referenced type, and might
>> be a trap representation." (6.3.2.3p5).
>>
>> The conversion itself is supported, it's just not guaranteed to result
>> in a pointer to "an entity of the referenced type". I would expect that
>> calling a function through a pointer that does not point at a function
>> would result in undefined behavior - but I think Stefan has a point -
>> I'm having trouble locating the part of the standard that explicitly
>> says so. I suppose that such a pointer could be considered to be a trap
>> representation. But even so, it's what you do with the resulting pointer
>> value that has undefined behavior, not the conversion itself.
>
> Thanks for the correction.
>
> You would think that the description of function call expressions covers
> this. E.g. in C99 we had the wording:
>
> If the function is defined with a type that is not compatible with the
> type (of the expression) pointed to by the expression that denotes the
> called function, the behavior is undefined.
>
> Whatever is at the address arising from the conversion of 1, if that is
> an address, it is not a function defined with a type pointed to by the
> pointer expression.

It _could_ be a function. The mapping from integers to pointers
is implementation defined. There is no reason an implementation
couldn't define the conversion of integers to function pointers
as the nth function in the overall program, with functions being
listed alphabetically. So if a program defines a function

void aardvark( double d ){ (void)&d; }

then that program, with this definition of main(),

int main( void ){
((void (*)( double )) 1) ( 3.14 );
return 0;
}

could be a well-defined (as well as well-formed) program for that
implementation.

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> When "1" is cast to a function type and then this is called,
> one would expect this call to have undefined behavior. But
> I can only find this in the C specification:

Of course what you mean is there is a cast to a pointer to
function type. The C standard requires the casted-to type
to be a scalar type, and functions are not scalar types,
so a pointer-to-function type is needed.

> |If a converted pointer is used to call a function whose type
> |is not compatible with the referenced type, the behavior is
> |undefined.
>
> . At the address "1" there is not "a function whose type is not
> compatible", but no function at all.

An implementation could choose to convert an integer 1 to
a pointer to an actual function, because the mapping is
implementation defined. Of course it's very likely that it
won't be, but it could be.

> Is "no function at all" also
> "a function whose type is not compatible with the referenced type"
> or is there some other part of the specification by which a call
> to an address where there is no function at all has UB?

As James Kuyper rightly points out, trying to call through a
pointer that doesn't point to an actual function is undefined
behavior by virtue of the C standard not defining what happens
in such cases. Not having a definition has exactly the same
consequences as the standard giving an explicit statement that
the behavior is undefined (because the C standard says so).

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> When "1" is cast to a function type and then this is called,
>> one would expect this call to have undefined behavior. But
>> I can only find this in the C specification:
>
> Of course what you mean is there is a cast to a pointer to
> function type. The C standard requires the casted-to type
> to be a scalar type, and functions are not scalar types,
> so a pointer-to-function type is needed.
>
>> |If a converted pointer is used to call a function whose type
>> |is not compatible with the referenced type, the behavior is
>> |undefined.
>>
>> . At the address "1" there is not "a function whose type is not
>> compatible", but no function at all.
>
> An implementation could choose to convert an integer 1 to
> a pointer to an actual function, because the mapping is
> implementation defined. Of course it's very likely that it
> won't be, but it could be.

I worked on a C compiler that did just this. The machine put every
function into it's own memory segment, and the code segments (entirely
separate from data) were simply numbered, so there was a function 1, a
function 2 and so on. If the C library did not change much, you got to
know that a call to, say, function 34 was printf.

Programmers of a certain age, and from this side of the Atlatic, might
know the company (though maybe not the machine) from this description
alone since the memory architecture (for a personal workstation) was
borrowed from it big brothers at the same firm.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

[converting integers to pointer-to-function]

>> An implementation could choose to convert an integer 1 to
>> a pointer to an actual function, because the mapping is
>> implementation defined. Of course it's very likely that it
>> won't be, but it could be.
>
> I worked on a C compiler that did just this. The machine put every
> function into it's own memory segment, and the code segments (entirely
> separate from data) were simply numbered, so there was a function 1, a
> function 2 and so on. If the C library did not change much, you got to
> know that a call to, say, function 34 was printf.

Great info! thanks.

> Programmers of a certain age, and from this side of the Atlatic, might
> know the company (though maybe not the machine) from this description
> alone since the memory architecture (for a personal workstation) was
> borrowed from it big brothers at the same firm.

I hope you realize that there is no way I could read this
and not be curious about the particulars.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
> [converting integers to pointer-to-function]
>
>>> An implementation could choose to convert an integer 1 to
>>> a pointer to an actual function, because the mapping is
>>> implementation defined. Of course it's very likely that it
>>> won't be, but it could be.
>>
>> I worked on a C compiler that did just this. The machine put every
>> function into it's own memory segment, and the code segments (entirely
>> separate from data) were simply numbered, so there was a function 1, a
>> function 2 and so on. If the C library did not change much, you got to
>> know that a call to, say, function 34 was printf.
>
> Great info! thanks.
>
>> Programmers of a certain age, and from this side of the Atlatic, might
>> know the company (though maybe not the machine) from this description
>> alone since the memory architecture (for a personal workstation) was
>> borrowed from it big brothers at the same firm.
>
> I hope you realize that there is no way I could read this
> and not be curious about the particulars.

I only held off in case anyone wanted to play...

It was ICL. The workstation was the Perq from Three Rivers Corp. which
ICL licenced (or bought out right -- I don't recall) and, after some
internal wrangling, decided to make run Unix. It was a microcoded CPU
that could load and save instruction sets, so the instruction set to run
C could be designed as the compiler was being written. The design team,
being all existing ICL engineers, chose to copy some aspects of the
companies big machines. I had never worked on them, but I think the
"every function in it's own numbered segment" came from the 1900 and
2900 series mainframes.

The Perq was a wonderful piece of kit and very innovative, but that's a
poor predictor of success in the computer field. After I'd been working
on the project for a while, I was sent (almost literally undercover) to
go see what the workstation from a company no one had ever heard of was
like. In my naivety (I was a graduate hire), I reported back that that
it was not particularly fast and the graphics (and screen) were not up
to much, but that it did already have a full Unix implementation. It
was the Sun-1 workstation.

--
Ben.

On 25/09/2023 23:41, Ben Bacarisse wrote:
> I only held off in case anyone wanted to play...
>
> It was ICL. The workstation was the Perq from Three Rivers Corp. which
> ICL licenced (or bought out right -- I don't recall) and, after some
> internal wrangling, decided to make run Unix. It was a microcoded CPU
> that could load and save instruction sets, so the instruction set to run
> C could be designed as the compiler was being written. The design team,
> being all existing ICL engineers, chose to copy some aspects of the
> companies big machines. I had never worked on them, but I think the
> "every function in it's own numbered segment" came from the 1900 and
> 2900 series mainframes.
>
> The Perq was a wonderful piece of kit and very innovative, but that's a
> poor predictor of success in the computer field. After I'd been working
> on the project for a while, I was sent (almost literally undercover) to
> go see what the workstation from a company no one had ever heard of was
> like. In my naivety (I was a graduate hire), I reported back that that
> it was not particularly fast and the graphics (and screen) were not up
> to much, but that it did already have a full Unix implementation. It
> was the Sun-1 workstation.

Perq. OMG I haven't thought about that in _decades_!

I have this vague memory that there was an internal dispute about the
instruction set, and that part implementations were done on two.

IIRC (and it's very vague) it originally had a Pascal-oriented
instruction set, and it was recoded for C. But it could easily have been
the other way around! I wasn't involved, but I was near some of the guys
in BRA01 who were.

Andy

Vir Campestris <vir.campestris@invalid.invalid> writes:

> On 25/09/2023 23:41, Ben Bacarisse wrote:
>> I only held off in case anyone wanted to play...
>> It was ICL. The workstation was the Perq from Three Rivers Corp. which
>> ICL licenced (or bought out right -- I don't recall) and, after some
>> internal wrangling, decided to make run Unix. It was a microcoded CPU
>> that could load and save instruction sets, so the instruction set to run
>> C could be designed as the compiler was being written. The design team,
>> being all existing ICL engineers, chose to copy some aspects of the
>> companies big machines. I had never worked on them, but I think the
>> "every function in it's own numbered segment" came from the 1900 and
>> 2900 series mainframes.
>> The Perq was a wonderful piece of kit and very innovative, but that's a
>> poor predictor of success in the computer field. After I'd been working
>> on the project for a while, I was sent (almost literally undercover) to
>> go see what the workstation from a company no one had ever heard of was
>> like. In my naivety (I was a graduate hire), I reported back that that
>> it was not particularly fast and the graphics (and screen) were not up
>> to much, but that it did already have a full Unix implementation. It
>> was the Sun-1 workstation.
>
> Perq. OMG I haven't thought about that in _decades_!
>
> I have this vague memory that there was an internal dispute about the
> instruction set, and that part implementations were done on two.
>
> IIRC (and it's very vague) it originally had a Pascal-oriented instruction
> set, and it was recoded for C. But it could easily have been the other way
> around! I wasn't involved, but I was near some of the guys in BRA01 who
> were.

It came to ICL with a Pascal-oriented instruction set done by the people
at Three Rivers. The C one was largely the work of a few people at
Dalkeith. What's BRA01? Bracknell? IIRC the work was moved to Stoke
when Dalkeith was closed but I had decided to move on by then.

There was a very tentative Lisp instruction set (the OS was designed to
be able to swap instruction sets with context switches between
processes) but I don't think that was in-house. It might even have been
the work of an early customer.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Programmers of a certain age, and from this side of the Atlatic,
>>> might know the company (though maybe not the machine) from this
>>> description alone since the memory architecture (for a personal
>>> workstation) was borrowed from it big brothers at the same firm.
>>
>> I hope you realize that there is no way I could read this
>> and not be curious about the particulars.
>
> I only held off in case anyone wanted to play...

A laudable policy. Thank you for the followup info.

On 27/09/2023 03:56, Ben Bacarisse wrote:
> Vir Campestris <vir.campestris@invalid.invalid> writes:
>
>> On 25/09/2023 23:41, Ben Bacarisse wrote:
>>> I only held off in case anyone wanted to play...
>>> It was ICL. The workstation was the Perq from Three Rivers Corp. which
>>> ICL licenced (or bought out right -- I don't recall) and, after some
>>> internal wrangling, decided to make run Unix. It was a microcoded CPU
>>> that could load and save instruction sets, so the instruction set to run
>>> C could be designed as the compiler was being written. The design team,
>>> being all existing ICL engineers, chose to copy some aspects of the
>>> companies big machines. I had never worked on them, but I think the
>>> "every function in it's own numbered segment" came from the 1900 and
>>> 2900 series mainframes.
>>> The Perq was a wonderful piece of kit and very innovative, but that's a
>>> poor predictor of success in the computer field. After I'd been working
>>> on the project for a while, I was sent (almost literally undercover) to
>>> go see what the workstation from a company no one had ever heard of was
>>> like. In my naivety (I was a graduate hire), I reported back that that
>>> it was not particularly fast and the graphics (and screen) were not up
>>> to much, but that it did already have a full Unix implementation. It
>>> was the Sun-1 workstation.
>>
>> Perq. OMG I haven't thought about that in _decades_!
>>
>> I have this vague memory that there was an internal dispute about the
>> instruction set, and that part implementations were done on two.
>>
>> IIRC (and it's very vague) it originally had a Pascal-oriented instruction
>> set, and it was recoded for C. But it could easily have been the other way
>> around! I wasn't involved, but I was near some of the guys in BRA01 who
>> were.
>
> It came to ICL with a Pascal-oriented instruction set done by the people
> at Three Rivers. The C one was largely the work of a few people at
> Dalkeith. What's BRA01? Bracknell? IIRC the work was moved to Stoke
> when Dalkeith was closed but I had decided to move on by then.
>
> There was a very tentative Lisp instruction set (the OS was designed to
> be able to swap instruction sets with context switches between
> processes) but I don't think that was in-house. It might even have been
> the work of an early customer.
>
All ICL sites had a three letter town ID, plus a two digit sequence
number. A few towns had more than 9 sites. BRA01 was the main site at
Bracknell. I assumed from what you said that you worked for ICL.

Andy

Vir Campestris <vir.campestris@invalid.invalid> writes:

> On 27/09/2023 03:56, Ben Bacarisse wrote:
>> Vir Campestris <vir.campestris@invalid.invalid> writes:
....
>>> Perq. OMG I haven't thought about that in _decades_!
>>>
>>> I have this vague memory that there was an internal dispute about the
>>> instruction set, and that part implementations were done on two.
>>>
>>> IIRC (and it's very vague) it originally had a Pascal-oriented instruction
>>> set, and it was recoded for C. But it could easily have been the other way
>>> around! I wasn't involved, but I was near some of the guys in BRA01 who
>>> were.
>> It came to ICL with a Pascal-oriented instruction set done by the people
>> at Three Rivers. The C one was largely the work of a few people at
>> Dalkeith. What's BRA01? Bracknell?
....
> All ICL sites had a three letter town ID, plus a two digit sequence
> number. A few towns had more than 9 sites. BRA01 was the main site at
> Bracknell. I assumed from what you said that you worked for ICL.

Yes, I did. And, from what you tell me, I probably worked at DAL01
without ever knowing what it was called!

--
Ben.

On 28/09/2023 21:54, Ben Bacarisse wrote:
> Yes, I did. And, from what you tell me, I probably worked at DAL01
> without ever knowing what it was called!

Ah, Dalkeith. Other end of the country, I never got past Manchester.

And while I was looking I found this...

<http://www.chilton-computing.org.uk/acd/sus/perq_history/overview.htm>

<https://en.wikipedia.org/wiki/International_Computers_Limited#Locations>

Andy

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> On 2023-09-22, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>
>>> When "1" is cast to a function type and then this is called,
>>> one would expect this call to have undefined behavior. But
>>> I can only find this in the C specification:
>>>
>>> |If a converted pointer is used to call a function whose type
>>> |is not compatible with the referenced type, the behavior is
>>> |undefined.
>>
>> Because ISO C supports conversions between function pointer types,
>> above, the document is addressing what happens in the situation
>> when the address of a function is converted to a different pointer type,
>> which is then called. E.g. int puts(const char *) is misused as
>> a void (double) function:
>>
>> void (*fptr)(double) = (void (*)(double)) puts;
>>
>> So far, the behavior is defined: the conversion is valid.
>> The pointer could be converted to the correct type and used:
>>
>> So, the above remarks make it clear that
>>
>> fptr(3.14);
>>
>> isn't defined.
>>
>>> . At the address "1" there is not "a function whose type is not
>>> compatible", but no function at all.
>>
>> The conversion is not supported by ISO C, and so itself has
>> undefined behavior:
>>
>> void (*fptr)(double) = (void (*)(double)) 1;
>
> The original post used "1", a string literal. You assumed it was an
> integer constant in quotes.

I would say inferred rather than assumed. Clearly the OP was
using double quotes as a way of delimiting code, in much the same
way that some people use back tick (backward facing single
quotes); note that the original text also says "f()" to indicate
a function call, and there is no doubt that "f()" is not meant to
include the quotes as part of the code.

> The point is the same either way, [...]

The point isn't quite the same. The C standard explicitly says
integers may be converted to any pointer type. The C standard
does not say that a pointer to an object type may be converted
to a pointer to function type. Every implementation is within
its rights to reject any program whose static text includes[*] a
cast from a pointer to an object type to a pointer to function
type, regardless of whether the cast has any chance of being
executed.

[*] meaning, still present as source of any preprocessor
conditionals have been processed, etc.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> The point isn't quite the same. The C standard explicitly says
> integers may be converted to any pointer type. The C standard
> does not say that a pointer to an object type may be converted
> to a pointer to function type. Every implementation is within
> its rights to reject any program whose static text includes[*] a
> cast from a pointer to an object type to a pointer to function
> type, regardless of whether the cast has any chance of being
> executed.
>
> [*] meaning, still present as source of any preprocessor
> conditionals have been processed, etc.

I disagree. (I think we've discussed this before.)

Concretely, I believe that this program violates no syntax error or
constraint. It includes code whose behavior would be undefined if it
were executed, but the `if (0)` prevents that.

On what basis do you think a conforming implementation may reject it?
Do you see a syntax rule or constraint that it violates? Do you see
some other basis for rejecting it?

int main(void) {
int obj = 42;
typedef void func(void);
if (0) {
func *fptr = (func*)&obj;
fptr();
}
}

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>> The point isn't quite the same. The C standard explicitly says
>> integers may be converted to any pointer type. The C standard
>> does not say that a pointer to an object type may be converted
>> to a pointer to function type. Every implementation is within
>> its rights to reject any program whose static text includes[*] a
>> cast from a pointer to an object type to a pointer to function
>> type, regardless of whether the cast has any chance of being
>> executed.
>>
>> [*] meaning, still present as source of any preprocessor
>> conditionals have been processed, etc.
>
> I disagree. (I think we've discussed this before.)
>
> Concretely, I believe that this program violates no syntax error or
> constraint. It includes code whose behavior would be undefined if it
> were executed, but the `if (0)` prevents that.

The problem is that the is not required to be translatable.

The code being dead inside an if (0) doesn't rescue it.

Conversion between function and object pointers isn't something that is
only undefined at run time, but otherwise translatable.

> On what basis do you think a conforming implementation may reject it?

On the basis that it's not able to convert between object and
function pointers, and on the basis that it only eliminates dead
code that is first generated by its translation scheme.

> Do you see a syntax rule or constraint that it violates? Do you see
> some other basis for rejecting it?

The implementation can add its own constraint rule, and then
stop translation.

Undefined can cause the program to be terminated during translation or
execution, with or without a diagnostic.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>> The point isn't quite the same. The C standard explicitly says
>>> integers may be converted to any pointer type. The C standard
>>> does not say that a pointer to an object type may be converted
>>> to a pointer to function type. Every implementation is within
>>> its rights to reject any program whose static text includes[*] a
>>> cast from a pointer to an object type to a pointer to function
>>> type, regardless of whether the cast has any chance of being
>>> executed.
>>>
>>> [*] meaning, still present as source of any preprocessor
>>> conditionals have been processed, etc.
>>
>> I disagree. (I think we've discussed this before.)
>>
>> Concretely, I believe that this program violates no syntax error or
>> constraint. It includes code whose behavior would be undefined if it
>> were executed, but the `if (0)` prevents that.
>
> The problem is that the is not required to be translatable.

You left out a word, but I disagree.

> The code being dead inside an if (0) doesn't rescue it.
>
> Conversion between function and object pointers isn't something that is
> only undefined at run time, but otherwise translatable.

The standard doesn't talk about translatability. It says what is
allowed, and defines the behavior of *some* things that are allowed.
A cast from a function pointer type to an object pointer type,
or vice versa, satisfies the constraints for a cast operator.
(Conversions between pointer types and floating-point types are
explicitly banned. Function/object pointer conversions *could*
have been.)

Perhaps the standard would be improved by making object/function pointer
conversions not involving a null pointer constant a constraint
violation. That might break some working but non-portable code that
converts between function pointers and void*. Or perhaps the standard
could be changed to state explicitly that such conversions have
undefined behavior, but they already do due to the lack of any
definition of the behavior.

>> On what basis do you think a conforming implementation may reject it?
>
> On the basis that it's not able to convert between object and
> function pointers, and on the basis that it only eliminates dead
> code that is first generated by its translation scheme.

For most implementations, object and function pointers have the same
size and representation, and a conversion can just copy or reinterpret
the bits. For others, perhaps it could extend or truncate the result,
yielding garbage, just as (void*)(char)'x' yields garbage. Or it could
just yield a null pointer regardless of the operand. It's not plausible
that an implementation would not be *able* to perform such a conversion.

>> Do you see a syntax rule or constraint that it violates? Do you see
>> some other basis for rejecting it?
>
> The implementation can add its own constraint rule, and then
> stop translation.

What do you mean by "add its own constraint rule"? Constraints are
defined by the standard, not by an implementation. Are you suggesting
an implementation can add its own constraint for some code that the
implementer just found too difficult to handle correctly?

> Undefined can cause the program to be terminated during translation or
> execution, with or without a diagnostic.

*If* the undefined behavior can occur.

int a = 1;
const int b = 0;
if (b != 0) a /= b;

A compiler can prove that the division has undefined behavior if it's
executed. Can it reject the code because of that?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 10/3/2023 3:13 PM, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>> The point isn't quite the same. The C standard explicitly says
>> integers may be converted to any pointer type. The C standard
>> does not say that a pointer to an object type may be converted
>> to a pointer to function type. Every implementation is within
>> its rights to reject any program whose static text includes[*] a
>> cast from a pointer to an object type to a pointer to function
>> type, regardless of whether the cast has any chance of being
>> executed.
>>
>> [*] meaning, still present as source of any preprocessor
>> conditionals have been processed, etc.
>
> I disagree. (I think we've discussed this before.)
>
> Concretely, I believe that this program violates no syntax error or
> constraint. It includes code whose behavior would be undefined if it
> were executed, but the `if (0)` prevents that.
>
> On what basis do you think a conforming implementation may reject it?
> Do you see a syntax rule or constraint that it violates? Do you see
> some other basis for rejecting it?
>
> int main(void) {
> int obj = 42;
> typedef void func(void);
> if (0) {
> func *fptr = (func*)&obj;
> fptr();
> }
> }
>

"Saved by Zero" by the Fixx? lol

https://youtu.be/JOiZP8FS5Ww

;^)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>
>> The point isn't quite the same. The C standard explicitly says
>> integers may be converted to any pointer type. The C standard
>> does not say that a pointer to an object type may be converted
>> to a pointer to function type. Every implementation is within
>> its rights to reject any program whose static text includes[*] a
>> cast from a pointer to an object type to a pointer to function
>> type, regardless of whether the cast has any chance of being
>> executed.
>>
>> [*] meaning, still present as source of any preprocessor
>> conditionals have been processed, etc.
>
> I disagree. (I think we've discussed this before.)
>
> Concretely, I believe that this program violates no syntax error
> or constraint. It includes code whose behavior would be undefined
> if it were executed, but the `if (0)` prevents that.
>
> On what basis do you think a conforming implementation may reject
> it?

First let me ask a question. Does the C standard allow an
implementation to reject any program that is not strictly
conforming?

On 10/24/23 8:54 PM, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>
>>> The point isn't quite the same. The C standard explicitly says
>>> integers may be converted to any pointer type. The C standard
>>> does not say that a pointer to an object type may be converted
>>> to a pointer to function type. Every implementation is within
>>> its rights to reject any program whose static text includes[*] a
>>> cast from a pointer to an object type to a pointer to function
>>> type, regardless of whether the cast has any chance of being
>>> executed.
>>>
>>> [*] meaning, still present as source of any preprocessor
>>> conditionals have been processed, etc.
>>
>> I disagree. (I think we've discussed this before.)
>>
>> Concretely, I believe that this program violates no syntax error
>> or constraint. It includes code whose behavior would be undefined
>> if it were executed, but the `if (0)` prevents that.
>>
>> On what basis do you think a conforming implementation may reject
>> it?
>
> First let me ask a question. Does the C standard allow an
> implementation to reject any program that is not strictly
> conforming?

No, to reject a program it must violate some constraint.

Not being 'strictly conforming' (a technical term in the Standard) is
not a requirement for a program to be accepted.

Now, there is the escape clause, that allows an implementation to fail
to actually be able to run anything but the one specified program that
meets all the minimum requirements, but that isn't grounds to 'reject'
programs.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>> The point isn't quite the same. The C standard explicitly says
>>> integers may be converted to any pointer type. The C standard
>>> does not say that a pointer to an object type may be converted
>>> to a pointer to function type. Every implementation is within
>>> its rights to reject any program whose static text includes[*] a
>>> cast from a pointer to an object type to a pointer to function
>>> type, regardless of whether the cast has any chance of being
>>> executed.
>>>
>>> [*] meaning, still present as source of any preprocessor
>>> conditionals have been processed, etc.
>>
>> I disagree. (I think we've discussed this before.)
>>
>> Concretely, I believe that this program violates no syntax error
>> or constraint. It includes code whose behavior would be undefined
>> if it were executed, but the `if (0)` prevents that.
>>
>> On what basis do you think a conforming implementation may reject
>> it?
>
> First let me ask a question. Does the C standard allow an
> implementation to reject any program that is not strictly
> conforming?

Not just for that reason.

This program:

#include <stdio.h>
int main(void) {
printf("%zu\n", sizeof (int));
}

is not strictly conforming, since it depends on the
implementation-defined size of int. A hosted implementation that
rejected it would violate 4p3:

A program that is correct in all other aspects, operating on correct
data, containing unspecified behavior shall be a correct program and
act in accordance with 5.1.2.3.

(A perverse implementation could claim that it exceeds its capacity, but
I think we can ignore that.)

What is your answer to your own question?

And I hope we're not going to go back and forth too many times before
you answer mine.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */