Re: encapsulating directory operations

"Richard Heathfield" <rjh@cpax.org.uk> wrote in message
news:100i7ub$2aaj2$1@dont-email.me...

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.

There are places in computing where powers of 2 are not
used, and sometimes it is important.

In this case it wasn't really necessary, but I wanted to be
precise anyway.

The main reason I use it is because I copied off someone
else (Gerhard, who wrote most of mvssupa.asm), when he
started using it.

Similarly, "BFN" was popular when I started using BBSes,
and I copied the others. It seems that as soon as I started
using it, everyone else stopped using it to the point where
many people have never seen it before I turn up.

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 !

Yeah - exactly.

That's sort of my goal.

But I am already preempting the fact that the ISO committee
is very unlikely to cooperate with me, so I will fork the
standard.

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;

That's changing the language. I'm not talking about changing
the language. There are precedence operators that should
ideally be changed too.

Maybe a new language with all these things sorted out
could be done one day. English could be revamped (or
replaced with Esperanto) too. But that's not what I'm
trying to do right now. And is not my question.

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

I'm guessing what this is, and this sounds like you want
some new functions. You can have some new functions
like a variant of strncpy that puts the terminating NUL
for you too. And snprintf too.

I'm not trying to do that. I'm after minimal changes to C90.

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

This is something that sounds good, but I'm not sure C90
is the right place for it. C90 covers simple applications
that block on every operation.

If you want to extend C90 to including fancy non-blocking,
that's fine, but a different extension to what I'm currently after.

Note that I did previously suggest the addition of an "fpeek",
to give a very minimal way of doing minimal non-blocking.

BFN. Paul.