By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,786 Members | 2,241 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,786 IT Pros & Developers. It's quick & easy.

main() in C90

P: n/a
Hi, in C90 is "int main()" valid, the same as "int main(void)" and "int
main(int argc, char *argv[])"?
AFAIK in C99 only "int main(void)" and "int main(int argc, char *argv[])
- and the **argv syntax" are the only valid ones.
Jan 16 '08 #1
Share this Question
Share on Google+
80 Replies


P: n/a
In article <fm***********@ulysses.noc.ntua.gr>,
Ioannis Vranos <jo**@no.spamwrote:
>Hi, in C90 is "int main()" valid, the same as "int main(void)" and "int
main(int argc, char *argv[])"?
>AFAIK in C99 only "int main(void)" and "int main(int argc, char *argv[])
- and the **argv syntax" are the only valid ones.
The relevant rules did not change between C90 and C99. Both permit
"or equivilents".

C99 still permits the old style non-prototype definition of functions:
e.g.,

int foo(bar)
int bar;
{ ... }

is still accepted as well as the newer

int foo(int bar) { ... }

Using (void) in a function declaration or definition
signals lack of parameters, and by transforming back to the old style,
int main(void) would be equivilent to

int main( /* no parameters here */ )
/* no declarations here */

which is more simply written int main()
What is -not- still valid in C99 would be to leave out the int part:
functions no longer default to int return type if no return type
is specified.
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers
Jan 16 '08 #2

P: n/a
Ioannis Vranos said:
Hi, in C90 is "int main()" valid,
Yes. It is also valid in C99.
the same as "int main(void)" and "int
main(int argc, char *argv[])"?
Yes, those are both valid in C90 and in C99.
AFAIK in C99 only "int main(void)" and "int main(int argc, char *argv[])
- and the **argv syntax" are the only valid ones.
No, int main() is also valid.

Also, any exact equivalent of any of the above is also valid. For example:

typedef int cat;
typedef char **mouse;

cat main(cat run, mouse hide)
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jan 16 '08 #3

P: n/a
Richard Heathfield <rj*@see.sig.invalidwrites:
Ioannis Vranos said:
>Hi, in C90 is "int main()" valid,

Yes. It is also valid in C99.
>the same as "int main(void)" and "int
main(int argc, char *argv[])"?

Yes, those are both valid in C90 and in C99.
>AFAIK in C99 only "int main(void)" and "int main(int argc, char *argv[])
- and the **argv syntax" are the only valid ones.

No, int main() is also valid.

Also, any exact equivalent of any of the above is also valid. For example:

typedef int cat;
typedef char **mouse;

cat main(cat run, mouse hide)
The wording in C99 is such that an argument could be made that "int
main()" is not valid. But there's considerable evidence that authors
of the standard intended it to be valid. See
<http://groups.google.com/group/comp.std.c/browse_thread/thread/fef53cc781d555a4/2d61b64c0ee672e3>
if you're really bored, or want to be.

In practice, "int main() { /* ... */ }" is ok, but IMHO
"int main(void) { /* ... */ }" is stylistically better because it's
more explicit.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jan 16 '08 #4

P: n/a
On Wed, 16 Jan 2008 20:35:43 +0000 (UTC), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote in comp.lang.c:
In article <fm***********@ulysses.noc.ntua.gr>,
Ioannis Vranos <jo**@no.spamwrote:
Hi, in C90 is "int main()" valid, the same as "int main(void)" and "int
main(int argc, char *argv[])"?
AFAIK in C99 only "int main(void)" and "int main(int argc, char *argv[])
- and the **argv syntax" are the only valid ones.

The relevant rules did not change between C90 and C99. Both permit
"or equivilents".

C99 still permits the old style non-prototype definition of functions:
e.g.,

int foo(bar)
int bar;
{ ... }

is still accepted as well as the newer

int foo(int bar) { ... }

Using (void) in a function declaration or definition
signals lack of parameters, and by transforming back to the old style,
int main(void) would be equivilent to

int main( /* no parameters here */ )
/* no declarations here */

which is more simply written int main()
Not quite right. There is a difference between:

type func_name()

....and:

type func_name(void)

....in both function declarations that are definitions as well, and in
function declarations that are not definitions.

In terms of a function declaration that defines the function, empty
parentheses tell the compiler when compiling the body of the function
that it accepts no parameters.

But regardless of whether the declaration is a definition or not, the
empty parentheses do not provide a prototype, and only specify that
the function accepts an unspecified but fixed number and type of
parameters.
What is -not- still valid in C99 would be to leave out the int part:
functions no longer default to int return type if no return type
is specified.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Jan 16 '08 #5

P: n/a
Keith Thompson <ks***@mib.orgwrites:
[...]
In practice, "int main() { /* ... */ }" is ok, but IMHO
"int main(void) { /* ... */ }" is stylistically better because it's
more explicit.
Here's another reason to prefer "int main(void)" rather than "int main()"
(though it's not a *great* reason).

This:

int main(void) {
main(42);
return 0;
}

requires a diagnostic on the recursive call, whereas this:

int main() {
main(42);
return 0;
}

doesn't. In practice, this matters only if you call main(), which is
almost always a bad idea anyway. Note that the call to main() could
be from another function rather than from main() itself.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jan 17 '08 #6

P: n/a
On Wed, 16 Jan 2008 22:15:29 +0200, Ioannis Vranos wrote:
Hi, in C90 is "int main()" valid, the same as "int main(void)" and "int
main(int argc, char *argv[])"?
AFAIK in C99 only "int main(void)" and "int main(int argc, char *argv[])
- and the **argv syntax" are the only valid ones.
In reality, "void main()" is also valid.

Some compilers issue a warning for this, but you can safely ignore this
warning in 99.999999% or six sigma of the time.

You're more likely to be struck by lightning than come across a compiler
that does not both accept and work with no problems with "void main()".

Microsoft supports "void main()", so that should tell you something,
provided you're living in the real world, of course.

--
Billy
Jan 17 '08 #7

P: n/a
On Wed, 16 Jan 2008 14:17:56 -0800, Keith Thompson wrote:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Ioannis Vranos said:
>>Hi, in C90 is "int main()" valid,

Yes. It is also valid in C99.
>>the same as "int main(void)" and "int main(int argc, char *argv[])"?

Yes, those are both valid in C90 and in C99.
>>AFAIK in C99 only "int main(void)" and "int main(int argc, char
*argv[]) - and the **argv syntax" are the only valid ones.

No, int main() is also valid.

Also, any exact equivalent of any of the above is also valid. For
example:

typedef int cat;
typedef char **mouse;

cat main(cat run, mouse hide)

The wording in C99 is such that an argument could be made that "int
main()" is not valid. But there's considerable evidence that authors of
the standard intended it to be valid.
How credible should we consider this evidence, given that the same
authors put gets() in the standard?

--
Billy, alternate Juror #1
Jan 17 '08 #8

P: n/a
Billy Bong <bi**********@aol.comwrote:
On Wed, 16 Jan 2008 22:15:29 +0200, Ioannis Vranos wrote:
Hi, in C90 is "int main()" valid, the same as "int main(void)" and "int
main(int argc, char *argv[])"?

AFAIK in C99 only "int main(void)" and "int main(int argc, char *argv[])
- and the **argv syntax" are the only valid ones.
You've forgotten a variation. In C89, main() is also valid, as an
old-style declaration. I'm not sure about main(void) and main(int argc,
char **argv), since they seem to be a mix of old-style and prototype,
but since they're perverse anyway I'm not going to look it up. Any of
those are, in any case, not allowed under C99.
In reality, "void main()" is also valid.
No, it isn't. It may be widely accepted, but then, so is jaywalking.
Some compilers issue a warning for this, but you can safely ignore this
warning in 99.999999% or six sigma of the time.
You've never run a program from a makefile.
Microsoft supports "void main()",
Micro$oft supports

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)

which tells you all you need to know about assuming that Micro$oft cares
about reasonable, legible code.

Richard
Jan 17 '08 #9

P: n/a
Richard Bos said:

<snip>
In C89, main() is also valid, as an
old-style declaration. I'm not sure about main(void) and main(int argc,
char **argv)
They are both legal in C89, being exact equivalents of their explicit int
counterparts.

[...] Any of those are, in any case, not allowed under C99.
Right.

<snip>

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

P: n/a
In article <47*****************@news.xs4all.nl>, Richard Bos
<rl*@hoekstra-uitgeverij.nlwrites
>Billy Bong <bi**********@aol.comwrote:
>On Wed, 16 Jan 2008 22:15:29 +0200, Ioannis Vranos wrote:
Hi, in C90 is "int main()" valid, the same as "int main(void)" and "int
main(int argc, char *argv[])"?

AFAIK in C99 only "int main(void)" and "int main(int argc, char *argv[])
- and the **argv syntax" are the only valid ones.

You've forgotten a variation. In C89, main() is also valid, as an
old-style declaration. I'm not sure about main(void) and main(int argc,
char **argv), since they seem to be a mix of old-style and prototype,
but since they're perverse anyway I'm not going to look it up. Any of
those are, in any case, not allowed under C99.
>In reality, "void main()" is also valid.

No, it isn't. It may be widely accepted, but then, so is jaywalking.
The only place void main() is should to be valid is in a self
hosted/freestanding (usually) embedded system where there is no RTOS or
in deed anything to return to. Otherwise it should be int main(.....
>Microsoft supports "void main()",

Micro$oft supports

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)

which tells you all you need to know about assuming that Micro$oft cares
about reasonable, legible code.
Or standards for that matter.

How many M$ Engineers does it take to change a light bulb..... :-)


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 17 '08 #11

P: n/a
Chris Hills said:
In article <47*****************@news.xs4all.nl>, Richard Bos
<rl*@hoekstra-uitgeverij.nlwrites
<snip>
>>Micro$oft supports

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)

which tells you all you need to know about assuming that Micro$oft cares
about reasonable, legible code.

Or standards for that matter.
What's non-standard about it? It looks to me like a perfectly good C
program entry point for a freestanding implementation.

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

P: n/a
Billy Bong <bi**********@aol.comwrites:
On Wed, 16 Jan 2008 14:17:56 -0800, Keith Thompson wrote:
[...]
>The wording in C99 is such that an argument could be made that "int
main()" is not valid. But there's considerable evidence that authors of
the standard intended it to be valid.

How credible should we consider this evidence, given that the same
authors put gets() in the standard?
The authors of the standard didn't invent gets(). It was existing
practice at the time the standard was first developed. I'm not saying
that including it in the standard was a good idea, but dropping it
would not have been easy. And it's finally been deprecated in C99 TC3
(better late than never).

The evidence includes statements in the thread I cited by at least one
committee member (which was more about fixing some unclear wording
than about questioning the actual intent).

If you want to discount the credibility of the committee because of
one unsafe function (which nobody is actually required to use), that's
up to you.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jan 17 '08 #13

P: n/a
On Thu, 17 Jan 2008 09:30:25 -0600, Keith Thompson wrote
(in article <87************@kvetch.smov.org>):
Billy Bong <bi**********@aol.comwrites:
>On Wed, 16 Jan 2008 14:17:56 -0800, Keith Thompson wrote:
[...]
>>The wording in C99 is such that an argument could be made that "int
main()" is not valid. But there's considerable evidence that authors of
the standard intended it to be valid.

How credible should we consider this evidence, given that the same
authors put gets() in the standard?

The authors of the standard didn't invent gets(). It was existing
practice at the time the standard was first developed. I'm not saying
that including it in the standard was a good idea, but dropping it
would not have been easy. And it's finally been deprecated in C99 TC3
(better late than never).
Yeah, one sentence, without adornment, 7.26.9, that reads:
"The gets function is obsolescent, and is deprecated."

How bold.

Earlier they provide all of this, presumably so the Forward reference
can be added.

7.19.7.7 The gets function

Synopsis

1 #include <stdio.h>
char *gets(char *s);

Description

2 The gets function reads characters from the input stream pointed
to by stdin, into the array pointed to by s, until end-of-le is
encountered or a new-line character is read. Any new-line
character is discarded, and a null character is written
immediately after the last character read into the array.

Returns

3 The gets function returns s if successful. If end-of-le is
encountered and no characters have been read into the array, the
contents of the array remain unchanged and a null pointer is
returned. If a read error occurs during the operation, the array
contents are indeterminate and a null pointer is returned.

Forward references: future library directions (7.26.9).
Note: they didn't mention anything about why not to use it, what
dangers it might have, or even flag it as deprecated in the main
function description. Hardly the flashing warning light it deserves.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Jan 17 '08 #14

P: n/a
Randy Howard wrote:
>
Note: they didn't mention anything about why not to use it, what
dangers it might have, or even flag it as deprecated in the main
function description. Hardly the flashing warning light it deserves.
The asctime() function will make a buffer overflow for any
year/month/date that is out of range but they failed to specify
valid ranges.

When I complained about this they pointed me to a decision where they
said that "corrupting memory can happen" and refused to fix this.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 17 '08 #15

P: n/a

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:47*****************@news.xs4all.nl...
Billy Bong <bi**********@aol.comwrote:
>On Wed, 16 Jan 2008 22:15:29 +0200, Ioannis Vranos wrote:
Hi, in C90 is "int main()" valid, the same as "int main(void)" and "int
main(int argc, char *argv[])"?

AFAIK in C99 only "int main(void)" and "int main(int argc, char
*argv[])
- and the **argv syntax" are the only valid ones.

You've forgotten a variation. In C89, main() is also valid, as an
old-style declaration. I'm not sure about main(void) and main(int argc,
char **argv), since they seem to be a mix of old-style and prototype,
but since they're perverse anyway I'm not going to look it up. Any of
those are, in any case, not allowed under C99.
>In reality, "void main()" is also valid.

No, it isn't. It may be widely accepted, but then, so is jaywalking.
I found it odd that "void main()" gets 5 times as many hits on Google as
"int main(void)".

Might be easier to change the Standard than those 3 million references.

Bart
Jan 17 '08 #16

P: n/a
On Thu, 17 Jan 2008 10:28:09 -0600, jacob navia wrote
(in article <fm**********@aioe.org>):
Randy Howard wrote:
>>
Note: they didn't mention anything about why not to use it, what
dangers it might have, or even flag it as deprecated in the main
function description. Hardly the flashing warning light it deserves.

The asctime() function will make a buffer overflow for any
year/month/date that is out of range but they failed to specify
valid ranges.

When I complained about this they pointed me to a decision where they
said that "corrupting memory can happen" and refused to fix this.
Was this an official response, or something from a thread in
comp.std.c?

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Jan 17 '08 #17

P: n/a
In article <00*****************************@news.verizon.net> ,
Randy Howard <ra*********@FOOverizonBAR.netwrote:
>The authors of the standard didn't invent gets(). It was existing
practice at the time the standard was first developed. I'm not saying
that including it in the standard was a good idea, but dropping it
would not have been easy. And it's finally been deprecated in C99 TC3
(better late than never).
>Yeah, one sentence, without adornment, 7.26.9, that reads:
"The gets function is obsolescent, and is deprecated."

How bold.
It's a standard, not a user guide. The people who need warning about
gets() are not likely to be looking in the standard for guidance.

And of course the Rationale explains what's wrong with it.

-- Richard
--
:wq
Jan 17 '08 #18

P: n/a
In article <lv******************@text.news.blueyonder.co.uk >,
Bart C <bc@freeuk.comwrote:
>No, it isn't. It may be widely accepted, but then, so is jaywalking.
Jaywalking is not illegal, at least in this country. It's more or
less the opposite of "void main()": legal but unsafe.
>I found it odd that "void main()" gets 5 times as many hits on Google as
"int main(void)".
Googling for "void main()" is identical to googling for "void main".

Two thirds of them are in fact "static void main", so they are probably
not C code at all.
>Might be easier to change the Standard than those 3 million references.
I found zillions of references to Al Gore saying he invented the
Internet. Perhaps we should get him to say it, so they'd be true.

-- Richard
--
:wq
Jan 17 '08 #19

P: n/a
On Thu, 17 Jan 2008 16:37:53 +0000, Randy Howard wrote:
On Thu, 17 Jan 2008 10:28:09 -0600, jacob navia wrote (in article
<fm**********@aioe.org>):
>The asctime() function will make a buffer overflow for any
year/month/date that is out of range but they failed to specify valid
ranges.

When I complained about this they pointed me to a decision where they
said that "corrupting memory can happen" and refused to fix this.

Was this an official response, or something from a thread in comp.std.c?
The official response is in DR #217, at
<http://open-std.org/JTC1/SC22/WG14/www/docs/dr_217.htm>

At the very least, in my opinion, the description for asctime() should
have been updated so that it's clear that there are valid times for which
it is not guaranteed to work.
Jan 17 '08 #20

P: n/a
On Thu, 17 Jan 2008 16:37:37 GMT, "Bart C" <bc@freeuk.comwrote:
>
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:47*****************@news.xs4all.nl...
>Billy Bong <bi**********@aol.comwrote:
>>On Wed, 16 Jan 2008 22:15:29 +0200, Ioannis Vranos wrote:

Hi, in C90 is "int main()" valid, the same as "int main(void)" and "int
main(int argc, char *argv[])"?

AFAIK in C99 only "int main(void)" and "int main(int argc, char
*argv[])
- and the **argv syntax" are the only valid ones.

You've forgotten a variation. In C89, main() is also valid, as an
old-style declaration. I'm not sure about main(void) and main(int argc,
char **argv), since they seem to be a mix of old-style and prototype,
but since they're perverse anyway I'm not going to look it up. Any of
those are, in any case, not allowed under C99.
>>In reality, "void main()" is also valid.

No, it isn't. It may be widely accepted, but then, so is jaywalking.

I found it odd that "void main()" gets 5 times as many hits on Google as
"int main(void)".
Is that the new standard of correctness?
>
Did you notice that the majority of the hits, at least in the first
three pages, say that the usage is incorrect?

--
Al Balmer
Sun City, AZ
Jan 17 '08 #21

P: n/a
On Thu, 17 Jan 2008 07:08:17 +0000, Billy Bong wrote:
In reality, "void main()" is also valid.

Some compilers issue a warning for this, but you can safely ignore this
warning in 99.999999% or six sigma of the time.

You're more likely to be struck by lightning than come across a compiler
that does not both accept and work with no problems with "void main()".
void main() will be rejected by gcc when compiling with the options
-pedantic-errors -Wall
which I normally do for my own code. I haven't been struck by lightning
yet.
Jan 17 '08 #22

P: n/a

"Richard Tobin" <ri*****@cogsci.ed.ac.ukwrote in message
news:fm***********@pc-news.cogsci.ed.ac.uk...
In article <lv******************@text.news.blueyonder.co.uk >,
Bart C <bc@freeuk.comwrote:
>>I found it odd that "void main()" gets 5 times as many hits on Google as
"int main(void)".

Googling for "void main()" is identical to googling for "void main".

Two thirds of them are in fact "static void main", so they are probably
not C code at all.
Maybe not. But the rest would still outnumber "int main(void)" :-)

If it is in fact that common an error, and is tolerated by compilers, then
why not just allow it? It would mean 'I'm declaring a main() function that
takes no parameters and doesn't explicitly return any value'. The compiler
can stick a return value in there if it likes.
>
>>Might be easier to change the Standard than those 3 million references.

I found zillions of references to Al Gore saying he invented the
Internet. Perhaps we should get him to say it, so they'd be true.
100 years from now it might well be true..

--
Bart
Jan 17 '08 #23

P: n/a
Richard Tobin wrote:
In article <00*****************************@news.verizon.net> ,
Randy Howard <ra*********@FOOverizonBAR.netwrote:
>>The authors of the standard didn't invent gets(). It was existing
practice at the time the standard was first developed. I'm not saying
that including it in the standard was a good idea, but dropping it
would not have been easy. And it's finally been deprecated in C99 TC3
(better late than never).
>Yeah, one sentence, without adornment, 7.26.9, that reads:
"The gets function is obsolescent, and is deprecated."

How bold.

It's a standard, not a user guide. The people who need warning about
gets() are not likely to be looking in the standard for guidance.

And of course the Rationale explains what's wrong with it.

-- Richard
The why did they leave it in the standard?
Why they refuse to fix asctime()'s buffer overflow?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 17 '08 #24

P: n/a
Richard Heathfield wrote:
>>
Why not fixing it?

Because it's not broken.
You can't read?
int tm_year; // years since 1900
And where it says that should be smaller than 8099 ???

NOWHERE.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 17 '08 #25

P: n/a
On Thu, 17 Jan 2008 23:28:55 +0100, jacob navia <ja***@nospam.com>
wrote:
>Richard Heathfield wrote:
>>>
Why not fixing it?

Because it's not broken.

You can't read?
int tm_year; // years since 1900

And where it says that should be smaller than 8099 ???

NOWHERE.
What's 8099 + 1900?

--
Al Balmer
Sun City, AZ
Jan 18 '08 #26

P: n/a
jacob navia <ja***@nospam.comwrites:
Richard Tobin wrote:
>In article <00*****************************@news.verizon.net> ,
Randy Howard <ra*********@FOOverizonBAR.netwrote:
>>>The authors of the standard didn't invent gets(). It was existing
practice at the time the standard was first developed. I'm not saying
that including it in the standard was a good idea, but dropping it
would not have been easy. And it's finally been deprecated in C99 TC3
(better late than never).
>>Yeah, one sentence, without adornment, 7.26.9, that reads:
"The gets function is obsolescent, and is deprecated."

How bold.

It's a standard, not a user guide. The people who need warning about
gets() are not likely to be looking in the standard for guidance.

And of course the Rationale explains what's wrong with it.
The why did they leave it in the standard?
Why they refuse to fix asctime()'s buffer overflow?
Why are you asking us?

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jan 18 '08 #27

P: n/a
jacob navia said:
Richard Heathfield wrote:
>>>
Why not fixing it?

Because it's not broken.

You can't read?
It isn't me who can't read. Look at Harald van Dijk's reply (parallel to
yours) for an example of how to disagree with people without being an
idiot about it.

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

P: n/a
Richard Heathfield wrote:
jacob navia said:
>Richard Heathfield wrote:
>>>Why not fixing it?
Because it's not broken.
You can't read?

It isn't me who can't read. Look at Harald van Dijk's reply (parallel to
yours) for an example of how to disagree with people without being an
idiot about it.
Angry Your Majesty?

I am sorry but I do not care.

You argue that a user of the standard should
know how to avoid buffer overflows by carefully
avoiding any input to a badly designed software
by ensuring that the input doesn't exceed
unspecified limits.

GREAT!

And you agree with the committee that any error should be
rewarded with a buffer overflow ("corrupting memory" as they
call it), without any problems.

GREAT!

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 18 '08 #29

P: n/a
[asctime]

jacob navia said:

<snip>
You argue that a user of the standard should
know how to avoid buffer overflows
Right.
by carefully
avoiding any input to a badly designed software
by ensuring that the input doesn't exceed
unspecified limits.
The limits can be deduced from information published in the Standard.
And you agree with the committee that any error should be
rewarded with a buffer overflow ("corrupting memory" as they
call it), without any problems.
I agree with sensible programmers who ensure that the input they provide to
a standard library function is appropriate to that function. Writing a
validation wrapper for asctime is trivial. ISO C implementations provide
us with a considerable degree of expressive power with very little
overhead. If we wish to add a safety layer, that's our choice, and we have
the freedom *not* to do so in situations whose very nature renders the
safety layer unnecessary. There is a trade-off between safety and
performance. Whilst it is often wise to err on the side of safety, there
is no point in situations where safety is simply not an issue. For
example, let's say we're looping through every second in 2008, that's
31622400 iterations. Once we've got the code right in dev, it's right, and
it isn't going to break by magic. A paranoid asctime function would just
slow us down. At times where we do need the safety (e.g. working from
stream input), we can do our own range checks. It's not rocket science.

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

P: n/a
In article <fm**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>It's a standard, not a user guide. The people who need warning about
gets() are not likely to be looking in the standard for guidance.

And of course the Rationale explains what's wrong with it.
>The why did they leave it in the standard?
Because the procedure for removing things is to deprecate them first.

-- Richard
--
:wq
Jan 18 '08 #31

P: n/a
jacob navia wrote:
>
You defend them becasue you and they have the same basic
philosophy towards error checking:

"Error checking is unnecessary overhead"

Off topic, but I think C++ is more suitable for you.
Jan 18 '08 #32

P: n/a
jacob navia wrote:
Richard Heathfield wrote:
>>
>>Why not fixing it?

Because it's not broken.

You can't read?
>int tm_year; // years since 1900

And where it says that should be smaller than 8099 ???

NOWHERE.
You failed to read Richards post, and especially you snipped the
following from it:
>The limits are easily deduced from 4.12.3.1 of C90 or 7.23.3.1
of C99. For the buffer not to overflow:

tm_wday must be in the range 0-6.
tm_mon must be in the range 0-11.
tm_mday must be in the range 0-999(!).
tm_hour must be in the range 0-99.
tm_min must be in the range 0-99.
tm_sec must be in the range 0-99.
tm_year must be in the range 0-8099.
I think part of the confusion may be that the C90 reference should
actually be C89. The illiteracy suggestion is not appropriate.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 18 '08 #33

P: n/a
Ioannis Vranos wrote:
jacob navia wrote:
>You defend them becasue you and they have the same basic
philosophy towards error checking:

"Error checking is unnecessary overhead"

Off topic, but I think C++ is more suitable for you.
If he takes you up on it, you may not be popular there yourself.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 18 '08 #34

P: n/a
Billy Bong wrote:
>
.... snip ...
>
Microsoft supports "void main()", so that should tell you
something, provided you're living in the real world, of course.
Yes, it tells us that MS doesn't understand the C language.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 18 '08 #35

P: n/a
jacob navia wrote:
Walter Roberson wrote:
.... snip ...
>
>These things could be done, but would the result still be C?

This is irrelevant. You mean that if the committee specified
the above limits foe asctime() C would "change its nature"
If you ever learn not to castigate anyone who disagrees with you,
you just might eventually find that your suggestions at least get
read. This is probably a futile suggestion.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 18 '08 #36

P: n/a
On 18 Jan 2008 at 2:44, CBFalconer wrote:
jacob navia wrote:
>Walter Roberson wrote:
... snip ...
>>
>>These things could be done, but would the result still be C?

This is irrelevant. You mean that if the committee specified
the above limits foe asctime() C would "change its nature"

If you ever learn not to castigate anyone who disagrees with you,
you just might eventually find that your suggestions at least get
read.
*splutter* My coffee just went everywhere!

Said without the slightest trace of irony, too! Perfect.

Jan 18 '08 #37

P: n/a
ja*********@verizon.net said:

<snip>
As far as C is concerned, a rewrite of asctime() to prevent overflow
is the right solution.
Since overflowing a buffer necessarily invokes undefined behaviour,
implementations are free *right now* to protect asctime's buffer from
overflow if they wish, because an unoverflowed buffer is one legal outcome
of an overflowed buffer!

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

P: n/a
In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
>On 18 Jan 2008 at 2:44, CBFalconer wrote:
>jacob navia wrote:
>>Walter Roberson wrote:
... snip ...
>>>
These things could be done, but would the result still be C?

This is irrelevant. You mean that if the committee specified
the above limits foe asctime() C would "change its nature"

If you ever learn not to castigate anyone who disagrees with you,
you just might eventually find that your suggestions at least get
read.

*splutter* My coffee just went everywhere!

Said without the slightest trace of irony, too! Perfect.
CBF is, if nothing else, a master of the perfect delivery.
What style, what grace...!

Jan 18 '08 #39

P: n/a
Richard Heathfield wrote:
ja*********@verizon.net said:

<snip>
As far as C is concerned, a rewrite of asctime() to prevent overflow
is the right solution.

Since overflowing a buffer necessarily invokes undefined behaviour,
implementations are free *right now* to protect asctime's buffer from
overflow if they wish, because an unoverflowed buffer is one legal outcome
of an overflowed buffer!
Agreed - but it would be better if the standard mandated a specific
behavior, or at least mandated the absence of buffer overflow.
Jan 18 '08 #40

P: n/a
ja*********@verizon.net wrote:
Walter Roberson wrote:
>Jacob specifically quoted the DR about "Corrupting memory" being
part of "the range of undefined behavior", and took exception to that.

I understood him as objecting to the fact that this was given as a
reason for the fact that committe ingnored the problem, not as a more
general complaint about undefined behavior. I thought he wanted
asctime() to have defined behavior. I didn't think he was expressing
opposition to the fact that undefined behavior includes the
possibility of corrupting memory. He might oppose it, but if so that
sentence didn't clearly express that opposition.
I think that any SERIOUS specifications must treat error
handling correctly and specify for ALL the range of
possible inputs what the outcome of the function should be.

The rejected proposal of Mr Cleaver proposed that in case of
overflow the output should contain stars ('*') in the overflowed
positions. That is a sensible outcome that would transform
a nadly specified function with no error handling into a
correctly specified function for all possible inputs.

The cmmittee rejected that solution and left the behavior
UNSPECIFIED!
>That is a more general dissatisfaction than with the result of
the single library function asctime(). Fixing asctime() alone would
not fix the more general issue that as far as C is concerned,
corrupting memory is an acceptable part of the range of
"undefined behavior".

Your proposal is therefor just a band-aid over one particular wart;
removing the possibility that corrupting memory is permitted
behavior for "undefined behaviour" everywhere in the C standard would
require the sort of checks I outline, such as mandatory bounds checking
and run-time memory alignment checking for unions.

As you said "These things could be done, but would the result still be
C?". If a future version of the C standard did actually mandate such
changes, the slow rate with which it would be adopted would make C99
look like an instant success, by comparison.

As far as C is concerned, a rewrite of asctime() to prevent overflow
is the right solution.
Yes.

What is the philosophy behind

"C is so full of warts that fixing this one doesn't matter" ???

I think that fixing them all is the only possible solution and I press
this issue again and again because I want it fixed. I think C is
deliberately left in this sorry state so that C++ can shine even
better.

There is NO reason to specify in that way asctime(). It can be done
correctly without any problems!

o snprintf would solve that
o a few tests for wrong values would solve that.

Why leave it like that?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 18 '08 #41

P: n/a
On Thu, 17 Jan 2008 02:03:52 -0600, CBFalconer wrote
(in article <47***************@yahoo.com>):
Billy Bong wrote:
>>
... snip ...
>>
Microsoft supports "void main()", so that should tell you
something, provided you're living in the real world, of course.

Yes, it tells us that MS doesn't understand the C language.
That, or it tells us that they realize they allows to provide
extensions, and they realize that on their platform's runtime, not
returning a value is acceptable.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Jan 18 '08 #42

P: n/a
CBFalconer wrote:
Ioannis Vranos wrote:
>jacob navia wrote:
>>You defend them becasue you and they have the same basic
philosophy towards error checking:

"Error checking is unnecessary overhead"
Off topic, but I think C++ is more suitable for you.

If he takes you up on it, you may not be popular there yourself.
Couldn't understand what you mean. Rephrase it.

Jan 19 '08 #43

P: n/a
Ioannis Vranos wrote:
CBFalconer wrote:
>Ioannis Vranos wrote:
>>jacob navia wrote:

You defend them becasue you and they have the same basic
philosophy towards error checking:

"Error checking is unnecessary overhead"
Off topic, but I think C++ is more suitable for you.

If he takes you up on it, you may not be popular there yourself.

Couldn't understand what you mean. Rephrase it.
He means that I am such a bad beast that the C++ people
will be angry with you because you brought them the
terrible horror of my presence.

CBFalconer likes to insult me like this, oblique, and
utterly stupid. He must feel so good after he writes that
nonsense.

Well, each one his hobbies I suppose.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jan 19 '08 #44

P: n/a
jacob navia wrote:
>
.... snip ...
>
I want asctime( fixed because it can be done VERY EASILY!!!
It suffices to specify correctly the size of the buffer OR
the allowed range of the arguments. That is not rocket science!
No, it can't have the buffer size adjusted. It is specified in the
C standard.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 19 '08 #45

P: n/a
On Fri, 18 Jan 2008 20:41:38 -0500, CBFalconer wrote:
jacob navia wrote:
>>
... snip ...
>>
I want asctime(* fixed because it can be done VERY EASILY!!! It
suffices to specify correctly the size of the buffer OR the allowed
range of the arguments. That is not rocket science!

No, it can't have the buffer size adjusted. It is specified in the C
standard.
Well obviously it's possible to change the standard. It's been done
before. So I'm assuming you're referring to implementations supporting
the current standard.

In what way would an implementation of asctime with a larger buffer size
than specified in the C standard fail to conform? For all input to
asctime, either the behaviour is defined, sprintf will write exactly 26
bytes, and there's no way for the calling program to see that extra bytes
have been reserved, or the behaviour would be undefined, and the effects
of using a larger buffer allows the input as an extension.
Jan 19 '08 #46

P: n/a
CBFalconer wrote:
jacob navia wrote:
... snip ...
>I want asctime( fixed because it can be done VERY EASILY!!!
It suffices to specify correctly the size of the buffer OR
the allowed range of the arguments. That is not rocket science!

No, it can't have the buffer size adjusted. It is specified in the
C standard.
No, that specification is only intended to convey the required behavior,
when the behavior is defined; it is not a required way of implementing
it. There is no way for strictly conforming code to detect the fact that
the buffer is larger than 26, because any code that would fill that
buffer with a string longer than that has undefined behavior.
Jan 19 '08 #47

P: n/a
CBFalconer <cb********@yahoo.comwrites:
jacob navia wrote:
>>
... snip ...
>>
There is NO reason to specify in that way asctime(). It can be
done correctly without any problems!

o snprintf would solve that
o a few tests for wrong values would solve that.

Why leave it like that?

Below is the appropriate section of the standard, copied from
N869.txt. Note that the output string is specified as holding 26
chars, the last of which will be a '0'.
You mean '\0', not '0'.
That string is static to
the function (or equivalent). The only possibility of an overrun
error is a bad value for timeptr->tm_year, and values from -1900
through 8099 are already handled.
[...]

Values of timeptr->tm_year anywhere in the range -2899 through 8099
(representing years -999 to 9999) are safe.

Not quite. The format string, again, is

"%.3s %.3s%3d %.2d:%.2d:%.2d %d\n"

Any of the "%...d" specifiers could result in an arbitrarily long
string (up to the width of INT_MIN) given a sufficiently large
argument. The "%3d" and "%.2d" specifiers, unlike "%.3s", don't
truncate their arguments.

For example, this program:

#include <stdio.h>
#include <limits.h>
int main(void)
{
printf("%.3s %.3s%3d %.2d:%.2d:%.2d %d\n",
"Sun", "Sep", INT_MIN, INT_MIN, INT_MIN, INT_MIN, INT_MIN);
return 0;
}

produces this output (on a system with INT_MIN==-2147483648):

Sun Sep-2147483648 -2147483648:-2147483648:-2147483648 -2147483648

Using sprintf this would require 68 bytes.

And of course the sample implementation given in the standard uses
unchecked arguments as array indices. A value of timeptr->tm_wday
outside the range 0..7, or of timeptr->tm_mon outside the range 0..11,
would invoke undefined behavior even before the result string is
built.

And just to add to the frivolity, values of tm_sec occupying 3
characters in the result (rather than the usual 2) are safe if tm_year
only takes up 3 characters (rather than the usual 4), along with a
plethora of other permutations.

(The workaround is easy enough: be careful when using asctime(), or
use strftim() instead.)

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jan 20 '08 #48

P: n/a
Keith Thompson said:
CBFalconer <cb********@yahoo.comwrites:
<snip>
>Below is the appropriate section of the standard, copied from
N869.txt. Note that the output string is specified as holding 26
chars, the last of which will be a '0'.

You mean '\0', not '0'.
<snip>
>
(The workaround is easy enough: be careful when using asctime(), or
use strftim() instead.)
You mean strftime() :-)

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

P: n/a
In article <8o******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>Keith Thompson said:
>(The workaround is easy enough: be careful when using asctime(), or
use strftim() instead.)

You mean strftime() :-)
If it's working with C90, he might have meant STRFTI().
dave

--
Dave Vandervies dj3vande at eskimo dot com
Plus I do sometimes still need to do math, and as great as vi is
for many purposes, it's not too great for algebra or calculus...
--Logan Shaw in the scary devil monastery
Jan 20 '08 #50

80 Replies

This discussion thread is closed

Replies have been disabled for this discussion.