Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Richard Heathfield <rjh@cpax.org.uk>
Newsgroups: comp.lang.c
Subject: Re: encapsulating directory operations
Date: Tue, 20 May 2025 16:43:05 +0100
Organization: Fix this later
Lines: 108
Message-ID: <100i7ub$2aaj2$1@dont-email.me>
References: <100h650$23r5l$1@dont-email.me>
 <87ecwj1vy9.fsf@nosuchdomain.example.com> <100hieb$261k5$1@dont-email.me>
 <100hs85$27qbn$1@dont-email.me> <100i14o$28o7d$1@dont-email.me>
 <100i43s$29dr0$1@dont-email.me> <100i632$29uce$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 20 May 2025 17:43:07 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3f6d60df11199315dcee71f6a818ac4e";
	logging-data="2435682"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+4DOgDLulbXfij8cYaaHNqshaiyLT08R9HotYHkL3xYg=="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:JEetVP85YE6YoIvCURXmlUinckU=
Content-Language: en-GB
In-Reply-To: <100i632$29uce$1@dont-email.me>

On 20/05/2025 16:11, Paul Edwards wrote:
> "Richard Heathfield" <rjh@cpax.org.uk> wrote in message
> news:100i43s$29dr0$1@dont-email.me...
>> [This should be fun.]
>>
>> On 20/05/2025 14:47, Paul Edwards wrote:
>>> "David Brown" <david.brown@hesbynett.no> wrote in message
>>> news:100hs85$27qbn$1@dont-email.me...
>>>> On 20/05/2025 11:36, Paul Edwards wrote:
>>>>> "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
>>>>> news:87ecwj1vy9.fsf@nosuchdomain.example.com...
>>>>>> "Paul Edwards" <mutazilah@gmail.com> writes:
>>>>
>>>>>>> And C90 (etc) could potentially be extended to include a folder.h
>>
>> directory.h, damn you! Folders are for schoolteachers, not
>> programmers. We could fall out over this.
> 
> What we'll fall out over is you exceeding the limits of
> MSDOS 8.3 filenames. :-)

I did actually think about that (only for about a microsecond, 
but yes, I used to think it was a big deal).

<snip>

>>> And in another corner, there are people who claim that I
>>> am at fault for not making "my" compiler (a slight variation
>>> of gcc 3.2.3) run in under 16 MiB of memory.
>>
>> Mibs are marbles. You can't run a C compiler under 16 marbles,
>> not even if you bring in Dennis Ritchie.
> 
> Pardon?

https://en.wiktionary.org/wiki/mib

Noun

mib (plural mibs)

     (games) A marble (glass ball used in games), especially one 
used as a target.

(Don't miss the quotations - priceless!)

> I also use Microsoft C 6.0 which was the
> last version to run on a PC XT in 640 KiB.

Well, kib turns out to be Sumerian for "leash". Naturally, I 
prefer "unleashed".

> 
> gcc 3.2.3 will run in under 16 MiB if I switch off optimization.
> 
>>> I understand where these people are coming from.
>>
>> So do I, but I expect it was a typo for 16 GB.
> 
> Nope.

Clearly humour has failed me on this occasion.

If you're allowed to get all uppity about 9-letter filenames 
(which uppityness I absolutely understand and respect), I reserve 
the right to insist on KB, MB, and GB instead of these 
nonsensical new inventions. The world knows full well that bit 
and byte prefixes are measured in powers of 2, and we don't need 
an intrusive iota irresponsibly interceding itself into initialisms.

>>> But my starting position is that I (sort of) can't personally
>>> fault the C90 standard, and the assembler code produced
>>> by a typical C compiler is exemplary, and that this is the
>>> basis for the lingua franca of programming.
>>
>> Right.
> 
> Certainly great to have company!

Today comp.lang.c, tomorrow ISO/IEC JTC 1/SC 22/WG 14 !

<snip 1 - no comment>


<snip 2 - Ce n'est pas ma tasse de thé.>

> Or to put it another way - if you didn't have time pressure,
> and the world was willing to stop writing code circa 1986
> until C had been standardized, and with the benefit of
> hindsight - what should or shouldn't be in a C90 or C2090 -
> however long it takes to "get it right"?

fclose would take a FILE ** instead of FILE *, and its dying act 
would be *fp = NULL;

qsort and bsearch would take context pointers to pass to cmp.

non-blocking sockets would be in the standard, using an interface 
based on fopen/fread/fwrite/fclose.

If I'm only allowed three, those would be the three I'd take.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within