reply the answer

[jaysome]

CBFalconer said:


I don't have the patience to wait that long. Nor do I have the
inclination to use ugly features just because they're legal.

So what you're saying is that C1999--I mean C99--was totally useless
(at least in this instance) in your point of view? If so, I tend to
agree.

Windows Vista, and even Windows XP, has a "Rollback driver" option. Is
there anything similar with respect to ISO/ANSI standards in general,
and the ISO/ANSI C99 standard in specific?

I'd be willing to bet that most regulars in this newsgroup wouldn't
hesitate to click on a button labeled "Rollback Standard Version" when
it comes to C.

 

[Richard Heathfield]

jaysome said:

So what you're saying is that C1999--I mean C99--was totally useless
(at least in this instance) in your point of view? If so, I tend to
agree.

Certainly in this instance, yes. The absence of a return statement from
main makes the program very, very marginally easier to write, at the
expense of being very marginally harder to read. The cost is N * delta
(where N is the number of times the code will be read), and the saving
is a mere 1 * epsilon. The game is not worth the candle.

Windows Vista, and even Windows XP, has a "Rollback driver" option. Is
there anything similar with respect to ISO/ANSI standards in general,
and the ISO/ANSI C99 standard in specific?

Not as far as I'm aware, at least not officially. In practice, that's
what implementors have actually done, for the most part.

I'd be willing to bet that most regulars in this newsgroup wouldn't
hesitate to click on a button labeled "Rollback Standard Version" when
it comes to C.

Here's what I'd have liked C99 to be:

X removal of K&R-style function definitions
X removal of gets
X removal of unadorned %s from *scanf
X #ifntypedef (but at least I understand why I can't have it)
X function without return statement not permitted except where return
type is void
X no changes may invade the user's identifier namespace
X no new headers
X operators for integer power and powmod
X (limited) support for operator overloading perhaps as some kind of
preprocessor step:
e.g. #overload +(bignum b1, bignum2) bignum_add(&b1, &b2)
X a C equivalent of STL - that is, a standard set of routines for
manipulating dynamic strings, arrays, maps, and so on
* removal of implicit int
* compound literals
* support for complex types
* %zu for size_t in printf
* variable argument macros
* trailing comma allowed in enum
* snprintf and vsnprintf
* inline functions
* return without expression not permitted in function that returns a
value (and vice versa)

....and NOTHING ELSE.

Some of these changes are trivial, of course. Others are rather more
wide-ranging, but those are also the ones that I think would have been
most useful to most people. If the effort that had gone into codifying
97,000 pages of mostly useless mathematical features had instead gone
into some of these features, I think we'd have a more dynamic, vibrant
language - and one which implementors just *might* have taken the
trouble to implement.

 

[Keith Thompson]

Here's what I'd have liked C99 to be:

X removal of K&R-style function definitions
X removal of gets
X removal of unadorned %s from *scanf
X #ifntypedef (but at least I understand why I can't have it)
X function without return statement not permitted except where return
type is void
X no changes may invade the user's identifier namespace
X no new headers
X operators for integer power and powmod
X (limited) support for operator overloading perhaps as some kind of
preprocessor step:
e.g. #overload +(bignum b1, bignum2) bignum_add(&b1, &b2)
X a C equivalent of STL - that is, a standard set of routines for
manipulating dynamic strings, arrays, maps, and so on
* removal of implicit int
* compound literals
* support for complex types
* %zu for size_t in printf
* variable argument macros
* trailing comma allowed in enum
* snprintf and vsnprintf
* inline functions
* return without expression not permitted in function that returns a
value (and vice versa)

...and NOTHING ELSE.

Interesting list.

Mine would include long long, and probably extended integer types
(though nobody seems to have bothered implementing the latter). It
would have made more sense to have char=8, short=16, int=32, and
long=64, but too many implementers have refused to do that; long long
is a common extension even without C99.

I'd also include <stdint.h> and <stdbool.h>.

<tgmath.h> seems too complex for the benefit; I'd rather see language
features added to make type-generic math macros/functions possible
within the language.

Something I'd really like, which didn't make it into C99 is a
replacement for <time.h>.

Also, quite a few of the changes in C99 are clarifications of things
that were poorly worded in C90.

 

[Richard Heathfield]

Keith Thompson said:

Interesting list.

Mine would include long long,

I never saw the point of that. If the implementation wants to provide a
64-or-more-bit integer type, it can use long int.

and probably extended integer types
(though nobody seems to have bothered implementing the latter).

Again, no point.

It
would have made more sense to have char=8, short=16, int=32, and
long=64, but too many implementers have refused to do that; long long
is a common extension even without C99.

If only they had called it "very long", I'd perhaps have looked more
kindly on it, despite the namespace invasion it would have represented.

I'd also include <stdint.h> and <stdbool.h>.

<tgmath.h> seems too complex for the benefit; I'd rather see language
features added to make type-generic math macros/functions possible
within the language.

Something I'd really like, which didn't make it into C99 is a
replacement for <time.h>.

Such as? Guaranteed 1-second resolution? Or sub-second? Maybe a decent
way of handling clock() wrap? What did you have in mind?

Also, quite a few of the changes in C99 are clarifications of things
that were poorly worded in C90.

Sure, and I have no problem with a general tightening, although they do
seem to have broken a few things in the process. As you may recall from
a few years back, Lawrence drove a coach and horses through their
redefinition of 'lvalue'.

 

[Keith Thompson]

Keith Thompson said: [...]

Something I'd really like, which didn't make it into C99 is a
replacement for <time.h>.

Such as? Guaranteed 1-second resolution? Or sub-second? Maybe a decent
way of handling clock() wrap? What did you have in mind?

My main concern is completeness. mktime() is the inverse of
localtime(); where's the inverse of gmtime? More support for time
zones would be nice. The trailing '\n' on the result of asctime() is
just silly. The representation of time_t could be specified much
better.

David R. Tribble has an interesting proposal at
<http://david.tribble.com/text/c0xlongtime.html>.

 

[Richard Heathfield]

Keith Thompson said:

Keith Thompson said: [...]

Something I'd really like, which didn't make it into C99 is a
replacement for <time.h>.

Such as? Guaranteed 1-second resolution? Or sub-second? Maybe a
decent way of handling clock() wrap? What did you have in mind?

My main concern is completeness. mktime() is the inverse of
localtime(); where's the inverse of gmtime?

localtime(). At least, it is from where I'm sitting.

More support for time
zones would be nice. The trailing '\n' on the result of asctime() is
just silly.

So is the format. Surely, whoever thought up "Nnn Mmm dd HH:MM:SS YYyy"
has to be completely out to lunch?

The representation of time_t could be specified much better.

Personally, I think it should be an unsigned integer type, with TIME_MAX
reserved for an invalid value, and other values representing the number
of seconds since 1/1/2001. And %tu should be added to *printf.

David R. Tribble has an interesting proposal at
<http://david.tribble.com/text/c0xlongtime.html>.

I took a quick look. I lacked the time to look at it in more detail
because I just blew most of my coffee break on a trivium over in
comp.programming. Maybe later.

 

[Richard Heathfield]

Richard Heathfield said:

Keith Thompson said:


localtime(). At least, it is from where I'm sitting.

Replied too fast. I meant mktime(), of course.

 

[Peter 'Shaggy' Haywood]

Groovy hepcat Harald van =?UTF-8?B?RMSzaw==?= was jivin' on Sun, 24
Jun 2007 17:59:37 +0200 in comp.lang.c.
Re: reply the answer's a cool scene! Dig it!

I'm not sure what you mean by "that" kind. You don't need a return statement
in a strictly conforming C90 program that prints "HELLOWORLD" and exits
successfully.

#include <stdio.h>
#include <stdlib.h>
int main(void) {
puts("HELLOWORLD");
exit(0);
}

That is *not* a C90 conforming program. In C90, a function,
including main(), with non-void return type requires a return
statement. You were thinking, perhaps, of C99?
The above program also does not live up to the specification, which
was to write a program without using a semicolon.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?

 

[Eric Sosman]

Peter 'Shaggy' Haywood wrote On 06/26/07 10:12,:

Groovy hepcat Harald van =?UTF-8?B?RMSzaw==?= was jivin' on Sun, 24
Jun 2007 17:59:37 +0200 in comp.lang.c.
Re: reply the answer's a cool scene! Dig it!




That is *not* a C90 conforming program. In C90, a function,
including main(), with non-void return type requires a return
statement.

Chapter and verse? (In particular, C&V for the case
where, as above, the function does not return at all?)

The above program also does not live up to the specification, which
was to write a program without using a semicolon.

True, but the modification to eliminate the semicolon
is simple. I imagine that "Groovy hepcat Harald" was
reluctant to do *all* of the idiot O.P.'s homework for him.

 

[Keith Thompson]

Keith Thompson said:

Keith Thompson said: [...]
Something I'd really like, which didn't make it into C99 is a
replacement for <time.h>.

Such as? Guaranteed 1-second resolution? Or sub-second? Maybe a
decent way of handling clock() wrap? What did you have in mind?

My main concern is completeness. mktime() is the inverse of
localtime(); where's the inverse of gmtime?

localtime(). At least, it is from where I'm sitting.

(corrected to mktime() in a followup)

Yeah, but if we all sat where you're sitting, it would be pretty darn
crowded.

[...]

Personally, I think it should be an unsigned integer type, with TIME_MAX
reserved for an invalid value, and other values representing the number
of seconds since 1/1/2001. And %tu should be added to *printf.

I don't want time_t to be unsigned. I want it to be able to represent
times in the past, and with a big enough type (64 bits or better), the
top bit is much better spent representing times in the past than in
the unimaginably distant future.

Ideally, I'd like a single arithmetic type that has both as much range
(past an future) and as much precision (nanoseconds?) as you could
want. If that's impractical, I'd settle for a better specified time_t
with 1-second resolution, and something like the Unix gettimeofday()
function for finer precision when it's needed. (gettimeofday() gives
you a structure containing a time_t representing seconds and an
integer representing microseconds.)

[...]

 

[Old Wolf]

In C90, a function, including main(), with non-void return
type requires a return statement.

Not true. (An example of a conforming function
that has no return statement has been posted
on this thread already, for one).

 

[Richard Bos]

Keith Thompson said:

Keith Thompson said:
[...]
Something I'd really like, which didn't make it into C99 is a
replacement for <time.h>.

Such as? Guaranteed 1-second resolution? Or sub-second? Maybe a
decent way of handling clock() wrap? What did you have in mind?

My main concern is completeness. mktime() is the inverse of
localtime(); where's the inverse of gmtime?

localtime(). At least, it is from where I'm sitting.

(corrected to mktime() in a followup)

Yeah, but if we all sat where you're sitting, it would be pretty darn
crowded.

[...]

Personally, I think it should be an unsigned integer type, with TIME_MAX
reserved for an invalid value, and other values representing the number
of seconds since 1/1/2001. And %tu should be added to *printf.

I don't want time_t to be unsigned. I want it to be able to represent
times in the past, and with a big enough type (64 bits or better), the
top bit is much better spent representing times in the past than in
the unimaginably distant future.

Ideally, I'd like a single arithmetic type that has both as much range
(past an future) and as much precision (nanoseconds?) as you could
want. If that's impractical, I'd settle for a better specified time_t
with 1-second resolution, and something like the Unix gettimeofday()
function for finer precision when it's needed. (gettimeofday() gives
you a structure containing a time_t representing seconds and an
integer representing microseconds.)

Bah. Why settle for a today-only solution? We want a type that is able
to represent times very precisely now, for measurement and scientific
purposes. We also want a type that can represent dates far into the past
and future, for historical, geological, and insurance purposes; and we
don't need great precision for these.

I say we opt for a long double, centred on the date at which the new
Standard comes into force.

Richard

 

[Keith Thompson]

Bah. Why settle for a today-only solution? We want a type that is able
to represent times very precisely now, for measurement and scientific
purposes. We also want a type that can represent dates far into the past
and future, for historical, geological, and insurance purposes; and we
don't need great precision for these.

I say we opt for a long double, centred on the date at which the new
Standard comes into force.

A floating-point type? Nah. That means the resolution changes over
time.

Now if we were going to add fixed-point types to the language (which I
wouldn't mind doing), a fixed-point time_t might be a good idea.

I've very tempted to advocate requiring the epoch to be 1970-01-01
00:00:00, just for the sake of compatibility with the most common
practice.

 

[Richard Bos]

A floating-point type? Nah. That means the resolution changes over
time.

Precisely. We want exact measurements, up to nanoseconds if at all
possible, today and for a couple of decades to come. After that, we will
need to have a better time handling system anyway. (We need that today
as well, but we won't have it until this and probably the next decade
has passed.) We want mid-term measurements, exact to a day, for the
middle ages back to, say, Roman times at most. We want exact year counts
back to the earliest written record at least. We want millennium counts,
if that, back in the Triassic. Seems to me that this is the perfect job
for a large floating point number.
(No, I'm not entirely serious. But not _entirely_ jesting, either. I
believe that the argument I'm making is flawless in theory; I also
believe that nobody will accept it, and that it will probably be a pain
in the arse in practice.)

Now if we were going to add fixed-point types to the language (which I
wouldn't mind doing), a fixed-point time_t might be a good idea.

You don't need to make it fixed-point at all. You just need to set the
resolution small enough. A three-decimal fixed-point second count is the
same thing as an integral millisecond count.

I've very tempted to advocate requiring the epoch to be 1970-01-01
00:00:00, just for the sake of compatibility with the most common
practice.

And have the Microserfs and Jobsworths whining? Nah. Let's pick an
egregiously incompatible date, to go with our egregiously incompatible
data type. (Again: HHOS. If you're not going with the POSIX time_t, why
stick to the POSIX epoch? That only leads to confusion. Take your pick
as to which confusion you prefer, that of making a clean break with
POSIX, or that of staying with it halfway.)

Richard

 

[CBFalconer]

(e-mail address removed) (Richard Bos) writes:

.... snip about time format ...

A floating-point type? Nah. That means the resolution changes
over time.

Now if we were going to add fixed-point types to the language
(which I wouldn't mind doing), a fixed-point time_t might be a
good idea.

I've very tempted to advocate requiring the epoch to be
1970-01-01 00:00:00, just for the sake of compatibility with the
most common practice.

Any such case should be based on 1968, 1972, 1900, or even the
mythical year 0, to ease computation of leap years.

 

[Richard Heathfield]

Richard Bos said:

Precisely. We want exact measurements, up to nanoseconds if at all
possible, today and for a couple of decades to come. After that, we
will need to have a better time handling system anyway. (We need that
today as well, but we won't have it until this and probably the next
decade has passed.)

The Planck time is 5.4E-44 seconds. Shorter intervals than this seem
pretty pointless to me, but let's crank it right down to 1E-45, for the
sake of an exact mantissa and an exponent that is a multiple of 3.

The expected lifetime of the universe, according to a not terribly
authoritative source I have on my shelf, is 1E18 seconds if the
universe is closed. I seem to recall that physicists believe the
current age of the universe to be less than 20 US billion years, which
is about 6.31E17 seconds, but let's pretend it's another 1E18. Nice
symmetry - so we'll use a signed type, okay? 0 represents 1/1/1970 or
1/1/1 or whatever the implementor feels like.

Either side of that point, we need to be able to represent 1E63
different states, so altogether that's 1E64 different states.

We can represent that many states in a mere 213 bits (one of which is
the sign bit).

So let's just use a 256-bit signed integer type and be done with it. And
we'll have 43 bits left over for storing stuff like daylight savings
flags, time zones, yadayadayada.

<snip>

 

[Richard Heathfield]

CBFalconer said:

Any such case should be based on 1968, 1972, 1900, or even the
mythical year 0, to ease computation of leap years.

Or we could simply define the Zero Point as the midnight dividing
31 Dec 1 BC from 1 Jan 1 AD.

 

[Keith Thompson]

Keith Thompson wrote: [...]

I've very tempted to advocate requiring the epoch to be
1970-01-01 00:00:00, just for the sake of compatibility with the
most common practice.

Any such case should be based on 1968, 1972, 1900, or even the
mythical year 0, to ease computation of leap years.

Leap year computations are not at all difficult; tweaking the epoch to
make them easier would not be worthwhile. And setting the epoch to
1968 or 1972 wouldn't make the century-based rule any easier.

 

[Dave Vandervies]

You don't need to make it fixed-point at all. You just need to set the
resolution small enough. A three-decimal fixed-point second count is the
same thing as an integral millisecond count.

Not quite. If it's a fixed-point type with a minimum resolution and a
minimum range, it becomes trivial to extend either the resolution or the
range by adding more bits at one end or the other; for a fixed-resolution
tick counter, adding more range is easy (just use a wider type), but
adding more resolution would require going from an integer type to
a floating-(or fixed-)point type, which Would Be Problematic if the
counter were required (by standardization or by custom) to be an integer.


dave

--
Dave Vandervies (e-mail address removed)

"There is no reason for an individual to have a computer in their home." -
Ken Olson, President of DEC, 1977 --JoeB and

I agree with Ken. Peter Corlett in the scary devil monastery

 

[Walter Roberson]

Or we could simply define the Zero Point as the midnight dividing
31 Dec 1 BC from 1 Jan 1 AD.

The year didn't start in January back then. September was
the 7th month, October was the 8th month, November was the 9th
month, December was the 10th month: the year started with March.
(I believe this is why it is February that is the short month:
the extra day for Augustus Caeser to make it equal in length with
Julius Caeser was stolen from the end of the year, February.)