"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

> On Wednesday, April 12, 2023 at 5:36:03?AM UTC-4, Tim Rentsch wrote:
>
>> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
>>
>>> On Tuesday, April 11, 2023 at 10:46:24?PM UTC-4, Tim Rentsch wrote:
>>>
>>>> James Kuyper <james...@alumni.caltech.edu> writes:
>>>
>>> ...
>>>
>>>>> The fundamental problem is that, in C, a typedef is nothing more
>>>>> than an synonym for a type. In any context where you use a typedef,
>>>>> you could also use the explicit type itself. [...]
>>>>
>>>> Strictly speaking this assertion isn't quite right. Here is an
>>>> example:
>>>>
>>>> typedef long Elongator( int );
>>>>
>>>> extern const Elongator *elongator;
>>>
>>> I'm confused by that declaration - what is the 'const' supposed to
>>> mean in that context?
>>
>> 'Elongator' is a function type (that maps an int to a long).
>>
>> 'const Elongator' is a 'const' function type; in other words the
>> qualifier 'const' applies to the function type as a whole, not
>> just to the return type of the function.
>
> Which is even more meaningless.
>
>>> Normally, I would read that declaration as
>>> saying that elongator is an identifier with external linkage, and
>>> that (*elongator)(5) returns a "const long", which makes no sense to
>>> me.
>>
>> If 'elongator' had been declared as follows:
>>
>> const long (*elongator)( int );
>>
>> that would give the result you describe. But in effect the
>> declaration of 'elongator' is the following (not legal C, but
>> meant to show what is taking place):
>>
>> extern const (long (int)) *elongator;
>>
>> so the 'const' modifies the function type itself as a whole, and
>> not just the return type of the function. The syntax used there
>> is not allowed in C, which is why a typedef is needed.
>
> Sorry - I'd misunderstood what you were trying to get at, mainly because
> it's so patently absurd. True, the standard imposes no requirements
> when the behavior is undefined, so in particular it allows an
> implementation to interpret that declaration in that way. But so would
> any other construct with undefined behavior, such as division by 0.
> There's really no point in discussing code with undefined behavior
> beyond identifying that it does have undefined behavior.
> .
>
>>>> There is no way to declare the pointer object 'elongator' without
>>>> the use of a typedef.
>>>> It may be worth noting that using a type qualifier directly on a
>>>> function type is explicitly undefined behavior (but not a constraint
>>>> violation).
>>>
>>> gcc shares my confusion about that declaration, referring to
>>> precisely that rule:
>>> elongator.h:2:25: warning: ISO C forbids qualified
>>> function types [-Wpedantic]
>>> 2 | extern const Elongator *elongator;
>>> | ^~~~~~~~~
>>
>> Actually I think gcc is not confused, but has (for some unknown
>> reason) chosen to give a confusing error message. In point of
>> fact ISO C does not forbid qualified function types, but simply
>> says they are undefined behavior.
>
> You are correct - the C standard never forbids any code; it only
> specifies what can and cannot be expected of a conforming
> implementation if it processes such code. I agree, it would be
> better if the message had instead identified the declaration as
> having undefined behavior. However, that's not really relevant to
> my point - gcc correctly identified this code has having a serious
> problem, that it described the problem incorrectly is far less
> important.
>
>>> That error message disappears if I move the 'const', so that it
>>> qualifies elongator, which makes a lot more sense to me:
>>> extern Elongator * const elongator;
>>>
>>> and it accepts, as compatible, the following declaration of the
>>> same identifier:
>>>
>>> extern long(*const elongator)(int);
>>
>> Yes, moving 'const' to the other side of the '*' changes the
>> meaning of the declaration, just like the two declarations
>>
>> const int *pci;
>> int *const cpi;
>>
>> have different meanings for the types of the respective items
>> being declared.
>
> Agreed - it's just that I thought that you had made a mistake,
> since the code you actually wrote had undefined behavior, so I
> assumed that you must have meant something else. That you would
> actually present such code as if it constituted a meaningful
> rebuttal to my claim was so ridiculous I hadn't considered it.

I wasn't offering a rebuttal, simply correcting an incorrect
statement. And my comments were meaningful, even if the meaning
is not one you are interested in.

Furthermore there is another, related case that does not have
undefined behavior, and which I had hoped you would be perceptive
enough to discover for yourself. But as usual you were more
concerned with feeling like you were winning the argument than in
discovering what is true.