Sujet : Re: else ladders practice
De : antispam (at) *nospam* fricas.org (Waldek Hebisch)
Groupes : comp.lang.cDate : 27. Nov 2024, 11:47:11
Autres entêtes
Organisation : To protect and to server
Message-ID : <vi6tbd$148h7$2@paganini.bofh.team>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14
User-Agent : tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
Bart <
bc@freeuk.com> wrote:
On 25/11/2024 17:30, Scott Lurndal wrote:
Bart <bc@freeuk.com> writes:
On 24/11/2024 21:45, Keith Thompson wrote:
A more useful installation would of course need more standard headers,
an assembler, linker, and whatever .a files are needed to provide the
standard library.
>
Sure, those are all part of a C implementation, though they're not part
of gcc.
>
>
This seems to be a thing with Linux, where a big chunk of a C
implementation is provided by the OS.
Actually, no. The OS provides the dynamic linker and some os-specific
header files. Pretty much everything else comes from various
third-party packages.
>
That is, standard headers, libraries, possibly even 'as' and 'ld'
utilities.
None of those come from the OS.
So, if I install 5 distinct C compilers on Linux, will they each come
with their own stdio.h, or will they use the common one in /usr/include?
It depends on the compiler. IIUC your compiler has its own stdio.h.
There was 'Tendra C compiler' (tcc in short) which had its own
handling of headers. Basically, there was internal compiler
magic to activate headers. I do not remember if "real" headers were
just part of compiler executable or were kept in files. But
real header data were in compiler-specific format. You could
not look for stdio.h to see function declarations, I do not
remember if stdio.h was present as real file, but if it were
present it would contain only some compiler-specific magic
to activate declarations. In other words, Tendra did not
use system headers and its headers were unusable for other
compilers.
If you ask why, the reason was portability and standard compilance.
Tendra was supposed to give you the same results on wide
selection of machines, provided that machines supported
appropriater API-s. I do not remember how/if they handled
32 versus 64 bit issue, but their headers were claimed to be
100% standard compliant, as opposed to vendor headers which
often had various incompatibilites. They also provided
wrapper libraries so that when you called their wrapper
you got standard-specified behaviour (vendor libraries
frequently violated standards). Concerning API-s, they
went quite a bit beyond standard C and provided several
industry standards.
-- Waldek Hebisch