By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,827 Members | 2,267 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,827 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
Share this Question
Share on Google+
80 Replies


P: n/a
James Kuyper wrote:
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.
The specification says:

"using the equivalent of the following algorithm."

and the following algorithm specifies a static buffer size of 26.
This leaves no option, IMO. It does allow implementation in
assembly code, or in Druidism, as pleases the implementor.

--
[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 20 '08 #51

P: n/a
CBFalconer said:
James Kuyper wrote:
>CBFalconer wrote:
<snip>
>>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.

The specification says:

"using the equivalent of the following algorithm."

and the following algorithm specifies a static buffer size of 26.
This leaves no option, IMO. It does allow implementation in
assembly code, or in Druidism, as pleases the implementor.
The "as if" rule applies. Since a strictly conforming program can't tell
whether a larger buffer is allocated, it's okay to allocate a larger
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 20 '08 #52

P: n/a
Billy Bong schrieb:
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.
That's what I thought always, but I'm not anymore so sure. According to
a recent thread...

* H. Schildt (book writer and ISOC member)
- writes that you are free to use void main()
* Richard Heathfield (book writer)
- says that void main() is false
* Chris Hills (ISOC member)
- says that void main() is valid C
* Jack Klein (writer of C library and inventor of Klein Bottle)
- says that void main() is not valid C code

I am still very confused.

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.
What is ERRORLEVEL on Microsoft OS when main returns void? Is it 0?
Jan 20 '08 #53

P: n/a
Keith Thompson wrote:
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.
No. The input is specified as a struct tm*, and that struct is
specified as having restricted value sizes. I believe they never
exceed 60, and are never negative. Some are 3 char. strings. That
struct is, in turn, created by provided code that interfaces with
some system specific timer.

--
[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 20 '08 #54

P: n/a
Hans Schneider said:
Billy Bong schrieb:
>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.

That's what I thought always, but I'm not anymore so sure. According to
a recent thread...

* H. Schildt (book writer and ISOC member)
- writes that you are free to use void main()
* Richard Heathfield (book writer)
- says that void main() is false
* Chris Hills (ISOC member)
- says that void main() is valid C
* Jack Klein (writer of C library and inventor of Klein Bottle)
- says that void main() is not valid C code

I am still very confused.
The return type of main isn't a matter of opinion. It can be resolved with
reference to the ISO C Standard.
What is ERRORLEVEL on Microsoft OS when main returns void? Is it 0?
Bearing in mind that the behaviour is in any case undefined, the answer is
that it is up to the implementation. I ran a couple of tests, and found
that one Microsoft implementation did indeed set ERRORLEVEL to 0, whereas
one Borland implementation set it to 10 (for one given test - YMMV).

--
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 #55

P: n/a
Hans Schneider wrote:
>
.... snip ...
>
That's what I thought always, but I'm not anymore so sure.
According to a recent thread...

* H. Schildt (book writer and ISOC member)
- writes that you are free to use void main()
* Richard Heathfield (book writer)
- says that void main() is false
* Chris Hills (ISOC member)
- says that void main() is valid C
* Jack Klein (writer of C library and inventor of Klein Bottle)
- says that void main() is not valid C code

I am still very confused.
Then resolve it. Read the standard. Try the following links:

Some useful references about C:
<http://c-faq.com/ (C-faq)
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf(C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2(C99, txt)

Hint - RH and JK are accurate. HS is notorious.

--
[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 20 '08 #56

P: n/a
On Sat, 19 Jan 2008 22:46:56 -0600, Hans Schneider wrote
(in article <19****************@aioe.org>):
Billy Bong schrieb:
>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.

That's what I thought always, but I'm not anymore so sure. According to
a recent thread...

* H. Schildt (book writer and ISOC member)
- writes that you are free to use void main()
* Richard Heathfield (book writer)
- says that void main() is false
* Chris Hills (ISOC member)
- says that void main() is valid C
* Jack Klein (writer of C library and inventor of Klein Bottle)
- says that void main() is not valid C code

I am still very confused.
Apparently you are. The Klein surface, later known as a Klein bottle
was by Felix Klein in the late 1800s, you seem to be way off target on
at least some of it. ;-)

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

Jan 20 '08 #57

P: n/a
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
[...]
>(The workaround is easy enough: be careful when using asctime(), or
use strftim() instead.)

You mean strftime() :-)
Yeah, well, the 'e' is silent anyway.

--
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 #58

P: n/a
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
[...]
>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.

No. The input is specified as a struct tm*, and that struct is
specified as having restricted value sizes. I believe they never
exceed 60, and are never negative. Some are 3 char. strings. That
struct is, in turn, created by provided code that interfaces with
some system specific timer.
The members of an object of type struct tm are of type int, and can
have any values in the range INT_MIN .. INT_MAX. C99 7.23.1.4, which
defines struct tm, says (emphasis added):

The semantics of the members and their *normal* ranges are
expressed in the comments.

The gmtime() and localtime() functions should always generate struct
tm values with members having values in the "normal" ranges, but
there's nothing to prevent user code from storing any arbitrary values
in any of the members. In other words, the given ranges are
constraints on the results of gmtime() and localtime(), not on the
type. (There's no way in the language to specify or enforce such a
constraint.) Indeed, the mktime() function is specifically designed
to work with values outside the normal ranges.

Consider this program:

#include <stdio.h>
#include <time.h>
int main(void)
{
struct tm tm;
tm.tm_sec = 999;
tm.tm_min = -99;
tm.tm_hour = 0;
tm.tm_mday = 0;
tm.tm_mon = 0;
tm.tm_year = -1801; /* year 99 */
tm.tm_wday = 0;
fputs(asctime(&tm), stdout);
return 0;
}

I believe it is completely portable (to conforming hosted
implementations), and must produce the following output (barring
output errors):

Sun Jan 0 00:-99:999 99

--
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 #59

P: n/a
Richard Heathfield <rj*@see.sig.invalidwrites:
CBFalconer said:
>James Kuyper wrote:
>>CBFalconer wrote:
<snip>
>>>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.

The specification says:

"using the equivalent of the following algorithm."

and the following algorithm specifies a static buffer size of 26.
This leaves no option, IMO. It does allow implementation in
assembly code, or in Druidism, as pleases the implementor.

The "as if" rule applies. Since a strictly conforming program can't tell
whether a larger buffer is allocated, it's okay to allocate a larger
buffer.
I agree, but I'm going to quibble about terminology.

The body of the standard doesn't mention the "as if" rule, but the
index has an entry that points to C99 5.1.2.3; I'm not sure that
anything in that section directly applies to this. For that matter,
I'm not sure just what part of that section is supposed to define the
"as-if" rule.

It's true that a strictly conforming program can't tell the
difference, but that's not sufficient. If a program with unspecified
behavior could tell the difference, then an implementation wouldn't be
allowed to use a larger buffer. But in fact any program that avoids
undefined behavior can't tell the difference, and that's why a larger
buffer is allowed.

Consider an implementation that provides an asctime() function
identical to the one presented in the standard, except that
static char result[26];
is replaced by
static char result[100];
Only a program that invokes undefined behavior (by overflowing a
26-byte buffer) would behave differently in the two cases.

For that matter, the implementation of asctime() could declare a
26-byte buffer, but the compiler could recognize this as a special
case and arrange for extra memory to reserved immediately after the
result buffer.

--
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 #60

P: n/a
On Sun, 20 Jan 2008 01:34:35 -0800, Keith Thompson wrote:
The body of the standard doesn't mention the "as if" rule, but the index
has an entry that points to C99 5.1.2.3; I'm not sure that anything in
that section directly applies to this. For that matter, I'm not sure
just what part of that section is supposed to define the "as-if" rule.
That's likely p5:
"The least requirements on a conforming implementation are:
-- At sequence points, volatile objects are stable in the sense that
previous accesses are complete and subsequent accesses have not yet
occurred.
-- At program termination, all data written into files shall be
identical to the result that execution of the program according to
the abstract semantics would have produced.
-- The input and output dynamics of interactive devices shall take place
as specified in 7.19.3. The intent of these requirements is that
unbuffered or line-buffered output appear as soon as possible, to
ensure that prompting messages actually appear prior to a program
waiting for input."

An implementation that defines a larger buffer size for use by asctime
can still meet these requirements.
Jan 20 '08 #61

P: n/a
In article <47***************@yahoo.com>, 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.
N869.txt is NOT a standard

Undefined behaviour cut..........

You can't have it both ways. .

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

Jan 20 '08 #62

P: n/a
In article <47***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>Hans Schneider wrote:
>>
... snip ...
>>
That's what I thought always, but I'm not anymore so sure.
According to a recent thread...

* H. Schildt (book writer and ISOC member)
Is he an ISO -c member?
> - writes that you are free to use void main()
But his books are known to be full of holes. On the other hand when did
he write it? C has been evolving for about 35 years.
>* Richard Heathfield (book writer)
- says that void main() is false
* Chris Hills (ISOC member)
- says that void main() is valid C
In a self hosted system.
>* Jack Klein (writer of C library and inventor of Klein Bottle)
- says that void main() is not valid C code
On a hosted system
>Hint - RH and JK are accurate.
They are very accurate pedants who as has been decided elsewhere are
often accurate but very unhelpful, almost misleading, at the same time.

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

Jan 20 '08 #63

P: n/a
Keith Thompson wrote:
(The workaround is easy enough: be careful when using asctime(), or
use strftim() instead.)
Of course the workaround is easy, and lcc-win will never
overflow the buffer.

BUT tell me, why do we have to program workarounds for the standard?

What kind of standard is this one that needs workarounds for its BUGS?

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

P: n/a
On Sun, 20 Jan 2008 10:32:48 +0000, Chris Hills wrote:
In article <47***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>>Below is the appropriate section of the standard, copied from N869.txt.

N869.txt is NOT a standard
The section (7.23.3.1) is identical between n869 and the standard, so
while n869 is indeed not the standard, the claim that the text was (also)
the appropriate section of the standard was correct.
Jan 20 '08 #65

P: n/a
In article <fm**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>What kind of standard is this one that needs workarounds for its BUGS?
As someone who's been on several standards committees, I think you'll
find it's the normal kind.

-- Richard
--
:wq
Jan 20 '08 #66

P: n/a
Chris Hills <ch***@phaedsys.orgwrites:
In article <47***************@yahoo.com>, 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.

N869.txt is NOT a standard

Undefined behaviour cut..........

You can't have it both ways. .
Nether can you. You are on record as objecting to pedantic postings
that are correct but unhelpful. If there a difference between the
cited text and the published standard? If so, telling us would be
very helpful. If not, knowing that would help too.

--
Ben.
Jan 20 '08 #67

P: n/a
Hans Schneider wrote:
....
* H. Schildt (book writer and ISOC member)
- writes that you are free to use void main()
* Richard Heathfield (book writer)
- says that void main() is false
* Chris Hills (ISOC member)
- says that void main() is valid C
* Jack Klein (writer of C library and inventor of Klein Bottle)
- says that void main() is not valid C code

I am still very confused.
You might try looking at the standard itself. None of the other sources
you've mentioned are authoritative.
Jan 20 '08 #68

P: n/a
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.
Six sigma what? That's not a normally distributed variable. :-)
--
Army1987 (Replace "NOSPAM" with "email")
Jan 20 '08 #69

P: n/a
Chris Hills wrote:
CBFalconer <cb********@yahoo.comwrites
.... snip ...
>
>Below is the appropriate section of the standard, copied from
N869.txt.

N869.txt is NOT a standard

Undefined behaviour cut..........

You can't have it both ways. .
Well, I could omit the informative comment about the source and
depend upon you to do a word for word comparison with the 'actual
standard'. Would you prefer that?

--
[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 20 '08 #70

P: n/a
Army1987 wrote:
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.

Six sigma what? That's not a normally distributed variable. :-)
I think it is more important to identify the Bong comment as pure
imagination, apart from embedded (non-hosted) systems. I.e. bong
it.

--
[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 20 '08 #71

P: n/a
Keith Thompson wrote:
>
.... snip ...
>
There are two kinds of conforming C implementations, hosted and
freestanding. You're not likely to run into a freestanding
implementation unless you work on embedded systems (though it's
been argued that some MS Windows C implementations are really
freestanding).
Since those 'implementations' lack any form whatsoever of the main
function, that seems to be an adequate argument that they are not
written in C for a hosted implementation. This seems to make MS
one of the largest vendors of embedded code.

--
[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 20 '08 #72

P: n/a
In article <87************@bsb.me.uk>, Ben Bacarisse
<be********@bsb.me.ukwrites
>Chris Hills <ch***@phaedsys.orgwrites:
>In article <47***************@yahoo.com>, 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.

N869.txt is NOT a standard

Undefined behaviour cut..........

You can't have it both ways. .

Nether can you. You are on record as objecting to pedantic postings
that are correct but unhelpful.
And it is CBF who is a prime example of doing this.
If there a difference between the
cited text and the published standard?
That is the question... it is as CFB woudl say "Undefined Behaviour"

Actually in this case they are the same *at the moment*.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jan 20 '08 #73

P: n/a
On Sun, 20 Jan 2008 12:25:25 -0800, Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
>Keith Thompson wrote:
>>(The workaround is easy enough: be careful when using asctime(), or
use strftim() instead.)

Of course the workaround is easy, and lcc-win will never overflow the
buffer.

Glad to hear it. So what exactly does it do with tm_year==100000? I'm
just curious.
I don't know about lcc-win32, but on my system with 32-bit ints, glibc
reserves a buffer of 114 bytes, which is capable of holding the result
for the absolute largest values that could be put in a struct tm if int
had 64 bits.
Jan 20 '08 #74

P: n/a
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>>
... snip ...
>>
There are two kinds of conforming C implementations, hosted and
freestanding. You're not likely to run into a freestanding
implementation unless you work on embedded systems (though it's
been argued that some MS Windows C implementations are really
freestanding).

Since those 'implementations' lack any form whatsoever of the main
function, that seems to be an adequate argument that they are not
written in C for a hosted implementation. This seems to make MS
one of the largest vendors of embedded code.
I thought it was still possible to write "int main(void)" (if you want
a program that uses a console rather than the GUI).

--
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 #75

P: n/a
Keith Thompson wrote:
>
I thought it was still possible to write "int main(void)" (if you want
a program that uses a console rather than the GUI).

int main(void) does not imply a console necessarily, but this is usually
the case.
Jan 20 '08 #76

P: n/a
CBFalconer said:
A struct tm is built by mktime,
The Standard does not require this. It's perfectly feasible (and
commonplace) for people to roll their own struct tm objects. Nor is mktime
the only standard function that builds a struct tm.

--
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 21 '08 #77

P: n/a
Richard Heathfield wrote:
CBFalconer said:
>A struct tm is built by mktime,

The Standard does not require this. It's perfectly feasible (and
commonplace) for people to roll their own struct tm objects. Nor
is mktime the only standard function that builds a struct tm.
I had the impression (possibly wrong) that the functions that
created a struct tm operated on unspecified format system data, and
thus had to be part of the library. In light of that I considered
any other method to be an extension, whose correctness is entirely
up to the extender.

--
[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 21 '08 #78

P: n/a
CBFalconer <cb********@yahoo.comwrites:
Richard Heathfield wrote:
>CBFalconer said:
>>A struct tm is built by mktime,

The Standard does not require this. It's perfectly feasible (and
commonplace) for people to roll their own struct tm objects. Nor
is mktime the only standard function that builds a struct tm.

I had the impression (possibly wrong) that the functions that
created a struct tm operated on unspecified format system data, and
thus had to be part of the library. In light of that I considered
any other method to be an extension, whose correctness is entirely
up to the extender.
Sure, gmtime() and localtime() have to know what a time_t looks like,
and therefore have to be part of the library. But a user function
that creates a struct tm is just a user function; it's not part of the
implementation, and therefore it's not an extension.

--
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 21 '08 #79

P: n/a
CBFalconer said:
Richard Heathfield wrote:
>CBFalconer said:
>>A struct tm is built by mktime,

The Standard does not require this. It's perfectly feasible (and
commonplace) for people to roll their own struct tm objects. Nor
is mktime the only standard function that builds a struct tm.

I had the impression (possibly wrong) that the functions that
created a struct tm operated on unspecified format system data
They may well do, but that's not a prerequisite for building a struct tm -
the spec for struct tm is spelled out in the Standard (and in K&R2), and
it's easy to roll your own. Right now, for example, I could represent
today's date and time as follows, and then use (a pointer to) it as
perfectly legal and well-defined input to, say, strftime:

#include <time.h>

int main(void)
{
struct tm now;
now.tm_isdst = 0;
now.tm_yday = 20;
now.tm_wday = 1;
now.tm_year = 108;
now.tm_mon = 0;
now.tm_mday = 21;
now.tm_hour = 8;
now.tm_min = 44;
now.tm_sec = 59;
now.tm_min = 45;
now.tm_sec = 09;
now.tm_sec = 16;
now.tm_sec = 23;
now.tm_sec = 31;
now.tm_sec = 39;
now.tm_sec = oh I give up. Okay, you're right - it can't be done.

--
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 21 '08 #80

P: n/a
On Sun, 20 Jan 2008 03:02:33 -0800, Keith Thompson <ks***@mib.org>
wrote:
Chris Hills <ch***@phaedsys.orgwrites:
In article <47***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>Hans Schneider wrote:
>* H. Schildt (book writer and ISOC member)
Is he an ISO -c member?

I think he's claimed to be an "observing member" or something like
that. I've heard that actual members of the committee don't recall
seeing him at any meetings.
The claim in my copy of The [Poorly] Annotated ANSI C Standard
is that he was an "Observing Member" of ANSI X3J11 "throughout
formation and adoption" (presumably meaning 1989). He says nothing
about (JTC1SC22)WG14, and I'm pretty sure it didn't even exist for
most if not all of that time.

- formerly david.thompson1 || achar(64) || worldnet.att.net
Feb 4 '08 #81

80 Replies

This discussion thread is closed

Replies have been disabled for this discussion.