Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Still no dirent.h in C1X

Reply
Thread Tools

Still no dirent.h in C1X

 
 
Lauri Alanko
Guest
Posts: n/a
 
      11-26-2011
In article <(E-Mail Removed)>,
Kaz Kylheku <(E-Mail Removed)> wrote:
> On 2011-11-25, Markus Wichmann <(E-Mail Removed)> 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 ****ing stupid, but it's what you expect from a committee working on
> the N-th revision of a programming language.


Maybe you should read Boehm's "Threads cannot be implemented as a
Library" for some rationale:

http://www.hpl.hp.com/techreports/20...-2004-209.html

The point of thread support in C1X is not the API for spawning threads
and synchronization primitives: that's evidently lifted quite
straightforwardly from pthreads. The point is 5.1.2.4 in N1570.


Lauri
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      11-26-2011
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/conte...pci/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!


 
Reply With Quote
 
 
 
 
André Gillibert
Guest
Posts: n/a
 
      11-27-2011
Quentin Pope <(E-Mail Removed)> 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/wg...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
 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      11-27-2011
Markus Wichmann <(E-Mail Removed)> 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.


No, it is not. It is similar to pthreads, but that's just because it
provides many of the same capabilities. It's also similar to Windows
threads for the same reason. It's intended to be a generic interface
that can be easily implemented on top of any existing thread support
(but particularly POSIX threads and Windows threads).
--
Larry Jones

My brain is trying to kill me. -- Calvin
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-27-2011
On 11/25/2011 06:02 PM, 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.
>
> 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!


For 2/3 of the functions in <threads.h>, I was able to match them up
that way with <pthread.h> functions, with the following exceptions:

From n1570.pdf "Committee Draft — April 12, 2011 ISO/IEC 9899:201x",
section B.25:
> Theads <threads.h>:
> ...
> int mtx_timedlock(mtx_t *restrict mtx,
> const struct timespec *restrict ts);

....
> thrd_t thrd_current(void);

....
> int thrd_sleep(const struct timespec *duration,
> struct timespec *remaining);

....
> void thrd_yield(void);
> int tss_create(tss_t *key, tss_dtor_t dtor);
> void tss_delete(tss_t key);
> void *tss_get(tss_t key);
> int tss_set(tss_t key, void *val);


Could you please identify which <pthread.h> functions correspond to the
above <threads.h> functions?

When I went to http://www3.opengroup.org/unix/, I got the following notice:
> Please note that on Sunday November 27 our servers are undergoing planned maintenance between 00:30 and 10:00 PST and some pages will be temporarily unavailable during that time.


I'm a little two impatient to wait that long. Therefore, for now, I'm
relying upon the contents of pthreads.h on my desktop, which is an
Ubuntu Linux machine. I'm not sure how accurately it conforms to POSIX.
It contains a lot of gcc-specific stuff, which I've removed where I
recognized it. Here's the list of functions prefixed with "pthread_"
that I extracted from that source, excluding those which clearly matched
a <threads.h> function.

> extern pthread_t pthread_self (void) __attribute__ ((const__));
> extern int pthread_attr_init (pthread_attr_t *__attr) ;
> extern int pthread_attr_destroy (pthread_attr_t *__attr);
> extern int pthread_attr_getdetachstate (const pthread_attr_t *__attr,
> int *__detachstate);
> extern int pthread_attr_setdetachstate (pthread_attr_t *__attr,
> int __detachstate);
> extern int pthread_attr_getguardsize (const pthread_attr_t *__attr,
> size_t *__guardsize);
> extern int pthread_attr_setguardsize (pthread_attr_t *__attr,
> size_t __guardsize);
> extern int pthread_attr_getschedparam (const pthread_attr_t *restrict
> __attr,
> struct sched_param *restrict __param);
> extern int pthread_attr_setschedparam (pthread_attr_t *restrict __attr,
> const struct sched_param *restrict
> __param);
> extern int pthread_attr_getschedpolicy (const pthread_attr_t *restrict
> __attr, int *restrict __policy)
> extern int pthread_attr_setschedpolicy (pthread_attr_t *__attr, int __policy);
> extern int pthread_attr_getinheritsched (const pthread_attr_t *restrict
> __attr, int *restrict __inherit);
> extern int pthread_attr_setinheritsched (pthread_attr_t *__attr,
> int __inherit);
> extern int pthread_attr_getscope (const pthread_attr_t *restrict __attr, int *restrict __scope);
> extern int pthread_attr_setscope (pthread_attr_t *__attr, int __scope);
> extern int pthread_attr_getstackaddr (const pthread_attr_t *restrict
> __attr, void **restrict __stackaddr);
> extern int pthread_attr_setstackaddr (pthread_attr_t *__attr,
> void *__stackaddr);
> extern int pthread_attr_getstacksize (const pthread_attr_t *restrict
> __attr, size_t *restrict __stacksize);
> extern int pthread_attr_setstacksize (pthread_attr_t *__attr,
> size_t __stacksize);
> extern int pthread_setschedparam (pthread_t __target_thread, int __policy, const struct sched_param *__param);
> extern int pthread_getschedparam (pthread_t __target_thread,
> int *restrict __policy,
> struct sched_param *restrict __param);
> extern int pthread_setschedprio (pthread_t __target_thread, int __prio);
> extern int pthread_setcancelstate (int __state, int *__oldstate);
> extern int pthread_setcanceltype (int __type, int *__oldtype);
> extern int pthread_cancel (pthread_t __th);
> extern void pthread_testcancel (void);
> extern int pthread_mutex_getprioceiling (const pthread_mutex_t *
> restrict __mutex,
> int *restrict __prioceiling);
> extern int pthread_mutex_setprioceiling (pthread_mutex_t *restrict __mutex,
> int __prioceiling,
> int *restrict __old_ceiling);
> extern int pthread_mutexattr_init (pthread_mutexattr_t *__attr);
> extern int pthread_mutexattr_destroy (pthread_mutexattr_t *__attr);
> extern int pthread_mutexattr_getpshared (const pthread_mutexattr_t *
> restrict __attr,
> int *restrict __pshared);
> extern int pthread_mutexattr_setpshared (pthread_mutexattr_t *__attr,
> int __pshared);
> extern int pthread_mutexattr_getprotocol (const pthread_mutexattr_t *
> restrict __attr,
> int *restrict __protocol));
> extern int pthread_mutexattr_setprotocol (pthread_mutexattr_t *__attr,
> int __protocol);
> extern int pthread_mutexattr_getprioceiling (const pthread_mutexattr_t *
> restrict __attr,
> int *restrict __prioceiling);
> extern int pthread_mutexattr_setprioceiling (pthread_mutexattr_t *__attr,
> int __prioceiling);
> extern int pthread_condattr_init (pthread_condattr_t *__attr);
> extern int pthread_condattr_destroy (pthread_condattr_t *__attr);
> extern int pthread_condattr_getpshared (const pthread_condattr_t *
> restrict __attr,
> int *restrict __pshared);
> extern int pthread_condattr_setpshared (pthread_condattr_t *__attr,
> int __pshared) ;
> extern int pthread_key_create (pthread_key_t *__key,
> void (*__destr_function) (void *));
> extern int pthread_key_delete (pthread_key_t __key);
>
> extern void *pthread_getspecific (pthread_key_t __key);
> extern int pthread_setspecific (pthread_key_t __key,
> const void *__pointer) ;
> extern int pthread_atfork (void (*__prepare) (void),
> void (*__parent) (void),
> void (*__child) (void));


Could you please identify the <threads.h> analogs of those functions?

By my count (and I'll freely admit the possibility of a miscount), there
are 24 functions defined in <threads.h>. I could find no <pthread.h>
analog for 8 of them. I found 61 functions with names starting with
pthread_ in the <pthread.h> on my machine. I could find no <threads.h>
analog for 45 of them. I don't know how many of those might be
extensions to the POSIX standard library. However, your claim that,
simply by modifying the names of the <threads.h> functions, "you get the
complete POSIX threads library." seems very substantially exaggerated.
It doesn't look at all complete to me.
--
James Kuyper
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      11-27-2011
On 2011-11-27, James Kuyper <(E-Mail Removed)> wrote:
> For 2/3 of the functions in <threads.h>, I was able to match them up
> that way with <pthread.h> functions, with the following exceptions:
>
> From n1570.pdf "Committee Draft — April 12, 2011 ISO/IEC 9899:201x",
> section B.25:
>> Theads <threads.h>:
>> ...
>> int mtx_timedlock(mtx_t *restrict mtx,
>> const struct timespec *restrict ts);

> ...


Hi James,

pthread_mutex_timedlock

http://pubs.opengroup.org/onlinepubs...timedlock.html

>> thrd_t thrd_current(void);


pthread_self

> ...
>> int thrd_sleep(const struct timespec *duration,


>> struct timespec *remaining);


nanosleep

> ...
>> void thrd_yield(void);


sched_yield

http://pubs.opengroup.org/onlinepubs...hed_yield.html

>> int tss_create(tss_t *key, tss_dtor_t dtor);
>> void tss_delete(tss_t key);
>> void *tss_get(tss_t key);
>> int tss_set(tss_t key, void *val);


pthread_key_create, pthread_getspecific, etc.

> Could you please identify which <pthread.h> functions correspond to the
> above <threads.h> functions?


As requested.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-27-2011
On 11/27/2011 11:52 AM, Kaz Kylheku wrote:
....
>> Could you please identify which <pthread.h> functions correspond to the
>> above <threads.h> functions?

>
> As requested.


Any comments on the three dozen other pthread_* functions I listed for
which I could not identify any <thread.h> equivalent? The claim that
<threads.h> corresponds to the complete POSIX threads library was made
by Markus, not you, but he hasn't responded yet, and you have.
--
James Kuyper
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      11-27-2011
On 2011-11-27, James Kuyper <(E-Mail Removed)> wrote:
> On 11/27/2011 11:52 AM, Kaz Kylheku wrote:
> ...
>>> Could you please identify which <pthread.h> functions correspond to the
>>> above <threads.h> functions?

>>
>> As requested.

>
> Any comments on the three dozen other pthread_* functions I listed for
> which I could not identify any <thread.h> equivalent?


That's going to be the case because this thread.h is just some toy invention
whereas pthreads is a years-old mature thing that was bred out of real
implementations.

A better way to design a portable threading interface for C would be to take
the subset of POSIX which is matched by <thread.h>, and just refer to the
original document along with the subset.

This way, certain programs with POSIX threads could become ISO C programs
without having to be rewritten.

There are already portable implementations of POSIX threads. If you want POSIX
threads on Win32, you can get it.

Nobody needs new spellings for the same thing.
 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      11-27-2011
Kaz Kylheku <(E-Mail Removed)> wrote:
>
> There are already portable implementations of POSIX threads. If you want POSIX
> threads on Win32, you can get it.


People keep saying that, but no one has yet provided a reference to an
implementation that is usable by normal Windows (Win32) programs. All
the known examples require some sort of POSIX environment (which is
quite reasonable since pthreads are intimately tied to POSIX; C threads
are not).
--
Larry Jones

It's clear I'll never have a career in sports until I learn
to suppress my survival instinct. -- Calvin
 
Reply With Quote
 
Markus Wichmann
Guest
Posts: n/a
 
      11-27-2011
On 27.11.2011 13:45, James Kuyper wrote:
>
> Could you please identify the <threads.h> analogs of those functions?
>
> By my count (and I'll freely admit the possibility of a miscount), there
> are 24 functions defined in <threads.h>. I could find no <pthread.h>
> analog for 8 of them. I found 61 functions with names starting with
> pthread_ in the <pthread.h> on my machine. I could find no <threads.h>
> analog for 45 of them. I don't know how many of those might be
> extensions to the POSIX standard library. However, your claim that,
> simply by modifying the names of the <threads.h> functions, "you get the
> complete POSIX threads library." seems very substantially exaggerated.
> It doesn't look at all complete to me.


There you go! I display my inability to correctly write down my thoughts
and, poof, there is a pedant pointing that out to me. I'm sorry if I
gave you mistaken hope.

<threads.h> is part of the (future) C library, which is kept thin
deliberately. There is of course no way it could ever amount to the same
feature set of pthreads. What I meant to say was that you can really map
each function in <threads.h> to a pthread or other POSIX function. And
that is one-to-one, just so we are on the same page. For instance, file
I/O is not directly mappable one-to-one between standard C and POSIX
(that is, the part of POSIX that is not standard C. The implementation
of those functions amounts to more than just wrapping another function).

In short: You can map any function name in <threads.h> exactly to one of
the functions in <pthread.h> or <sched.h> or <unistd.h> or... That is
not possible the other way round.

I hope that was clear enough.

CYA,
Markus
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
posting history -- wording of C1X sequencing Ersek, Laszlo C Programming 1 09-24-2010 12:43 AM
On alignment (final committee draft for C++0x and n1425 for C1X) Gennaro Prota C++ 2 08-25-2010 11:43 PM
On alignment (final committee draft for C++0x and n1425 for C1X) Gennaro Prota C++ 6 08-25-2010 04:37 PM
improved C1X security Robert Seacord C Programming 7 08-15-2008 10:18 AM
Who knows more information about the next ISO C standard "C1x" ? Royt C Programming 2 03-16-2008 01:05 PM



Advertisments