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

Groups > comp.lang.c > #379515

Re: bart again (UCX64)

Show all headers | View raw

James Kuyper <jameskuyper@alumni.caltech.edu> 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 <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> David Brown <david.brown@hesbynett.no> 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 <stdlib.h>` and `#include <stdio.h>`.
>>>> (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 */

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-18 00:57 -0500
  Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-11-18 05:44 -0800
    Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-19 00:25 -0800
      Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-11-19 13:08 -0800
        Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-25 17:45 -0800
          Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-25 21:12 -0800
          Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-12-27 20:14 -0500
            Re: bart again (UCX64) Julieta Shem <jshem@yaxenu.org> - 2023-12-27 23:22 -0300
              Re: bart again (UCX64) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-28 04:25 +0100
            Re: bart again (UCX64) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-28 04:22 +0100
            Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-12-28 09:12 +0100
              Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-12-28 16:31 +0800
      Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-19 19:03 -0500
        Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-25 17:46 -0800

csiph-web