Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #177443

Re: Call to a function

Show all headers | View raw

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 */

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Call to a function Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-22 15:21 +0000
  Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-22 11:39 -0400
    Re: Call to a function Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-22 16:47 +0000
      Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-23 01:26 -0400
      Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-23 07:38 -0700
  Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-22 11:54 -0700
    Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-03 06:34 -0700
      Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-03 15:13 -0700
        Re: Call to a function Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-04 01:52 +0000
          Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-03 19:13 -0700
        Re: Call to a function "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-03 20:41 -0700

csiph-web