Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #13855 > unrolled thread

Still no dirent.h in C1X

Back to article view | Back to comp.lang.c

Contents

  Still no dirent.h in C1X David Demelier <demelier.david@gmail.com> - 2011-11-24 04:43 -0800
    Re: Still no dirent.h in C1X Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-24 09:19 -0500
    Re: Still no dirent.h in C1X Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-11-25 20:01 +0000
      Re: Still no dirent.h in C1X Ian Collins <ian-news@hotmail.com> - 2011-11-26 09:03 +1300
        Re: Still no dirent.h in C1X Keith Thompson <kst-u@mib.org> - 2011-11-25 12:18 -0800
          Re: Still no dirent.h in C1X Ian Collins <ian-news@hotmail.com> - 2011-11-26 10:14 +1300
      Re: Still no dirent.h in C1X jacob navia <jacob@spamsink.net> - 2011-11-25 21:18 +0100
        Re: Still no dirent.h in C1X Stephen Sprunk <stephen@sprunk.org> - 2011-11-26 13:23 -0600
          Re: Still no dirent.h in C1X jacob navia <jacob@spamsink.net> - 2011-11-26 23:43 +0100
            Re: Still no dirent.h in C1X Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-12-02 22:26 +0000
              Re: Still no dirent.h in C1X John Tsiombikas <nuclear@member.fsf.org> - 2011-12-02 22:35 +0000
              Re: Still no dirent.h in C1X jacob navia <jacob@spamsink.net> - 2011-12-03 00:51 +0100
      Re: Still no dirent.h in C1X Markus Wichmann <nullplan@gmx.net> - 2011-11-25 23:54 +0100
        Re: Still no dirent.h in C1X Richard Damon <news.x.richarddamon@xoxy.net> - 2011-11-25 20:18 -0500
        Re: Still no dirent.h in C1X Seebs <usenet-nospam@seebs.net> - 2011-11-26 07:21 +0000
        Re: Still no dirent.h in C1X Kleuske <kleuske@nowhere.net> - 2011-11-26 11:27 +0000
      Re: Still no dirent.h in C1X Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-25 22:25 -0800
      Re: Still no dirent.h in C1X André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-11-27 01:13 +0100
    Re: Still no dirent.h in C1X Keith Thompson <kst-u@mib.org> - 2011-11-25 12:24 -0800
    Re: Still no dirent.h in C1X Kaz Kylheku <kaz@kylheku.com> - 2011-11-25 20:38 +0000
      Re: Still no dirent.h in C1X Markus Wichmann <nullplan@gmx.net> - 2011-11-26 00:02 +0100
        Re: Still no dirent.h in C1X Kaz Kylheku <kaz@kylheku.com> - 2011-11-26 17:15 +0000
          Re: Still no dirent.h in C1X Lauri Alanko <la@iki.fi> - 2011-11-26 21:36 +0000
        Re: Still no dirent.h in C1X "James" <no@spam.invalid> - 2011-11-26 10:31 -0800
        Re: Still no dirent.h in C1X lawrence.jones@siemens.com - 2011-11-26 22:13 -0500
        Re: Still no dirent.h in C1X James Kuyper <jameskuyper@verizon.net> - 2011-11-27 07:45 -0500
          Re: Still no dirent.h in C1X Kaz Kylheku <kaz@kylheku.com> - 2011-11-27 16:52 +0000
            Re: Still no dirent.h in C1X James Kuyper <jameskuyper@verizon.net> - 2011-11-27 12:29 -0500
              Re: Still no dirent.h in C1X Kaz Kylheku <kaz@kylheku.com> - 2011-11-27 18:48 +0000
                Re: Still no dirent.h in C1X lawrence.jones@siemens.com - 2011-11-27 16:21 -0500
                  Re: Still no dirent.h in C1X John Tsiombikas <nuclear@member.fsf.org> - 2011-11-28 01:57 +0000
                Re: Still no dirent.h in C1X James Kuyper <jameskuyper@verizon.net> - 2011-11-27 20:04 -0500
                Re: Still no dirent.h in C1X Joshua Maurice <joshuamaurice@gmail.com> - 2011-11-28 13:51 -0800
                  Re: Still no dirent.h in C1X Markus Wichmann <nullplan@gmx.net> - 2011-11-30 16:46 +0100
                    Re: Still no dirent.h in C1X James Kuyper <jameskuyper@verizon.net> - 2011-11-30 11:19 -0500
                      Re: Still no dirent.h in C1X Kaz Kylheku <kaz@kylheku.com> - 2011-11-30 16:51 +0000
                    Re: Still no dirent.h in C1X Joshua Maurice <joshuamaurice@gmail.com> - 2011-11-30 13:12 -0800
                      Re: Still no dirent.h in C1X Ian Collins <ian-news@hotmail.com> - 2011-12-01 10:15 +1300
                        Re: Still no dirent.h in C1X Joshua Maurice <joshuamaurice@gmail.com> - 2011-11-30 13:19 -0800
                        Re: Still no dirent.h in C1X Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-12-01 04:45 +0200
          Re: Still no dirent.h in C1X Markus Wichmann <nullplan@gmx.net> - 2011-11-27 23:30 +0100
            Re: Still no dirent.h in C1X James Kuyper <jameskuyper@verizon.net> - 2011-11-28 06:42 -0500
              Re: Still no dirent.h in C1X Markus Wichmann <nullplan@gmx.net> - 2011-11-28 15:09 +0100
    Re: Still no dirent.h in C1X blp@cs.stanford.edu (Ben Pfaff) - 2011-11-25 15:44 -0800

Page 1 of 3  [1] 2 3  Next page →

#13855 — Still no dirent.h in C1X

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 ?

[toc] | [next] | [standalone]

#13856

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
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#13889

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

[toc] | [prev] | [next] | [standalone]

#13890

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

[toc] | [prev] | [next] | [standalone]

#13893

Ian Collins <ian-news@hotmail.com> 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) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13896

On 11/26/11 09:18 AM, Keith Thompson wrote:
> Ian Collins<ian-news@hotmail.com>  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

[toc] | [prev] | [next] | [standalone]

#13892

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

[toc] | [prev] | [next] | [standalone]

#13925

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

[toc] | [prev] | [next] | [standalone]

#13930

Le 26/11/11 20:23, Stephen Sprunk a écrit :
> 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.
>

OK, OK. That is surely enough. You say that data is "useless"
and that was it. No firther arguments, nothing.


OK, another one is the respected tiobe index

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

C appears in the second position.

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

Obviously directories can ONLY happen to exist in a file system...
For all systems without them it would be very easy to have ONE
huge directory that contains everything if they have the concept of
files at all!


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

So what?

Should we eliminate file i/o because there are a lot of embedded systems
without any files?

Or should we eliminate math.h?

What is the use of having a time.h if the toaster has no clock?

I do not understand the philosophy:

"*I* do not need it therefore feature XXX is useless, just 'cruft'."

And if there are 1 million toasters around who cares?

There is surely 1 dvelopment system and ONE developer for all those!

[toc] | [prev] | [next] | [standalone]

#14244

On Sat, 26 Nov 2011 23:43:47 +0100, jacob navia wrote:
>> Embedded systems outnumber hosted systems by at least an order of
>> magnitude.
> 
> So what?
> 
> Should we eliminate file i/o because there are a lot of embedded systems
> without any files?

I think you have an insular view of the world.

For desktop computing, C is ancient history. Sure it'll be around for a 
while for operating systems and basic command line utilities, but for 
most programming it's just a relic - why would anyone use C for a serious 
program when there's C++ and Java and .NET?

Embedded programming is the only growth area for C. Embedded IS the 
mainstream for C nowadays. But you live in a world where "everything is 
an x86 running Windows" and you can't see the big picture.

> Or should we eliminate math.h?
> 
> What is the use of having a time.h if the toaster has no clock?

No, because these pieces of cruft are now too well established, going all 
the way back to C89. It would have been better if they'd never been 
included in the standard library, but that ship has long since sailed.

But there is no reason to add any more cruft to the standard library that 
would be better being supplied by implementations (maybe through 
standards like POSIX that build on C) WHERE THEY MAKE SENSE on those 
implementations.

> I do not understand the philosophy:
> 
> "*I* do not need it therefore feature XXX is useless, just 'cruft'."
> 
> And if there are 1 million toasters around who cares?
> 
> There is surely 1 dvelopment system and ONE developer for all those!

The C standard library doesn't need to do everything. Other libraries can 
be used too. Something like the directory structure on native filesystems 
is inherently system-specific and non-portable, it has NO PLACE in the C 
standard.

My 2c.

[toc] | [prev] | [next] | [standalone]

#14246

On 2011-12-02, Quentin Pope <qp19433@hotmail.NOSPAM.com> wrote:
>
> For desktop computing, C is ancient history. 

Seeing as more than 90% of the applications I use on my desktop are
written in C I can't see how you could possibly qualify that statement.

> Sure it'll be around for a 
> while for operating systems and basic command line utilities, but for 
> most programming it's just a relic - why would anyone use C for a serious 
> program when there's C++ and Java and .NET?

Because those languages are terrible, especially the last two.
Also what's the definition of a "serious program"?

-- 
John Tsiombikas
http://nuclear.mutantstargoat.com/

[toc] | [prev] | [next] | [standalone]

#14250

Le 02/12/11 23:26, Quentin Pope a écrit :
> On Sat, 26 Nov 2011 23:43:47 +0100, jacob navia wrote:
>
> For desktop computing, C is ancient history. Sure it'll be around for a
> while for operating systems and basic command line utilities, but for
> most programming it's just a relic - why would anyone use C for a serious
> program when there's C++ and Java and .NET?
>

C is still very interesting language. Look at "Quentin Pope", the
anonymous troll in this group. He says:


 > why would anyone use C for a serious
 > program when there's C++ and Java and .NET?

But he does NOT go to a C# or .NET group. He comes to the
C group obviously, since he IS interested in C. :-)

He says that he knows better how the C library should be.

Obviously.

Somebody that says C is "a relic" has surely the know
how and can be taken seriously as to what the future directions
of the language should be.

[toc] | [prev] | [next] | [standalone]

#13899

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

[toc] | [prev] | [next] | [standalone]

#13902

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.

[toc] | [prev] | [next] | [standalone]

#13910

On 2011-11-25, Markus Wichmann <nullplan@gmx.net> 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 / usenet-nospam@seebs.net
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.

[toc] | [prev] | [next] | [standalone]

#13917

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

[toc] | [prev] | [next] | [standalone]

#13905

On Nov 25, 10:01 pm, Quentin Pope <qp19...@hotmail.NOSPAM.com> 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.

[toc] | [prev] | [next] | [standalone]

#13937

Quentin Pope <qp19433@hotmail.NOSPAM.com> 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.

And on many embedded systems where no full OS is started, no file
system is implemented and fopen don't make sense either.

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

In that case, opendir()/readdir()/closedir() might still be
implemented on a flat root directory, and mkdir(2) would always fail,
unless listing is not possible.

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

It also makes sense on a large proportion of implementations. Having a
standard way to support directories is useful on these implementations.
Fortunately, as Kaz Kylheku told, we already have POSIX and there is
no need to merge C and POSIX.

-- 
André Gillibert

[toc] | [prev] | [next] | [standalone]

#13894

David Demelier <demelier.david@gmail.com> 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) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13895

On 2011-11-24, David Demelier <demelier.david@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web