Re: encapsulating directory operations

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