Deutsch   English   Français   Italiano  
<87o6vbdr3e.fsf@nosuchdomain.example.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: encapsulating directory operations
Date: Thu, 29 May 2025 14:50:13 -0700
Organization: None to speak of
Lines: 77
Message-ID: <87o6vbdr3e.fsf@nosuchdomain.example.com>
References: <100h650$23r5l$1@dont-email.me> <100j09o$2f04b$1@dont-email.me>
	<87tt5ezx9y.fsf@nosuchdomain.example.com>
	<100j4t3$2foah$1@dont-email.me>
	<87ldqqzfj0.fsf@nosuchdomain.example.com>
	<100kak8$2q0s6$1@dont-email.me>
	<87a575zvmb.fsf@nosuchdomain.example.com>
	<100o3sc$3ll6t$1@dont-email.me>
	<87bjrkxonr.fsf@nosuchdomain.example.com>
	<b7fb8fc41d43807641e673e1ca1d3baf69f5766f@i2pn2.org>
	<87iklrtcys.fsf@nosuchdomain.example.com>
	<20250523132019.763@kylheku.com> <100qm76$7shk$2@dont-email.me>
	<20250523140729.787@kylheku.com> <100qru0$9mjb$2@dont-email.me>
	<101929h$3olom$4@dont-email.me> <10196gn$3pd33$1@dont-email.me>
	<101aca9$me2$3@dont-email.me> <101afvt$1sm1$1@dont-email.me>
	<871ps7f8o3.fsf@nosuchdomain.example.com>
	<101aif2$1sm2$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 29 May 2025 23:50:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="35ee183a1de7bb444a1794cff417189d";
	logging-data="88190"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+YmqWwxb0vJ1X7hg7FkO96"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:vokYiTBuY2BoA7fhZJ1aZXJ9IQk=
	sha1:Dj+n8V3OFe9oNDyHcg98Nj94fQo=

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 29/05/2025 21:45, Keith Thompson wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> On 29/05/2025 20:24, David Brown wrote:
>> [...]
>>>> That's one of the reasons I like C99 and C11, and look forward to
>>>> C23. Once implemented, they don't change either.
>>>> I agree with all your are arguments on this,
>>>
>>> So far so good. :-)
>>>
>>>> except for one - I can't understand why you think C90 is different
>>>> from later C standards in this regard.
>>>
>>> I realise that my reply is going to sound glib, but I can't help that.
>>>
>>> I *don't* think C90 is different. I think C90 is exactly the
>>> same. It's the later standards that are different. Different from C90.
>> I'd like to understand the point you're trying to make.
>
> I'll do what I can to help out; I'm really not trying to be obscure.
>
>> Being different is a transitive relationship.  C90 is different
>> "from later C standards".  You say that C90 is "exactly the same"
>> -- as what?  As itself?
>
> Yes. And nothing else has that quality of being C90.
>
>> C99 is also exactly the same as itself.
>
> Yes, but it's different from C99.

I hope that was a typo.  If you really meant that C99 is different from
C99, I suggest that requires a bit more explanation.

>> If the difference is that you personally like C90 and dislike C99
>> and later editions, that's fine.  De gustibus non est disputandem
>> (never argue with a guy named Gus).
>
> Look, Gus, if that's what you want to call yourself...well, okay, I
> can't in all honesty deny that de gustibus is part of it, but it's
> more to do with bit rot.
>
> Software houses need C90 for the same reason the government needs IBM
> 1311s (unless they've finished migrating off them now), cassette
> players, WW2 crypto keys, and the boot passwords for those early 1990s
> PCs lurking in the cellar.
>
> I shudder to think how much C90 code is out there, but it has to be
> /at least/ in the region of 10^9 LOC, much of it in the military
> arena, medical applications, and particularly the world of
> comms. Letting C90 compilers fall off the radar (e.g. by society
> forgetting how to program in it) really could be a stupendously bad
> idea, for all the reasons that people overlook when they shrug and say
> `I expect it'll all turn out fine'.

Right, there's a lot of existing C90 code out there, and we need
both C90 compilers and programmers who are familiar with C90
to maintain it.  The alternative of updating it to conform to a
later C standard is often impractical (and the update would also
require programmers who know C90).  I don't recall anyone suggesting
otherwise.  ISO has decreed that each edition "cancels and replaces"
the previous edition, but none of us are obligated to accept that.

If I were starting a new project in C, I would not consider
using C90.  At this point, I'd probably use C11 (perhaps with
compiler-specific extensions depending on the details of the
project).

Obviously C90, C99, and C11 are all different from each other.
You seem to be suggesting that C90 is special in some way that C99
and C11 are not.  If that's an accurate summary of your opinion,
can you explain it?  And if it isn't, just what are we talking about?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */