Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Mon, 9 Sep 2024 10:46:02 +0200
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <vbmckb$2bn0s$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 09 Sep 2024 10:46:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="245842e44c78e95d3bc5cb773286c128";
	logging-data="2481180"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+IwR6/NUH38Y+M0PEUuJIm+8suhD2YvfU="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:j7K78pA/i7wl225KB/GqGYe9gw8=
In-Reply-To: <vbkcqi$1v2vr$1@dont-email.me>
Content-Language: en-GB
Bytes: 4480

On 08/09/2024 16:37, Janis Papanagnou wrote:
> On 08.09.2024 16:12, James Kuyper wrote:
>> On 9/8/24 00:39, Janis Papanagnou wrote:
>> ...
>>> That's why I immediately see the necessity that compiler creators need
>>> to know them in detail to _implement_ "C". And that's why I cannot see
>>> how the statement of the C-standard's "most important purpose" would
>> sound reasonable (to me). ...
>>
>> I agree - the most important purpose is for implementors, not developers.
>>
>>> ... I mean, what will a programmer get from the
>>> "C" standard that a well written text book doesn't provide?
>>
>> What the C standard says is more precise and more complete than what
>> most textbooks say.
> 
> Exactly. And this precision is what makes standard often difficult
> to read (for programming purposes for "ordinary" folks).
> 

Yes.  A standard is a different thing from a textbook, a tutorial, or a 
reference.

> If a textbook doesn't answer a question I have I'd switch to another
> (better) textbook, (usually) not to the standard.
> 

Or ask someone :-)

Not everyone needs to be an expert in the details of a programming language.


Often a good online reference is more helpful - this one is the best I 
know of (and I believe it is recommended and supported by the C++ 
standards committee):

<https://en.cppreference.com/>


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

> 
> To be honest, I was also inspecting and reading language standards
> (e.g. for the POSIX shell and awk), but not to be able to correctly
> write programs in those languages, but rather out of interest and
> for academical discussions in Usenet (like the discussions here,
> that also often refer to the "C" standard).
> 
>> For most of my career, I
>> worked under rules that required my code to avoid undefined behavior, to
>> work correctly regardless of which choice implementations make on
>> unspecified behavior, with a few exceptions.
> 
> Janis
>