Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Call to a function Date: Mon, 13 Nov 2023 19:17:26 -0800 Organization: A noiseless patient Spider Lines: 80 Message-ID: <86wmulxbuh.fsf@linuxsc.com> References: <20230922081706.858@kylheku.com> <87zg1et4wv.fsf@nosuchdomain.example.com> <86jzs3de3h.fsf@linuxsc.com> <87h6n7tkv4.fsf@nosuchdomain.example.com> <86ttqf2w6p.fsf@linuxsc.com> <87zg07jo1t.fsf@nosuchdomain.example.com> <86il69zvno.fsf@linuxsc.com> <87a5rh1m5t.fsf@fatphil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="f1b36554058883ff18682f96ce8dd084"; logging-data="1161636"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Iwx+MjNQAeZ4KFZ1pNmZwxLxPEvSqfA8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:WuLju7oYeJwN8R5eTE/V3O2WtJ4= sha1:gQHlx3KhRuQ5R/BTtVQrMZ5t0MA= Xref: csiph.com comp.lang.c:379508 Phil Carmody writes: > Tim Rentsch writes: > >> Keith Thompson writes: >> >>> Tim Rentsch 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 >> #include >> >> 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. > 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. > 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").