Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Mon, 9 Sep 2024 08:21:23 -0400
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <vbmp83$2dc4t$1@dont-email.me>
References: <vab101$3er$1@reader1.panix.com> <87mskwy9t1.fsf@bsb.me.uk>
 <vanq4h$3iieb$1@dont-email.me> <875xrkxlgo.fsf@bsb.me.uk>
 <vapitn$3u1ub$1@dont-email.me> <87o75bwlp8.fsf@bsb.me.uk>
 <vaps06$3vg8l$1@dont-email.me> <871q27weeh.fsf@bsb.me.uk>
 <20240829083200.195@kylheku.com> <87v7zjuyd8.fsf@bsb.me.uk>
 <20240829084851.962@kylheku.com> <87mskvuxe9.fsf@bsb.me.uk>
 <vaq9tu$1te8$1@dont-email.me> <875xrivrg0.fsf@bsb.me.uk>
 <20240829191404.887@kylheku.com> <86cylqw2f8.fsf@linuxsc.com>
 <871q2568vl.fsf@nosuchdomain.example.com> <vavmbk$13k4n$1@dont-email.me>
 <87cylo494u.fsf@nosuchdomain.example.com> <vb09gd$16mr5$1@dont-email.me>
 <20240831195350.785@kylheku.com> <86mskrrvco.fsf@linuxsc.com>
 <vbj9qb$1qi2h$1@dont-email.me> <vbkbc1$1u33o$1@dont-email.me>
 <vbkcqi$1v2vr$1@dont-email.me> <vbmckb$2bn0s$1@dont-email.me>
 <vbmkl4$2cqcu$1@dont-email.me> <vbmkr5$2cmfo$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 09 Sep 2024 14:21:29 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="fc421bddf55117e750f6777390bdd015";
	logging-data="2535581"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19sKSvKRUgE3YVbBzDT2fRZJUmNOhJqUXQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:zwHAfg1TAGPf3YT2QocTQ0Pw0zc=
In-Reply-To: <vbmkr5$2cmfo$2@dont-email.me>
Content-Language: en-US
Bytes: 4847

On 9/9/24 07:06, David Brown wrote:
> On 09/09/2024 13:03, James Kuyper wrote:
>> On 9/9/24 04:46, David Brown wrote:
>>> On 08/09/2024 16:37, Janis Papanagnou wrote:
>>>> On 08.09.2024 16:12, James Kuyper wrote:
>> ...
>>>>> Most important for my purposes, it makes it clear
>>>>> what's required and allowed by the standard.
>>>
>>> No, that is not really true - the C standard is /not/ clear on all
>>> points.  There are aspects of the language that you cannot fully
>>> understand without cross-referencing between many different sections
>>> (and there are a few aspects that are not clear even then).  That is
>>> because it is a standard, not a tutorial, and not a language reference.
>>> A standard is written in more "legalise" language, and makes a point of
>>> trying to avoid repeating itself - while a good reference will repeat
>>> the same information multiple times in different places, whenever it
>>> helps for clarity.
>>
>> I will concede your point, but it's still the case that the standard is
>> clearer about such things than any other source I'm familiar with.
> 
> I have lost track of which particular "such things" we are talking about 
> here, so you could well be right!

I was talking about "... what's required and allowed by the standard ...".

> The standard /is/ clear on some aspects of C - but not on others.  I 
> don't dispute that it is a useful document and one that serious C 
> programmers should aspire to read, but I don't think it is really aimed 
> at "normal" C programmers or useful to them.  Perhaps the original 
> writers did not envisage so many non-experts getting involved in C coding.

I will concede that there's many aspects of C that's it's less than
clear about - but I'm unaware of any other document that's clearer about
those aspects. I don't see how there can be - if the standard isn't
clear about something, there's no way to be sure what the "truth" behind
the lack of clarity is, so it's not possible for some other document to
clarify it. Exception: if a DR has been filed, and the committee has
responded with a clarification, but has not yet updated the standard
accordingly, the DR resolution is a document that's clearer than the
standard on that issue, and just as authoritative.

Other documents can say things like "... the standard isn't clear about
this, but you can count on all real-world implementations to do ...".
But when it's a question about "... what's required and allowed by the
standard ...", such alternatives are irrelevant.

Somewhat trickier are the cases where some other document says "... the
standard says X, but that doesn't make any sense. It's clear that they
actually meant Y, and you can just write your code accordingly." Tim
Rentsch is a prolific source of such comments. From what I've seen, when
people have written such things, and the committee later resolved the
issue, they often did not resolve it in the expected way.