Still no dirent.h in C1X

[David Demelier]

Hello,

I've seen the new standard of C called C1x.
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1250.pdf

They added some great features like anonymous unions and threads. But
there is still no directory management. I think that's very annoying.
Why threads should be added and dirent.h should not ?

 

[Eric Sosman]

I've seen the new standard of C called C1x.
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1250.pdf

They added some great features like anonymous unions and threads. But
there is still no directory management. I think that's very annoying.
Why threads should be added and dirent.h should not ?

Your question is better suited to comp.std.c than to this forum.

 

[Quentin Pope]

Hello,

I've seen the new standard of C called C1x.
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1250.pdf

They added some great features like anonymous unions and threads. But
there is still no directory management. I think that's very annoying.
Why threads should be added and dirent.h should not ?

You may not be aware that many, probably the majority, of C programs run
on systems without any notion of directories. For example, embedded
processors, but also many mainframe systems. It's only a few months ago
that I was doing some maintenance work on a UNISYS A Series, which has a
flat file system. This is not unusual for mainframes in current use.

C should not be ladened with cruft that simply doesn't make sense on a
large proportion of implementations.

My 2c.

//QP

 

[Ian Collins]

You may not be aware that many, probably the majority, of C programs run
on systems without any notion of directories. For example, embedded
processors, but also many mainframe systems. It's only a few months ago
that I was doing some maintenance work on a UNISYS A Series, which has a
flat file system. This is not unusual for mainframes in current use.

C should not be ladened with cruft that simply doesn't make sense on a
large proportion of implementations.

Like _Complex

 

[jacob navia]

Le 25/11/11 21:01, Quentin Pope a écrit :

You may not be aware that many, probably the majority, of C programs run
on systems without any notion of directories.

Where is your data for such sweeping generalizations?

According to several surveys, for instance this one:

http://langpop.com/

C is one of the most popular computer languages ever.
Applications like the linux kernel, many RDBMS like
Sqlite, and a LONG etc disprove your supposition that
C is used in embedded systems where there isn't a file
system.

Again, please show us some realworld DATA to prove
your asserions.

For example, embedded
processors, but also many mainframe systems. It's only a few months ago
that I was doing some maintenance work on a UNISYS A Series, which has a
flat file system. This is not unusual for mainframes in current use.

Well, archaic systems remain, but even there you have partitioned data
sets that are similar to directories in many ways.

You happen to have some history working in some special environments
Please do not generalize to ALL user of the language.

Thanks

 

[Keith Thompson]

On 11/26/11 09:01 AM, Quentin Pope wrote: [...]

C should not be ladened with cruft that simply doesn't make sense on a
large proportion of implementations.

Like _Complex

How does complex arithmetic not make sense on some systems?
It doesn't require any support from the operating system, just some
compiler support for the operators and a few library functions that
can be implemented (mostly?) in portable C.

I think complex numbers were added to the core language because it
would have been difficult or impossible to add them as a library
feature, given that C doesn't have operator overloading.

(To those who think that adding operator overloading would have
been a better solution, I refer you to the previous flame wars.)

 

[Keith Thompson]

I've seen the new standard of C called C1x.
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1250.pdf

http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1570.pdf is a more
recent draft.

They added some great features like anonymous unions and threads. But
there is still no directory management. I think that's very annoying.
Why threads should be added and dirent.h should not ?

<dirent.h> is already standardized by POSIX. Standardizing
directory access for non-POSIX systems is a harder problem than
you might think. A library that's general enough to cover all
relevant systems would probably be substantially less powerful than
the existing system-specific library (dirent for POSIX, whatever
Windows has, etc.).

Threads are also supported by POSIX, but apparently standardizing
threads in a way that could reasonably be supported by all hosted
implementations (or most of them; as I recall it's an optional
feature) apparently wasn't as difficult.

 

[Kaz Kylheku]

Hello,

I've seen the new standard of C called C1x.
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1250.pdf

They added some great features like anonymous unions and threads. But

It's stupid to start adding Unix stuff back to C.

C came from Unix, and the library on Unix didn't really distinguish between
what is part of C, and what is Unix-specific. So two parallel standards efforts
emerged, dividing up the library.

Why start merging it together now?

I haven't looked at the threads in C1X, but it would be ridiculous if it

there is still no directory management. I think that's very annoying.

There is.

Why threads should be added and dirent.h should not ?

There is a <dirent.h> and it's in a set of documents called POSIX.

Doh?

It's already standardized in a document that builds on C.

What would you achieve by putting into the same standard? It would have to be
an optional extension --- exactly what it is now.

 

[Ian Collins]

On 11/26/11 09:01 AM, Quentin Pope wrote: [...]

C should not be ladened with cruft that simply doesn't make sense on a
large proportion of implementations.

Like _Complex

How does complex arithmetic not make sense on some systems?

I didn't say that, but I do maintain that on the majority of systems
where C is used (read embedded, often small), it isn't much use. I'd
even go so far as to say it is of less use than filesystem support.

 

[Markus Wichmann]

Yeah, that appears to be quite stunning. To my knowledge, any OS out
there with multitasking capabilities should have a file system. Or are
there counter examples?

You may not be aware that many, probably the majority, of C programs run
on systems without any notion of directories. For example, embedded
processors, but also many mainframe systems. It's only a few months ago
that I was doing some maintenance work on a UNISYS A Series, which has a
flat file system. This is not unusual for mainframes in current use.

C should not be ladened with cruft that simply doesn't make sense on a
large proportion of implementations.

_Complex was already named. Apart from that, in my (little) experience,
programming for embedded processors takes place in a freestanding
environment, rendering the entire Section 7 useless there (OK, not
entirely, but there isn't much left in a freestanding environment).

What's more: The standard library already contains enough cruft to sink
a cruiser, so I don't get where there should be harm in adding more
stuff. For example, many programs out there do not need <math.h>. Way
less programs need <tgmath.h>. Yet it is there and it contains way more
functions than any program could ever need at once.

If you think mandating the existence of directory listing facilities in
the OS would lessen portability, I think you are wrong. That is because
either there is _any_ kind of file system, then you can enumerate the
files, or there isn't, then you can't. However, in a hosted environment

My 2c.

//QP

HTH,
Markus

 

[Markus Wichmann]

I haven't looked at the threads in C1X, but it would be ridiculous if it
was just a copy of <pthread.h> stuff from POSIX.

It is. Basically, if you prefix every function with "pthread_" and spell
out the second part completely ("cnd" -> "cond", "mtx"->"mutex", etc.)
you get the complete POSIX threads library.

Which is funny, because that itself is a library on Linux, wrapping
around system calls. So, up until now the C library wrapped system
calls, and now the C libary wraps the thread library, which wraps the
system calls. Nice job!

CYA,
Markus

 

[Ben Pfaff]

I've seen the new standard of C called C1x.
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1250.pdf

They added some great features like anonymous unions and threads. But
there is still no directory management. I think that's very annoying.
Why threads should be added and dirent.h should not ?

Threads strike right at the heart of the language. They require
compiler support to have any assurance that they will work
correctly.

In contrast, directory support is just a library.

 

[Richard Damon]

On 11/25/11 5:54 PM, Markus Wichmann wrote:
....

Yeah, that appears to be quite stunning. To my knowledge, any OS out
there with multitasking capabilities should have a file system. Or are
there counter examples?
....


HTH,
Markus

The question comes, do they all support them is a close enough manner
that a usable portable definition could be defined if the standard
extended the current file primitives to directories.

We do already have a POSIX standard which defines this for one major
class of systems. It would NOT make sense to just adopt that for C, as
then suddenly OSes that are NOT POSIX compatible might have a hard time
implementing the standard.

There is nothing wrong in using standards beyond the C standard in
defining your program (as long as they are compatible with it, and you
environment supports it).

This currently means that if you want to use <dirent.h>, you just need
to document that you program requires C/POSIX not just C as the
environment. This also means that you have available everything that
POSIX supplies. If the C standard did adopt a directory library you
would probably be complaining that it doesn't provide enough capability,
as it would be less than what you get from POSIX, and likely to remain
backwards compatible, (avoiding gratuitous incompatibilities with the
POSIX standard), the include file would likely be given a different name
and the functions would have different names.

 

[Malcolm McLean]

You may not be aware that many, probably the majority, of C programs run
on systems without any notion of directories. For example, embedded
processors, but also many mainframe systems. It's only a few months ago
that I was doing some maintenance work on a UNISYS A Series, which has a
flat file system. This is not unusual for mainframes in current use.

C should not be ladened with cruft that simply doesn't make sense on a
large proportion of implementations.

A lot of my programs could be written in pure ANSI C, with the
exception of a couple of calls to directory functions. Or are written
in ANSI C and need the user to create an empty directory and pass a
commandline argument to it.

 

[Seebs]

Yeah, that appears to be quite stunning. To my knowledge, any OS out
there with multitasking capabilities should have a file system. Or are
there counter examples?

File system is... well. Not all filesystems have directory structure as
such, or compatible directory structures. Some embedded systems have
filesystems optional, so whether or not you have anything like that is
variable.

Mostly, though... I think the <dirent.h> approach is probably wrong. Among
other things, consider the mandate of a 32-bit "fileno" which uniquely
identifies a file. There are filesystems on which that may be either very
expensive or impossible.

If you think mandating the existence of directory listing facilities in
the OS would lessen portability, I think you are wrong. That is because
either there is _any_ kind of file system, then you can enumerate the
files, or there isn't, then you can't. However, in a hosted environment
C already mandates the existence of files. (As seen in <stdio.h>)

It doesn't mandate the existence of directories, though. Or indeed the
existence of any *specific* files. So far as I can tell, an implementation
where fopen() always returns NULL could be conforming.

-s

 

[Kleuske]

Yeah, that appears to be quite stunning. To my knowledge, any OS out
there with multitasking capabilities should have a file system. Or are
there counter examples?

http://en.wikipedia.org/wiki/Ucos

There are more OS's like that, some proprietary.

_Complex was already named. Apart from that, in my (little) experience,
programming for embedded processors takes place in a freestanding
environment, rendering the entire Section 7 useless there (OK, not
entirely, but there isn't much left in a freestanding environment).

There's no requirement of using a freestanding implementation.

What's more: The standard library already contains enough cruft to sink
a cruiser, so I don't get where there should be harm in adding more
stuff.

For one, it may be quite tricky to design/specify a common interface for
any number of file-system implementations without reverting to a gretest
common denominator and hence inhibiting native functionality and, again,
many systems don't have one.

Hence it's more convenient, all around, to leave it to the OS-designers
to provide system-specific functionality and interfaces. As does POSIX.

<snip>

 

[Kaz Kylheku]

It is. Basically, if you prefix every function with "pthread_" and spell
out the second part completely ("cnd" -> "cond", "mtx"->"mutex", etc.)
you get the complete POSIX threads library.

That is fucking stupid, but it's what you expect from a committee working on
the N-th revision of a programming language.

 

[James]

It is. Basically, if you prefix every function with "pthread_" and spell
out the second part completely ("cnd" -> "cond", "mtx"->"mutex", etc.)
you get the complete POSIX threads library.

Pthreads does not provide atomic operations and memory barriers. However,
C1X does have them. FINALLY!

[...]

 

[Stephen Sprunk]

Le 25/11/11 21:01, Quentin Pope a écrit :

Where is your data for such sweeping generalizations?

According to several surveys, for instance this one:

http://langpop.com/

The "data" there is completely useless.

C is one of the most popular computer languages ever.

By pretty much any measure, yes. However, popularity is not the claim
in question.

Applications like the linux kernel, many RDBMS like
Sqlite, and a LONG etc disprove your supposition that
C is used in embedded systems where there isn't a file
system.

How does the fact C is used for one thing disprove that it is used for
another thing?

For many embedded systems, the _only_ language available is C, and there
is no OS to speak of. Many don't have file systems at all, and of those
that have file systems, some don't have a concept of directories because
they only need to manage a small (and fixed) set of files.

Embedded systems outnumber hosted systems by at least an order of magnitude.

S

 

[Stefan Ram]

The question comes, do they all support them is a close enough manner
that a usable portable definition could be defined if the standard
extended the current file primitives to directories.

See also:

http://www.purl.org/stefan_ram/pub/c++_standard_extensions_en