Still no dirent.h in C1X

Discussion in 'C Programming' started by David Demelier, Nov 24, 2011.

  1. 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 ?
    David Demelier, Nov 24, 2011
    #1
    1. Advertising

  2. David Demelier

    Eric Sosman Guest

    On 11/24/2011 7:43 AM, David Demelier wrote:
    >
    > 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.

    --
    Eric Sosman
    d
    Eric Sosman, Nov 24, 2011
    #2
    1. Advertising

  3. David Demelier

    Quentin Pope Guest

    On Thu, 24 Nov 2011 04:43:26 -0800, David Demelier wrote:
    > 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
    Quentin Pope, Nov 25, 2011
    #3
  4. David Demelier

    Ian Collins Guest

    On 11/26/11 09:01 AM, Quentin Pope wrote:
    > On Thu, 24 Nov 2011 04:43:26 -0800, David Demelier wrote:
    >> 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.


    Like _Complex :)

    --
    Ian Collins
    Ian Collins, Nov 25, 2011
    #4
  5. David Demelier

    jacob navia Guest

    Le 25/11/11 21:01, Quentin Pope a écrit :
    > On Thu, 24 Nov 2011 04:43:26 -0800, David Demelier wrote:
    >> 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.


    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


    > C should not be ladened with cruft that simply doesn't make sense on a
    > large proportion of implementations.
    >
    > My 2c.
    >
    > //QP
    jacob navia, Nov 25, 2011
    #5
  6. Ian Collins <> writes:
    > 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 (The_Other_Keith) <http://www.ghoti.net/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 25, 2011
    #6
  7. David Demelier <> writes:
    > 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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 25, 2011
    #7
  8. David Demelier

    Kaz Kylheku Guest

    On 2011-11-24, David Demelier <> wrote:
    > 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
    was just a copy of <pthread.h> stuff from POSIX.

    > 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.
    Kaz Kylheku, Nov 25, 2011
    #8
  9. David Demelier

    Ian Collins Guest

    On 11/26/11 09:18 AM, Keith Thompson wrote:
    > Ian Collins<> writes:
    >> 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.

    --
    Ian Collins
    Ian Collins, Nov 25, 2011
    #9
  10. On 25.11.2011 21:01, Quentin Pope wrote:
    > On Thu, 24 Nov 2011 04:43:26 -0800, David Demelier wrote:
    >> 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 ?

    >


    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
    C already mandates the existence of files. (As seen in <stdio.h>)

    > My 2c.
    >
    > //QP


    HTH,
    Markus
    Markus Wichmann, Nov 25, 2011
    #10
  11. On 25.11.2011 21:38, Kaz Kylheku wrote:
    > 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
    Markus Wichmann, Nov 25, 2011
    #11
  12. David Demelier

    Ben Pfaff Guest

    David Demelier <> writes:

    > 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.
    --
    Go not to Usenet for counsel, for they will say both no and yes.
    Ben Pfaff, Nov 25, 2011
    #12
  13. 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.
    Richard Damon, Nov 26, 2011
    #13
  14. On Nov 25, 10:01 pm, Quentin Pope <> wrote:
    >
    > 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.
    Malcolm McLean, Nov 26, 2011
    #14
  15. David Demelier

    Seebs Guest

    On 2011-11-25, 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?


    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
    --
    Copyright 2011, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Nov 26, 2011
    #15
  16. David Demelier

    Kleuske Guest

    On Fri, 25 Nov 2011 23:54:01 +0100, Markus Wichmann saw fit to publish the
    following:

    > On 25.11.2011 21:01, Quentin Pope wrote:
    >> On Thu, 24 Nov 2011 04:43:26 -0800, David Demelier wrote:
    >>> 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 ?

    >>
    >>

    > 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.

    <snip>

    >> 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).


    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>

    --
    Violence in reality is quite different from theory.
    -- Spock, "The Cloud Minders", stardate 5818.4
    Kleuske, Nov 26, 2011
    #16
  17. David Demelier

    Kaz Kylheku Guest

    On 2011-11-25, Markus Wichmann <> wrote:
    > On 25.11.2011 21:38, Kaz Kylheku wrote:
    >> 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.


    That is fucking stupid, but it's what you expect from a committee working on
    the N-th revision of a programming language.
    Kaz Kylheku, Nov 26, 2011
    #17
  18. David Demelier

    James Guest

    "Markus Wichmann" <> wrote in message
    news:...
    > On 25.11.2011 21:38, Kaz Kylheku wrote:
    >> 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.


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

    [...]
    James, Nov 26, 2011
    #18
  19. On 25-Nov-11 14:18, jacob navia wrote:
    > 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/


    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

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Nov 26, 2011
    #19
  20. David Demelier

    Stefan Ram Guest

    Stefan Ram, Nov 26, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Martin Pohlack

    sizeof(struct dirent.d_ino)

    Martin Pohlack, Sep 8, 2003, in forum: C Programming
    Replies:
    19
    Views:
    1,071
    Keith Thompson
    Sep 10, 2003
  2. **--> That Guy Downstairs
    Replies:
    14
    Views:
    730
    S7Solutions
    Feb 21, 2006
  3. Dirent.h

    , Feb 26, 2006, in forum: C++
    Replies:
    3
    Views:
    723
    Larry I Smith
    Feb 26, 2006
  4. Replies:
    9
    Views:
    508
    P.J. Plauger
    May 10, 2006
  5. Royt
    Replies:
    2
    Views:
    758
    llothar
    Mar 16, 2008
Loading...

Share This Page