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

Groups > comp.lang.c > #379512

Re: Call to a function

Show key headers only | View raw

Phil Carmody <pc+usenet@asdf.org> writes:

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

Here is my reasoning.

The sizeof operator works on both expressions (including expressions
that designate objects) and type names.

The result of sizeof has type size_t.

In <stdint.h>, the preprocessor symbol SIZE_MAX gives the maximum
value (for that implementation) of a value of type size_t.  SIZE_MAX
has a lower bound of 65535 (a minimum implementation limit).  So any
type whose size exceeds this value is violating the restriction that
strictly conforming programs not exceed a minimum implementation
limit.  (Sorry if that was belaboring the obvious.)

Or, here is another way to look at it.

Implemenations are allowed to have size_t be a 16-bit type.  If we
wanted to compile a declaration like

    struct foo { char a[20000], b[20000], c[20000], d[20000]; };

on such an implementation, the implementation would have to refuse
the program, because the size cannot be represented in a 16-bit
size_t (types have sizes even if they are never an operand of a
sizeof expressions).  Strictly conforming programs are intended to
be maximally portable.  Because a program with a type whose size
is more than 65535 cannot be accepted by an implementation with
a 16-bit size_t, the program must not be strictly conforming.


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

Looking through the standard, I see that the word array is used both
as an adjective and as a noun.

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

I am shocked, shocked to discover that a C compiler has a sloppily
worded diagnostic message.

But I agree with your assessment. :)

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