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

Groups > comp.lang.c > #379511

Re: Call to a function

Show all headers | View raw

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Phil Carmody <pc+usenet@asdf.org> 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:
>>>>
>>>>> [...]  Does the C standard allow an
>>>>> implementation to reject any program that is not strictly
>>>>> conforming?
>
> [...]
>
>>> 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?
>
> The short answer is yes.
>
> The lower bound for SIZE_MAX is 65535.  As I read the C standard,
> any object or any type whose 'sizeof' is bigger than 65535 means
> the program exceeds a minimum implementation limit, and is
> therefore not strictly conforming.  Because it is not strictly
> conforming, implementations are free not to accept it.

There's wording in the standard to support the "object" claim, but
I'm not seeing direct support for the "type" claim. Of course, there
might be a chain of deductions that leads there.

>> 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.
>
> An array type, but no array object.  I think most people would say
> there isn't an array, but just a type.

The standard uses the word "array" as a noun to refer to an array
object, so I was using the same usage as the standard there. And clang
was using that same word, and it was that usage of the word I was
calling into question. Given your similar view, I definitely think the
clang diagnostic is sloppily worded.

>> clang does seem to agree with me that it's a type it's looking at,
>> [...]
>
> Right, the operand of that sizeof is syntactically a type, not an
> expression (or more specifically, what the C standard calls a "type
> name").

Syntactically, yes.

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