Qry : Behaviour of fgets -- ?

[Richard Bos]

But most of what's suggested for the attributes is non-standardisable
without making life hard for some implementors.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1264.pdf
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1262.pdf

See also
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1259.htm
which refers to
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1233.pdf
which was an earlier edition of N1262.

I see nothing there which convinces me that this would be a good idea.
All the alignment brouhaha is not only inherently unportable, but also
something which 99% of programmers should trust their optimisers on. You
do not want to create another register keyword.
Threading falls outside the scope of the Standard.
Deprecated is exclusively of interest to implementors themselves, and
should never occur outside implementation headers; that can therefore be
handled in an implementation-specific manner in all cases - since those
headers cannot typically be used with other implementations in any case,
it is no loss if those solutions are not portable.

Noreturn _could_ be useful in a very few cases, but is that really
enough reason to complicate the syntax even further?

Richard

 

[Flash Gordon]

Richard Bos wrote, On 28/09/07 10:36:

But most of what's suggested for the attributes is non-standardisable
without making life hard for some implementors.


I see nothing there which convinces me that this would be a good idea.

I've not read those yet, but...

All the alignment brouhaha is not only inherently unportable, but also
something which 99% of programmers should trust their optimisers on. You
do not want to create another register keyword.

I can see that is a risk.

Threading falls outside the scope of the Standard.

Does that always have to be completely the case?

Deprecated is exclusively of interest to implementors themselves, and
should never occur outside implementation headers; that can therefore be
handled in an implementation-specific manner in all cases - since those
headers cannot typically be used with other implementations in any case,
it is no loss if those solutions are not portable.

Deprecated is also useful for the writers of third-party libraries. If,
for example, I wrote a wonderful XML processing library that everybody
used, after a few years I might add some new interfaces to it and
deprecate others. At that point it would be useful to be able to flag
the deprecated functions as being deprecated. Note that XML processing
can be done *entirely* in standard C, so the library could be completely
portable and nothing to do with any specific implementation.

Noreturn _could_ be useful in a very few cases, but is that really
enough reason to complicate the syntax even further?

That, obviously, is open for debate.

 

[Douglas A. Gwyn]

Richard Bos wrote, On 28/09/07 10:36:
Does that always have to be completely the case?

Actually, the C++ and C standards committees are working on
specifications for threading models. The motivation is that
many current applications rely on having multiple threads of
execution, perhaps because genuine IPC is too expensive on
most current platforms. Threads raise a number of issues
about how execution can be interleaved; this wouldn't be of
much concern if programmers always used protective measures
such as locks to serialize access to shared objects, but for
some reason many of them want to omit such mechanisms. It
doesn't help that popular current multiple-core processors
don't have good support for synchronizing memory caches.

 

[Flash Gordon]

Douglas A. Gwyn wrote, On 01/10/07 21:24:

Actually, the C++ and C standards committees are working on
specifications for threading models.

That certainly is interesting, and could motivate people to push for the
new standard to actually be implemented.

most current platforms. Threads raise a number of issues
about how execution can be interleaved; this wouldn't be of
much concern if programmers always used protective measures
such as locks to serialize access to shared objects, but for
some reason many of them want to omit such mechanisms.

I can't speak for others, but I can see the use for something equivalent
to "volatile sig_Atomic_t" so you can write a single small value and
know that the other thread will either see the old or new value and not
some mix of the two. However, for larger values or where there is a
read/modify/write cycle I would expect to have to use some form of locking.

It
doesn't help that popular current multiple-core processors
don't have good support for synchronizing memory caches.

Ouch.

I assume you are also trying to define something that can easily be
implemented on Windows and POSIX without having to change the way the OS
works or have a large "compatibility" layer. Must be quite some challenge.

I could certainly find use for even a simple standardised threading
implementation, so I wish you luck with it.

 

[Richard Bos]

Richard Bos wrote, On 28/09/07 10:36:

I can see that is a risk.


Does that always have to be completely the case?

No, but it would not be a good idea to introduce a new syntax element
for them when threading itself is not yet a part of C. If a new Standard
were to introduce a thorough, well thought out model for threading in C,
and have some of these attributes as part of that, I would have fewer or
possibly no problems with that. But the current proposal is coat first,
body afterwards.

Deprecated is also useful for the writers of third-party libraries. If,
for example, I wrote a wonderful XML processing library that everybody
used, after a few years I might add some new interfaces to it and
deprecate others. At that point it would be useful to be able to flag
the deprecated functions as being deprecated. Note that XML processing
can be done *entirely* in standard C, so the library could be completely
portable and nothing to do with any specific implementation.

Possibly; although in that case you would want a rather more complete
syntax than the proposed one. For example, you'd want to be able to
indicate to the user-programmer both the reason for the deprecation, and
the new, better option.

Richard

 

[Flash Gordon]

Richard Bos wrote, On 10/10/07 12:50:

No, but it would not be a good idea to introduce a new syntax element
for them when threading itself is not yet a part of C. If a new Standard
were to introduce a thorough, well thought out model for threading in C,
and have some of these attributes as part of that, I would have fewer or
possibly no problems with that. But the current proposal is coat first,
body afterwards.

Well, from a post by someone else I gather they are looking at adding
threading to the C standard in some form. However I would point out that
volatile is useful even without the standard defining most of the things
that make it useful. Whether the same applies in this case is another
matter.

Possibly; although in that case you would want a rather more complete
syntax than the proposed one. For example, you'd want to be able to
indicate to the user-programmer both the reason for the deprecation, and
the new, better option.

I've not looked at the proposal to be honest, but something that allows
you to specify a message as a simple string literal would allow you to
do this. Even without it the programmer would (if s/he has any sense,
which is not always the case) know to look at the documentation.