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

Groups > comp.lang.c > #379496

Re: Call to a function

Show all headers | View raw

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

> 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.

We have talked before about 4p3.  Your understandings of the
meaning and consequences of this sentence are mistaken, which if
you would take the time to read the published discussion notes
that led up to it being added to the standard I expect you would
realize.  In any case 4p3 is moot, because we are addressing the
qualifying condition:  if an implementation has a legitimate
reason not to accept a given program, then that program is not
"correct in all other aspects", and 4p3 doesn't apply.

Let's consider a concrete example.  This program

    #include <stdio.h>
    #include <stdint.h>

    extern char large[2305843009213693952];

    int
    main( void ){
        printf( "Hello, world\n" );
        printf( "\n" );
        printf( "SIZE_MAX is %21zu\n", SIZE_MAX );
        printf( "  large has %21zu  bytes\n", sizeof large );
        printf( "\n" );
        printf( "(... that's all, folks! ...)\n" );
        return  0;
    }

is, if I am not mistaken, free of any undefined behavior.  It can
be compiled and run, for example by gcc on a 64-bit linux system.
Yet if we ask clang to compile it on the same system, clang gives
an error complaining that the array is too large.  Note that the
same program, except with a one-smaller value of the array
dimension, can be compiled by clang without complaint, and run
successfully.  Clearly the clang implementors feel that the C
standard allows them not to accept this program, and the only
reason I can see for that is that the program is not strictly
conforming, because it exceeds a minimum implementation limit.

Long story short:  in how it treats this program, clang agrees
with my reading of the C standard.  Incidentally, gcc has the
same behavior as clang, only with a larger value of the array
dimension.


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

Per the C standard, "capacity" applies to data-processing systems
or to processors, not implementations.  Implementations have
implementation limits, also referred to in the standard as
environmental limits or translation limits.


> What is your answer to your own question?

The C standard requires implementations to accept any strictly
conforming program.  There is no statement in the standard that
requires implementations to accept any program other than those
that are strictly conforming (except perhaps the "one program"
of 5.2.4.1 p1, but implementations are free to choose a strictly
conforming program to satisfy this requirement, so there is no
conflict there).  Hence the C standard allows implementations not
to accept any program that is not strictly conforming.


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

Having a shared understanding on this threshold question is a
necessary prerequisite to addressing the larger question.  If you
can't or won't agree that not being strictly conforming is by
itself sufficient basis for not accepting a program, then there
seems little point in continuing, as my answer depends on that
premise for its conclusion.

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

Thread

Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-10 03:37 -0800
  Re: Call to a function Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-10 22:04 +0000
    Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-13 08:14 -0800
  Re: Call to a function Phil Carmody <pc+usenet@asdf.org> - 2023-11-13 21:35 +0200
    Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-11-13 12:48 -0800
    Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-13 19:17 -0800
      Re: Call to a function Phil Carmody <pc+usenet@asdf.org> - 2023-11-16 13:47 +0200
        Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-16 06:39 -0800
          Re: Call to a function Phil Carmody <pc+usenet@asdf.org> - 2023-11-21 01:29 +0200
            Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-21 23:21 -0500
            Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-24 11:12 -0800

csiph-web