Sujet : Re: Suggested method for returning a string from a C program?
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.cDate : 21. Mar 2025, 02:47:12
Autres entêtes
Organisation : None to speak of
Message-ID : <8734f7rw7z.fsf@nosuchdomain.example.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
User-Agent : Gnus/5.13 (Gnus v5.13)
bart <
bc@freeuk.com> writes:
On 21/03/2025 00:46, Kaz Kylheku wrote:
On 2025-03-20, bart <bc@freeuk.com> wrote:
On 20/03/2025 23:18, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
On 20/03/2025 19:10, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
[...]
stdint.h et al are just ungainly bolt-ons, not fully supported by the
language.
No, they're fully supported by the language. They've been in the ISO
standard since 1999.
>
I don't think so. They are add-ons that could have been created in
user-code even prior to C99 (user-defined typedefs for 64 bits would
'need long long').
>
Sure, they could; see Doug Gwyn's q8, for example.
>
Isn't that what I said? However I've just looked at this 700-line header:
The first thing you said was "I don't think so", in response to a true
statement that I made.
Following that, I wrote "Sure, they could....". I was agreeing with you
and providing an example. Is that a problem?
[...]
I just tried to compile it; it needs an extra q8defs.h file (600 more
lines), but it fails: "CPU not recognised" (it might have a point if
this was from the 1990s!).
It is from the 1990s. The web page was last updated in 1999. It hasn't
been updated since then because it's no longer necessary, since
<stdint.h> is part of the language and almost universally supported.
("gcc -std=c90 -pedantic-errors" doesn't even complain about <stdint.h>;
apparently it treats it as an implementation-defined header, the kind of
thing that most C software uses.)
gcc just gives lots of errors. To me it's all an ugly lot of code
which reminds me of what system headers looked like: a messy, fragile
patchwork of #ifdef blocks.
You're complaining about how much work it is. All that work
has been done for you by the implementers. Decades ago. I just
did a quick test comparing complation times for an empty program
with no #include directives and an empty program with #include
directives for <stdint.h> and <inttypes.h>. The difference was
about 3 milliseconds. I quite literally could not care care less.
of the core language, it would be zero lines.
This kind of argumentation is really not of good quality.
A feature requires lines of code. If those lines are not in some
satellite file like a C header, then they are elsewhere, like in the
compiler source code.
>
Doing stuff the C way requires LOTs of lines of code. Look at all
those MIN/MAX macros, the PRINT/SCAN macros; there's hundreds of them!
So what? I don't have to read those lines of code. All I have to read
is the standard (or some other document) that tells me how to use it.
[...]
I don't bother with LEAST/FAST types, whatever those mean. Where did
that all come from anyway? I've never seen those used.
I'd explain, but I've never known you to be grateful or even
interested when someone gives you information. If you actually
wanted to know what they mean, you could consult the standard.
If you don't care about something (and you're not obligated to care
about anything), please don't ask about it.
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comvoid Void(void) { Void(); } /* The recursive call of the void */