Does C really now that little?

[ArWeGod]

Hi,

I've read several questions and often the answer was

'C knows nothing about [lots of different stuff here].'

So if C knows that little as some people say, what are the benefits, I
mean do other languages know more or is it a benefit that C knows nearly
nothing (what I can think about is that C is the largest common divisor
defined on most available platforms)?

The command set for C is small and elegant. In the "bad old days" there were
languages that were so complex that one couldn't keep the entire language in
one's mind. Ada comes to mind as an example. It was impossible to become a
true expert. By keeping the command set to a consistant, small size allows
one to truly master the language.

As to how it can do so much with so little, well C can be expanded with
external libraries. These can be written in Assembler, C, or another
language. So, even though C has no built-in input/output functions, the
standard library STDIO.H declares several functions, like fread() and
printf(), which allow programs to do input and output. The particular
version of these routines (the implementation)will have to be non-portable,
Operating System (OS) based code. So, Microsoft writes a printf() that works
on DOS machines, and I link it into my program, and I can output "Hello,
world!" to my computer screen. When I move the program to a Linux box, I
recompile with gcc and it will build my executable with a Linux-based
printf() that still outputs "Hello, world!" to my computer screen. Same
source code, two differnt executables that can only run on their own OS.

Unfortunately, with C++, we've taken a step back into the "bigger = better"
style of language creation. However, as PDA's and phones begin to need
programming, you can bet that C will be there first. There will be a big
need to avoid platform specific programming, as new device come out
constantly and your code will have to work right, right now.

(e-mail address removed)

 

[Jack Klein]

On 12 Aug 2003 18:05:33 -0600, Chris Torek <[email protected]>
wrote in comp.lang.c:

[big snip]

(Not that this stopped the X3J11 folks in all cases. For instance,
they stole "const" from C++, and broke it. They also picked

I strongly disagree with your first statement above. They stole
"const" from C++ and FIXED it. They also didn't break "volatile", as
C++ has quite badly, albeit inadvertently. A very large percentage of
production C programming today is in the realm of embedded systems,
and the C semantics of const are ideal for read-only objects in
ROM/EPROM/Flash etc.

the wrong rules for dealing with narrow unsigned arithmetic, where
the Unix compilers got it right but one particular PC compiler used
the silly "value-preserving" rules. They even tried to add an

On the other hand, your second gripe is right on. "Value preserving"
is at the top of my list of things that went wrong in 1989.

11th-hour unworkable version of C99's "restrict", called "noalias".
But for whatever reason, they did not invent directory operations.)

You forgot to mention that enums are so crippled as to be almost
useless in both C and C++, and bit-fields likewise, and...

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Chris Torek]

I strongly disagree with your first statement above. They stole
"const" from C++ and FIXED it. ...
the C semantics of const are ideal for read-only objects in
ROM/EPROM/Flash etc.

If we want const to mean "read-only object as stored in ROM or
equivalent", const should be a storage-class, not a type-qualifier.

The part of C that is particularly broken with respect to "const"
has to do with pointers that point to "const char *", when using
const as a type-qualifier. For instance, suppose you have a
function f() that takes a pointer to "const char *" and applies
strlen to the various p values:

void f(const char **p) {
... strlen(p) ...
}

but never modifies p, p, or p[j].

Now we have a function much like main(), in which we have a
"char **argv", reasonably suited to pass to f():

f(argv);

but C's type rules prohibit this. (C++'s type rules allow it
if we change f() to take "const char *const *", but even then,
C's type rules prohibit it.)

If "const" were a storage-class specifier, the call would be OK
(and any "const" keywords in f()'s parameter would effectively be
a no-op, or prohibited entirely).

 

[Daniel Haude]

On Tue, 12 Aug 2003 19:18:56 +0200,

Problem 1: The only one that can forbid or allow me aksing questions is my
mother
Uh-oh...

Problem 2: If you would be so kind to point me to a group where I can ask
that question (I didn't find a group called
comp.lang.c.historical-background or similiar)

comp.lang.c is the perfectly correct place to ask the question why C has
or has not certain features.

Problem 3: Please tell me the reason why asking this question is OT in
this group,

Nobody accused you of off-topicality, because...

If you would have had a look at the post I mention in my original post you
would have seen that I didn't ask the question,

What several people pointed out to you is that this group isn't concerned
with platform-specific stuff, using reading information from a hard disk
as an example. Nobody accused you of barging in here asking
platform-specific stuff (as happens several times a day).

so you don't need to tell
me not to discuss platform specific code, I'm really new to C and did my
best to stay standard conform, also if you search my previous posts I
mentioned everytime I wasn't sure wether it was ANSI C or not, so people
that strictly refer to ANSI C aren't forced to read further.

A simple 'ask at this group' would be enough

Why do you fail to understand that YOU asked YOUR question at the CORRECT
newsgroup and NOBODY said otherwise?

PS: in case you want to flame use my mail address because flames are
off-topic and users are not allowed to do this in the newsgroup

And this comes from Mr "The only one that can forbid or allow me aksing
questions is my mother"?

For I minute I thought, wow, here comes a role-model thread: A newbie
comes in and asks a question, modestly and politely, and already a couple
of our highly regarded specialist regulars (to avoid the term "guru") give
him equally (and unusually) polite, verbous answers. Sadly, Mr. newbie
reads into those answers criticism, even flaming, snd heads off down the
well-trodden path into the killfiles by educating people about c.l.c
topicality.

--Daniel

 

[Nils Petter Vaskinn]

Bogus argument: we're not talking about freestanding implementations,
which need not provide any of the standard library functions, anyway.
Therefore, including directory support into the standard C library would
not affect freestanding implementations in any way. Furthermore, it
wouldn't affect hosted implementations with no directory support either:
opendir (or whatever) could simply fail.

But for C to know about filesystems you would have to define functions to
access that filesystem. While this may seem a good idea now, future
advances in filesystems (or how OS'es deal with them) may make that
interface a bad choice. But if the filesystem interface is part of the
language making a change to it is hard, (as opposed to linking new
programs against the new library on old programs against the old one).

If C knows nothing about filesystems you are free to choose a library with
an interface that suits YOU and/or your selected plattform to access
filesystems. If on the other hand C pretended to know the ultimate
filesystem interface you would effectively have no choice, since alternate
ways would dwindle away into obscurity.


regards
NPV

 

[Kevin Easton]

I strongly disagree with your first statement above. They stole
"const" from C++ and FIXED it. ...
the C semantics of const are ideal for read-only objects in
ROM/EPROM/Flash etc.

If we want const to mean "read-only object as stored in ROM or
equivalent", const should be a storage-class, not a type-qualifier.

The part of C that is particularly broken with respect to "const"
has to do with pointers that point to "const char *", when using
const as a type-qualifier. For instance, suppose you have a
function f() that takes a pointer to "const char *" and applies
strlen to the various p values:

void f(const char **p) {
... strlen(p) ...
}

but never modifies p, p, or p[j].

Now we have a function much like main(), in which we have a
"char **argv", reasonably suited to pass to f():

f(argv);

but C's type rules prohibit this.

For good reason. If char ** were assignment-compatible with const char
**, then you could accidentally escape const:

const char c;
char *p;
const char **q = &p; /* This is what C doesn't allow */
*q = &c; /* this looks ok, both are const.. */
*p = '!'; /* ...oh no, we just broke const on ` c ' */

(C++'s type rules allow it
if we change f() to take "const char *const *", but even then,
C's type rules prohibit it.)

I'm not sure how C++'s type rules work - does the destination have to be
const-qualified from the deepest indirection level of the type being
assigned, all the way up to the second last level?

If "const" were a storage-class specifier, the call would be OK
(and any "const" keywords in f()'s parameter would effectively be
a no-op, or prohibited entirely).

That would have the very big problem of preventing the compiler from
diagnosing modifications to const objects made through pointers:

const int a;
int *p_a = &a;

a = 10; /* Diagnostic */
*p_a = 10; /* No diagnostic */

- Kevin.

 

[Dan Pop]

But for C to know about filesystems you would have to define functions to
access that filesystem. While this may seem a good idea now, future
advances in filesystems (or how OS'es deal with them) may make that
interface a bad choice.

If well designed and generic enough, this is not going to happen. See
below.

But if the filesystem interface is part of the
language making a change to it is hard, (as opposed to linking new
programs against the new library on old programs against the old one).

If C knows nothing about filesystems you are free to choose a library with
an interface that suits YOU and/or your selected plattform to access
filesystems. If on the other hand C pretended to know the ultimate
filesystem interface you would effectively have no choice, since alternate
ways would dwindle away into obscurity.

You're missing the point. C should provide a minimal interface to
accessing directories plus a minimal interface to the information
associated with each directory entry (a minimal <dirent.h> and a minimal
<stat.h>). Each implementation can either extend these minimal interfaces
or provide alternative solutions that provide as much information as
available on the underlying OS. The minimal and possibly suboptimal C
solution doesn't prevent better solutions that are platform specific.

E.g. the existence of <stdio.h> doesn't prevent any implementation from
providing alternate I/O interfaces, more flexible and more functional than
the standard C one.

Dan

 

[Eric Sosman]

But for C to know about filesystems you would have to define functions to
access that filesystem. While this may seem a good idea now, future
advances in filesystems (or how OS'es deal with them) may make that
interface a bad choice.

If well designed and generic enough, this is not going to happen. [...]

The design is the hard part. The most ambitious attempt
at such an abstraction layer that I've come across is that of
Common LISP, and (personal opinion) it isn't all that useful.
Smarter people than I put some serious skull sweat into the
CL scheme and came up with something inadequate; that suggests
to me that the problem is considerably nastier than it might
appear on first examination.

You're missing the point. C should provide a minimal interface to
accessing directories plus a minimal interface to the information
associated with each directory entry (a minimal <dirent.h> and a minimal
<stat.h>). Each implementation can either extend these minimal interfaces
or provide alternative solutions that provide as much information as
available on the underlying OS. The minimal and possibly suboptimal C
solution doesn't prevent better solutions that are platform specific.

E.g. the existence of <stdio.h> doesn't prevent any implementation from
providing alternate I/O interfaces, more flexible and more functional than
the standard C one.

I'm not sure how this differs from the situation that prevails
today: C offers a "minimal" directory interface (to wit, a null
directory interface), and platforms extend it in various ways.
A less vacuous (is "less vacuous" a linguistic abomination?)
interface would presumably aspire to provide a portable means of
getting at some common subset of all the file-cataloging schemes,
but the big question would be whether that subset could be large
enough to be useful. The Common LISP experience suggests that a
portable interface might be close to impotent, and that a useful
interface might not be very portable.

 

[Mark McIntyre]

My question was more like, why it is that C knows so little (since you
didn't answer me I allow myself to asume that C really knows very little).

ISO C is designed to be maximally portable to different hardware and
OSes. Therefore it is a subset of what any given platform can do.
Platform specific extensions are then developed to augment C's basic
functions. However they're not topical here.

Problem 1: The only one that can forbid or allow me aksing questions is my
mother

<pedantic>
Actually you can also be forbidden from asking questions by a wide
range of other people, from the police to a maniac with a pair of
pliers and a penchant for roast tongue.
</pedantic>

The point is, this group is for discussion of ISO C. If you ask
nontopical questions here, expect to get told to ask elsewhere, then
flamed, then insulted and finally plonked.

Problem 2: If you would be so kind to point me to a group where I can ask
that question (I didn't find a group called
comp.lang.c.historical-background or similiar)

a group that specialises in the platform you want to use. Suchg
extensions are typically platform specific.

Problem 3: Please tell me the reason why asking this question is OT in
this group,

see above.

 

[Mark McIntyre]

Scott McPhillips a écrit :


This is not a problem of having discs or not. C supports files through
functions like rename(), remove(),... Then, why are directories, which are
useful at keeping files well ordered, not part of the language?

C supplies functions to remove things called "files" but it has no
actual idea what these things are. They could include directories,
which are after all a feature from VMS, but not say PalmOS. C
therefore cleverly allows these things to exist, to allows each
platform to support them in its own way.

Why that feature is in, and why this one is out?

Because a committee voted on whether they thought it was generically
useful or not.

Why not adding another
level, called "graphical environment", with graphical functions added into
the standard libraries?

Because the vast majority of devices on which C programs might be used
do not have any "graphical device". Therefore its not generically
useful. You're thinking too narrow.

I don't think there is any rationale here. It probably just depends on the
people attending the commitee meetings and their particular needs.

Of course, thats called "democracy in action". If you think the
committe got it wrong, then you are as it happens completely at
liberty to join it for C200x.

 

[Serve La]

ISO C is designed to be maximally portable to different hardware and
OSes. Therefore it is a subset of what any given platform can do.

But, has every platform in the world implemented fopen?

 

[Kelsey Bjarnason]

[snips]

Portability /and/ power. If you modularise your code so that all the
portable code is separate from the non-portable code, you can move the code
from one implementation to another with a minimum of effort, because you
only have to re-write the non-portable bit.

On the other hand, if C had, say, networking support which it admitted, up
front, wouldn't be available on all implementations, all that would result
is the same sort of situation we have now with the standard library and
freestanding implementations - C code *ain't* guaranteed to work on them,
not if it relies on things only guaranteed to exist on hosted
implementations.

Hence, we could have items such as, say, __STDC_NETWORK__ defined if the
implementation supports the standard networking functions; if it doesn't,
then there would very likely be very little point in trying to build the
app on that implementation in any case: an e-mail client, say, for an
embedded device with no network support makes little sense. That same
e-mail app, however, could now merrily work with any conforming compiler
which _does_ provide the standard networking library.

On one project I worked on - a
browser for embedded systems - a mere 1% of 500,000 lines of code was
non-portable. To move to a new platform (which this company did on a
regular basis), the team needed only to rewrite 5,000 lines of code, all of
which were isolated into a few core modules for easy identification.

Whereas you could probably have simply done a recompile, had C provided a
richer standard library, while admitting that - as with freestanding
implementations - not everyone can do everything.

C seems to take the approach "Daddy must drink milk, because baby can't
eat steak" which seems a tad... weird. Allowing, as it _already_ does,
some aspects of the full library to remain unimplemented on systems where
implementation can't be done, however, hits both sides of the issue; if
you've got networking, your network apps just recompile. If you don't,
well, why are you trying to build a web browser for a non-network-capable
system?

C, for the most part, assumes the coder knows what he's doing - hence
tends to lack a lot of the "safety" features of other languages. Yet when
it comes to the library, C does a complete about-face, assumes the coder
doesn't know what he's doing, assumes he is silly enough to expect
network support on his ABS braking system, or a complete GUI on his Coke
machine and thus decides to avoid the problem by not providing such
support anywhere. This seems very strange: if the coder knows what he's
doing, let _him_ make the decision to include the calls or not; if he
doesn't, then add in the range checking and other safety features.

For all its utility, and as much as I like working with C, its underlying
design mentality seems to be one of multiple and contradictory views.

 

[Mark McIntyre]

But, has every platform in the world implemented fopen?

Every platform is required to. It can however simply return NULL.
Luckily an adequately large majority of systems usefully support
opening streams, hence its sufficiently portable.

 

[Lew Pitcher]

I don't agree. Some feature can be only implemented in assembly. How can we
access the system register CR0 by C language ?

Let me reiterate...

In theory, /with the proper hardware/, it should be possible to write an
operating system with Standard C.

Obviously, hardware that requires assembly language to access system registers
/is not the proper hardware/.


--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

 

[Robert Wessel]

But, has every platform in the world implemented fopen?

It has if it claims to be a hosted C implementation. A freestanding C
implementation does not require an implementation of fopen().

Note that fopen() is a C library function. In fact a fully conforming
(albeit not very useful) implementation would be:

FILE *fopen(const char *filename, const char *mode) {return NULL;}

 

[Richard Heathfield]

[snips]

Portability /and/ power. If you modularise your code so that all the
portable code is separate from the non-portable code, you can move the
code from one implementation to another with a minimum of effort, because
you only have to re-write the non-portable bit.

On the other hand, if C had, say, networking support which it admitted, up
front, wouldn't be available on all implementations, all that would result
is the same sort of situation we have now with the standard library and
freestanding implementations - C code *ain't* guaranteed to work on them,
not if it relies on things only guaranteed to exist on hosted
implementations.

Oh, sure, I agree 100%. I'd like the committee to add support for
networking, graphics, sound, and a whole bunch of other stuff. Instead,
though, they potter around with their math extensions (as if anyone cared
about those) and tentatively give us a bool here and a long long there (not
even a very long, which would at least have been scalable).

Hence, we could have items such as, say, __STDC_NETWORK__ defined if the
implementation supports the standard networking functions;

Or even:

TCP *tcp_open(const char *host, unsigned short port);

Returns NULL if the network connection could not be opened. (This is
precisely how my own TCP library works.) It could set errno, for people who
cared about how it failed, e.g. ENONET for "I don't do networks, dummy".


Same for graphics, sound, etc. The library can always say "no", can't it? So
I don't see what the big deal is. And as for the "lowest common
denominator" being a poor reflection of what you can achieve using heavily
implementation-specific techniques, well, yes, that's true, but irrelevant.
Portability vs power has always been a trade-off in /that/ respect, at
least.

if it doesn't,
then there would very likely be very little point in trying to build the
app on that implementation in any case: an e-mail client, say, for an
embedded device with no network support makes little sense. That same
e-mail app, however, could now merrily work with any conforming compiler
which _does_ provide the standard networking library.

Right. That's how it should be. But we have to deal with reality as it is,
not as we'd like it to be.

For all its utility, and as much as I like working with C, its underlying
design mentality seems to be one of multiple and contradictory views.

I don't think it started out that way.

 

[Dan Pop]

But for C to know about filesystems you would have to define functions to
access that filesystem. While this may seem a good idea now, future
advances in filesystems (or how OS'es deal with them) may make that
interface a bad choice.

If well designed and generic enough, this is not going to happen. [...]

The design is the hard part.

It isn't. All you need for the purposes of portable C programming
is getting the name of each item in a directory (except for the
"maintenance" items that might be present, like . and .. on Unix
systems) and a method of deciding whether such an item is an ordinary
file, a directory or neither. The missing bit is a function taking
a path name and an item name and concatenating them to produce a new
valid path name. This is all you need in order to be able to traverse
a full directory tree in a fully portable way. As I said, this can
be trivially achieved with a minimal <dirent.h> and a minimal <stat.h>.
Add the possibility to check whether a directory is "traversable" and
whether an ordinary file is readable/writable/executable by the current
program (additional features of the minimal <stat.h>) and you have
pretty much everything you need for solving a lot of currently
insolvable problems (in standard C) in a fully portable manner.

I'm not sure how this differs from the situation that prevails
today: C offers a "minimal" directory interface (to wit, a null
directory interface), and platforms extend it in various ways.

Obvious answer: with today's "minimal directory interface" you can't do
anything at all. With my proposed minimal interface you can solve most
of the directory access problems arising in the context of portable C
programming.

A less vacuous (is "less vacuous" a linguistic abomination?)
interface would presumably aspire to provide a portable means of
getting at some common subset of all the file-cataloging schemes,
but the big question would be whether that subset could be large
enough to be useful. The Common LISP experience suggests that a
portable interface might be close to impotent, and that a useful
interface might not be very portable.

Please point out the *concrete* problems raised by my proposal above.
I am not interested in the kind of vacuous statements contained in your
previous post.

Dan

 

[The real OS2 guy]

Hi,

I've read several questions and often the answer was

'C knows nothing about [lots of different stuff here].'

Absolutely correct.

So if C knows that little as some people say, what are the benefits, I
mean do other languages know more or is it a benefit that C knows nearly
nothing (what I can think about is that C is the largest common divisor
defined on most available platforms)?

Other languages may know more: one language about this, another about
that and so on.

But C is designed to be present on an abstract mashine. That means
that mashine has no real device - but abstract streams, whereas
streams are diveded into:
inputstream - an stream that delivers characters from something
that is able to deliver characters, like
- a terminal with unkown behavior
- a file, where the programmer has no more knowledge
about as it can send a stream of characters
- a pipe
outputstream - a stream that receives characters from the
the program and sends it to somewhere that is able to
receive characters like
- a terminal with unknown behavior
- a file, where the programmer has no more knowledge
about as that it can receive a stream of characters
- a pipe

There are trillions of OSes on the market whereas each OS has its own
set of APIs.
Most of them have at least a C interface - but nothing (except of the
documentation of the OS) exists that defines which APIs are exist,
which kind of parameters, how many parameters and which sequence of
parameters they use. Some OSes have a number of subsystems, each with
theyr own set of APIs. C knows nothing of them! There are some
libraries are around who are fullifies different kints of work (like
linked lists, database access (different kinds of databases),
mathematical functions, different kinds of printers, scanners, tapes,
and so on, and so on... None of them have to do a bit with C - except
that many have interfaces, designed to be used by C programs.

Many of them are written in C with some properitary extensions
included, some are written in other programming languages, but with
interfaces to C programs included.

This question came to my mind when I was reading "Serial Number of the
Hard Drive" (Message ID: [email protected]).
Because I often read 'Unix is written in C' I'm asking myself how an OS
can be written in C if it knows nothing about anything.

Oh yes, C knows absolutely nothing about that - but the OS has sets of
APIs, designed to be used from C programs. One or more of that is able
to ask the OS for the required information, others to write it, .....

C is a land of a programming language designed to be extended to do
anything a programmer may ever have in mind. But each extension is
more or less properitary and is NOT simply C as defined by the ANSI
standard. Many of thiese extensions have theyr own newsgroup (or more
than one!) whereas this extension is on topic.

C itself is nothing than a naked language with some syntax
constraints, a set of rules to programmers of C compilers, C
implementations, hosted and free standing environments and a bit less
strong for programmers of applications.

A free standing environment is an environment whereas is nothing known
than the hardware a C program has to run on. This means: absolutely no
I/O (as C knows absolutely nothing about devices), a minimum about
pointers (accessing a NULL pointer results in undefined behavior, a
NULL pointer is defined INSIDE a C source as binary 0 - even as the
mashine itself may use some other bitpattern to represent it (it is on
the compiler to make a binary 0 comparing to this bitpattern in
pointer context).

A hosted environment has knowledge about the underlying OS, so it can
use it to make the streams to connecting and correspondence to the
device in a standardised manner. The OS can, but must not deliver a
more complex set of APIs to C programs - but thiese are only
interfaces, defined by the OS, not the C.

And please stay on the newbiest level possible so I can understand that or
just tell me to wait 'till I learned more

All that above can be reduced to:
comp.lang.c handles the language C and its assigned standard library -
but it has nothing to do with properitary interfaces to a spezific OS
or device or library.

You may use C to write an OS (then you uses a free standing
environment, whereas you has to write any bit of I/O by yourself).

You may use C as defined by the ANSI C standard(s) (there are more
than one created over the years C exists now). Then you can use the
standard C library. Whereas the C library itself defines a set of APIs
to make some basic things (e.g. string handling, memory handling,
streamed IO and so on). All these is on topic here.

You may use C in the way your OS extends it - but this lts you alone
in one of the newsgrous defined to programm with the OS you're working
under, as this has nothing to do with C. You may use some libraries
created for doing special work - but then you have to find a newsgroup
that handles this specific library, because this library has nothing
to do with C, even if it is written itself in C.

That is because the language C and its standard library
- is itself complex enough to justify its own newsgroup
- knows nothing about real devices, because
handling with real devices is object of the OS
and the real hardware and has nothing to do with C
- is designed to work on an abstract mashine
that defines anything one needs to write a
C program in, whereas a C compiler for a
real mashine is able to produce code running
on it. It will give you more or less possibilities
to use properitary extensions - but these extensions
are not C as defined by the standard and unportable.
- is designed to be portable to any real mashine
that ever had/will be exist. But it lefts open
anything that is only defineable on a real mashine.
So using something that is only defined on a
properitary mashine makes the program incompatible and
at least unportable - and so you leaves the standard.

In short: Whenever you have a question about C, you're
welcome here. Whenever you have a question about something
C knows nothing about you have to go to a group that
knows about that.

--
Tschau/Bye

Herbert Rosenau
http://www.pc-rosenau.de eComStation Reseller in Germany
eCS 1.1 german is in beta testing

 

[Dan Pop]

Dan Pop wrote:


But for C to know about filesystems you would have to define functions to
access that filesystem. While this may seem a good idea now, future
advances in filesystems (or how OS'es deal with them) may make that
interface a bad choice.

If well designed and generic enough, this is not going to happen. [...]

The design is the hard part.

It isn't. All you need for the purposes of portable C programming
is getting the name of each item in a directory (except for the
"maintenance" items that might be present, like . and .. on Unix
systems) and a method of deciding whether such an item is an ordinary
file, a directory or neither. The missing bit is a function taking ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
a path name and an item name and concatenating them to produce a new ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
valid path name. This is all you need in order to be able to traverse ^^^^^^^^^^^^^^^
a full directory tree in a fully portable way. As I said, this can
be trivially achieved with a minimal <dirent.h> and a minimal <stat.h>.
Add the possibility to check whether a directory is "traversable" and
whether an ordinary file is readable/writable/executable by the current
program (additional features of the minimal <stat.h>) and you have
pretty much everything you need for solving a lot of currently
insolvable problems (in standard C) in a fully portable manner.

Are you proposing an interface that's only able to discover
existing files, but not able to synthesize names for new ones?

Are you reading impaired or what?

It's not clear what you mean by "portable" here. Obviously,

The obvious: people need to do that in otherwise portable code and
currently they cannot. With my proposal above, it becomes possible,
without sacrificing the code portability.

Your proposal amounts to "readdir() is The Answer," and that's
hardly a *concrete* proposal until it's augmented with a good deal
more detail.

All the detail is, in shematic form, presented at the beginning of
my previous post (and still visible in this post). It's downright
idiotic to summarise it as "readdir is The Answer". There is no
point in giving concrete function and macro names *before* the idea
is accepted.

A good design for such a facility seems difficult to me, but
you say it's simple.

You have completely failed to produce a valid criticism of my
proposal or to point out why it would cause implementation
difficulties on systems where implementing it would make any sense
in the first place.

Fine: different people have different levels
of ability and imagination, and what's hard for me may be easy
for you. If that's the case, I hope you will share your simple
and useful design with the committee that next revises the Standard
for the benefit of C programmers everywhere.

It would be a waste of time, as long as the committee insists that a
*minimal* file system interface (as described above) does not belong to
the standard.

Dan