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

Groups > comp.lang.c > #379506

Re: Call to a function

Show all headers | View raw

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

Is your conclusion the same if the variable is scrapped and the printf
is given the type instead? clang retains its stance on the concept:

"""
phil@dovespaz:~$ clang -Wall -o crap crap.c
crap.c:11:59: error: array is too large (2305843009213693952 elements)
        printf( "  large has %21zu  bytes\n", sizeof(char[2305843009213693952]));
                                                          ^~~~~~~~~~~~~~~~~~~
1 error generated.
"""

Is there an "array", /per se/? I only see a type.

clang does seem to agree with me that it's a type it's looking at, as if
we try to feed it the expression-only version of sizeof, it notices that
you've given it a type name, not an expression:

"""
phil@dovespaz:~$ clang -Wall -o crap crap.c
crap.c:11:53: error: expected parentheses around type name in sizeof expression
        printf( "  large has %21zu  bytes\n", sizeof char[2305843009213693952]);
                                                    ^
                                                    (                         )
1 error generated.
"""

Phil
-- 
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

Back to comp.lang.c | Previous | Next — Previous in thread | 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