Sujet : Re: question about linker
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.lang.cDate : 05. Dec 2024, 11:20:48
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <viruq2$1hvlq$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 05.12.2024 02:29, Tim Rentsch wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 03.12.2024 16:24, David Brown wrote:
>
Of course lots of C programmers have never read the standards.
But they generally know that they don't know these details, and
don't try to pretend that the language details that they don't
know are confusing. They simply get on with the job of writing
clear C code as best they can.
>
I feel an urge to point out that the C standard is not necessary
to understand concepts that can be read about in textbooks
That assumes that such textbooks exist, that they can be identified,
located, and obtained without too much difficulty, and don't cost too
much to get.
Actually no. I was just reporting experiences about the various
(many) programmers I've met in several companies during decades,
and from our technical (and academical) discussions. - Literally
no one had read the "C" standard, all had read one or more books
and all had some programming and/or computer science background.
Most people bought their books, some asked their company to buy
them, one company had built over time a library (physical books).
(And some/few people also used public or academical libraries.)
The C standard is easily located and obtained, and
costs nothing to download (for a draft that is virtually identical
to the actual standard).
When I started there was no Web and not even Email available in
my country. Standards documents were harder to obtain than books.
Only after around 1990 things (only slowly) changed hereabouts.
The first standards I got were extremely expensive, the companies
bought them on demand. The first downloads were unreliable; e.g. I
wasn't able to download the ITU-T standards because the connection
constantly dropped, because the documents were "too large" - not
because of the text but because they stupidly decided to publish
them using a bulky MS *.DOC format.
I'm sure these things got better later, and (given what you say)
that there was a better situation (in all respects) with the "C"
standard later. But since we know in what "standards language"
the texts are written I'd not have expected that folks typically
read standards but prefer textbooks; and that was backed up by
what I actually observed. (The largest crowd of people knowing
and quoting standards _regularly_ I saw in this newsgroup, BTW.
Well, okay, in the farther past I also read a "C++/std" group.)
or inferred (or just tried out, if the available sources are
unclear about some detail).
Two problems with that suggestion. One, trying to figure out what
the rules are by experimentation is sometimes difficult and
unreliable.
You're absolutely correct. Deriving rules by behavioral analysis
is not what you shall do (or what I would suggest).
Two, some details, such as what constructs result in
undefined behavior, simply cannot be determined by means of
experimentation.
Sure.
All I wanted to say is that *some* [types of] questions about
details you still have after reading a book (after learning the
language) can be just tried out to confirm the understanding of
the primary source of information (or experience-based assumption).
Also, the idea that one can figure out the rules of the C language
by looking at compiler sources is just laughable.
Sure. (But that wasn't something that I said. By "sources" I did
not mean "source code" but sources of information, books, etc.)
The idea to consider source code quasi as a [syntax-]"defining"
source came from Bart elsethread.
Janis