Path: csiph.com!1.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: bart again (UCX64) Date: Sat, 18 Nov 2023 05:44:10 -0800 Organization: None to speak of Lines: 93 Message-ID: <87sf53dvmd.fsf@nosuchdomain.example.com> References: <20230901114625.198@kylheku.com> <20230901135123.702@kylheku.com> <878r9p7b13.fsf@nosuchdomain.example.com> <20230901175635.91@kylheku.com> <87h6o95znv.fsf@nosuchdomain.example.com> <86jzt5pgho.fsf@linuxsc.com> <87zg214c1j.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="ffbf1726d022f3b93d004de80f69bfcf"; logging-data="3502715"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18mD5YMcJBdDfG4Za09KPf6" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:SJxJ3acOdhYq60XIscALWgm1mRg= sha1:uhp6VivImPuxali+zMLTTgMRimA= Xref: csiph.com comp.lang.c:379515 James Kuyper writes: > On 2023-11-18 at 00:17 EST, Tim Rentsch wrote: >> I don't remember any outstanding question from the discussion of >> falling off the end of a non-void function. Looking back over >> postings from you responding to a posting of mine I don't see >> any either. I guess it's possible there was a question but I >> didn't see it. In any case I have no idea what question in that >> thread you want answered, so if you still want an answer please >> ask the question again. > > The question he was referring to was the very last sentence of the > following text, which comes from a message posted on the thread titled > "bart again (UCX64)". You never answered it. Keith posted three more > messages on that subthread repeating the question and asking why you had > not bothered answering it. You answered with the same useless comments > about needing a "shared understanding of what the statement means" that > you're using in this thread. What makes those comments useless is not > that they are wrong, but that you failed to explain what understanding > you think is not shared between you and Keith. Because you failed to > explain that, I have no idea why you think it's needed to answer a > simple straightforward question like the following: > > On 9/4/23 21:57, Keith Thompson wrote: >> Tim Rentsch writes: >>> Keith Thompson writes: >>>> David Brown writes: >>>>> On 04/09/2023 12:06, Bart wrote: >>>> [...] >>>> >>>>>> char* fred(void) { >>>>>> (long long int)rand()*3.14159; >>>>>> } >>>>>> int main(void) { >>>>>> printf("%s\n", fred()); >>>>>> } >>>> >>>> [...] >>>> >>>>> As you know, it is not valid C code. As you know, proper C compilers >>>>> will - at least - warn you about it when asked to treat the input >>>>> according to the C standards. As you know, there isn't a compiler in >>>>> the world for any language which will stop programmers from writing >>>>> incorrect code. >>>> >>>> Given the context of the discussion, pedantry seems appropriate. >>>> >>>> It's invalid C code because it doesn't declare rand() and printf(), >>>> correctable by adding `#include ` and `#include `. >>>> (It also contains NO-BREAK SPACE characters, but that's that's just a >>>> Usenet formatting issue.) >>>> >>>> Other than that, a conforming C compiler is not required to diagnose >>>> the above code. It does have undefined behavior, and a C compiler is >>>> likely to warn about it with appropriate warnings, but it does not >>>> violate any syntax rule or constraint. >>> >>> I say it does. > > That would have been the correct place to identify the syntax rule or > constraint you think it violates, and I have no idea why you failed to > do so. > >> If you're right, then gcc 13.2.0 and clang 16.0.0 have a bug. Both >> compile the above code (once the required #include directives are added) >> without error, though clang prints a couple of optional warnings. I used >> "-std=c17 -pedantic-errors" with both compilers. (With "-Wall", gcc >> prints warnings similar to the ones clang prints without it.) >> >> What syntax rule or constraint does it violate? Yes, that is the question I was referring to. To repeat, given this code: char* fred(void) { (long long int)rand()*3.14159; } int main(void) { printf("%s\n", fred()); } I asserted that it does not violate any syntax rule or constraint. You asserted, with no explanation, that it does. What syntax rule or constraint does it violate? (Optional followup question: Why didn't you answer that when I first asked it two and a half months ago?) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */