reply the answer

[guthena]

Can we write a C programe with out a semicolon ? printing HELLOWORLD !

[Keith Thompson]

Richard Heathfield <rj*@see.sig.in validwrites:
[...]

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.hand <stdbool.h>.

<tgmath.hseem s 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.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Keith Thompson said:

<snip>

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.hand <stdbool.h>.

I hesitated over <stdbool.h>, actually, and I can't say I'm dead set
against it.

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

Right. <tgmath.hhas "special-interest group with lobbying expertise"
written all over it.

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

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Richard Heathfield <rj*@see.sig.in validwrites:

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.c om/text/c0xlongtime.htm l>.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <rj*@see.sig.in validwrites:

>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.c om/text/c0xlongtime.htm l>.

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.programmin g. Maybe later.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Richard Heathfield said:

Keith Thompson said:

<snip>

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

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

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[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!

>Richard Heathfield wrote:

>Harald van D?k said:

>>Richard Heathfield wrote:
Eric Sosman said:
guthena wrote:
>Can we write a C programe with out a semicolon ? printing
>HELLOWOR LD !
>
Yes.

I'm curious. I can see the print part easily enough, but how are you
going to handle the return statement? (Email reply welcome if you
don't want to spoil the OP's fun.)

There is no need for a return statement.

Oh. *That* kind of program. Count me out.

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("HELLOWORL D");
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 "technicall y correct" English; but since when was rock & roll "technicall y 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!

>>Richard Heathfield wrote:

>>>Harald van D?k said:

Richard Heathfield wrote:

>Eric Sosman said:
>
>>guthena wrote:
>>
>>>Can we write a C programe with out a semicolon ? printing
>>>HELLOWOR LD !
>>
> Yes.
>
>I'm curious. I can see the print part easily enough, but how are you
>going to handle the return statement? (Email reply welcome if you
>don't want to spoil the OP's fun.)

There is no need for a return statement.

Oh. *That* kind of program. Count me out.

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

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

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.

--
Er*********@sun .com

[Keith Thompson]

Richard Heathfield <rj*@see.sig.in validwrites:

Keith Thompson said:

>Richard Heathfield <rj*@see.sig.in validwrites:

>>Keith Thompson said:

[...]

>>>Something I'd really like, which didn't make it into C99 is a
replacemen t 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.

[...]

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

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

[...]

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Old Wolf]

phayw...@alphal ink.com.au.NO.S PAM (Peter 'Shaggy' Haywood) wrote:

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 <ks***@mib.orgw rote:

Richard Heathfield <rj*@see.sig.in validwrites:

Keith Thompson said:

Richard Heathfield <rj*@see.sig.in validwrites:
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.

[...]

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.

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