lcc-win32

[Dave Thompson]

Re: lcc-win32

On Mon, 11 Oct 2004 21:56:37 +0200, jacob navia
<jacob@jacob.re mcomp.fr> wrote:
[color=blue]
> Mike Wahler wrote:
>[color=green]
> > "jacob navia" <jacob@jacob.re mcomp.fr> wrote in message
> > news:416ae03e$0 $26698$8fcfb975 @news.wanadoo.f r...
> >[color=darkred]
> >>Mike Wahler wrote:
> >>A library standard doesn't have any impact in the language.[/color]
> >
> >
> > But it does impact an implementation, which does have
> > a practical impact: E.g. storage space required, gobbling
> > up more names, etc.
> >[/color]
> No. You do not want it?
> Do not include
> #include <stdlist.h>
> <snip> If you do not use the floating
> point library (math.h) you just do not write:
> #include <math.h>
> and all names are still available to you and it is a legal
> program.[/color]

Not really. All standard library function names are reserved with
external linkage whether or not you #include their declarations and/or
ever reference them. You can't legally write your own sin() or fopen()
or whatever. (At least on a hosted implementation. ) Some (many?)
implementations do allow you to provide your own routines, which are
selected in preference to the standard one(s), as long as you don't
interfere with library internals. As a practical matter most of the
math routines stand pretty much alone, except for setting errno, and
overridng them has a fairly good chance of working but not standard.
[color=blue]
> You can then write:
> myfloat mysin(myfloat arg);
> and you can code the sinus function using only integer operations
> and table lookups.
>[/color]
That's true, since it uses a different name than the standard one. You
could do that even if you DID #include <math.h>.


- David.Thompson1 at worldnet.att.ne t

[Dan Pop]

Re: lcc-win32

In <lnmzynu9qc.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:
[color=blue]
>Dan.Pop@cern.c h (Dan Pop) writes:
>[...][color=green]
>> Calling a <time.h> function with a date that cannot be represented by
>> time_t invokes undefined behaviour.[/color]
>
>That's not true for asctime(). The algorithm, which is presented in
>the standard (and is admittedly flawed) makes no reference to time_t.[/color]

It doesn't have to. If you're passing asctime() a value out of range
for the <time.h> implementation, you're invoking undefined behaviour.
Admittedly, the standard fails to say so, leaving the algorithm to
define when an asctime call invokes undefined behaviour.

The real flaw in the standard is not the algorithm, but specifying
asctime() using an implementation. The right thing would have been to
require asctime to take as input the result of converting a time_t
value or the output of the mktime() function and to describe the format
of its output.
[color=blue]
>On a system where time_t overflows in, say, 2038, actime() must still
>work properly for a date in the year 2100.[/color]

It is this requirement that I consider the real bug in the standard.
asctime() must be seen as part of a package, rather than as an
independently defined entity.
[color=blue]
>On a system where time_t
>can represent years after 9999, asctime still invokes undefined
>behavior given an argument representing a time in the year 11000.[/color]

It's the caller that invokes undefined behaviour, by passing asctime()
a value not allowed by the definition of asctime(). If you have a
voltmeter rated up to 9999V, whose fault is if you connect it to 10000V
and it breaks? Was the voltmeter design flawed?

From a realistic point of view, it makes no sense to fill a tm struct
with values by hand and then pass it to asctime. In real applications,
if asctime() is used at all, its argument is the result of converting
a time_t value or has been properly adjusted by an mktime call.

Note that a year above 9999 is only one way of abusing the algorithm
from the standard. ALL the other fields of a struct tm involved in the
algorithm can be filled with values that would either cause out of
bounds array accesses or the total length of the output exceed the
allocated space.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

[Keith Thompson]

Re: lcc-win32

Dan.Pop@cern.ch (Dan Pop) writes:[color=blue]
> In <lnmzynu9qc.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:
>[color=green]
>>Dan.Pop@cern. ch (Dan Pop) writes:
>>[...][color=darkred]
>>> Calling a <time.h> function with a date that cannot be represented by
>>> time_t invokes undefined behaviour.[/color]
>>
>>That's not true for asctime(). The algorithm, which is presented in
>>the standard (and is admittedly flawed) makes no reference to time_t.[/color]
>
> It doesn't have to. If you're passing asctime() a value out of range
> for the <time.h> implementation, you're invoking undefined behaviour.
> Admittedly, the standard fails to say so, leaving the algorithm to
> define when an asctime call invokes undefined behaviour.[/color]

So you're arguing that time_t is the fundamental type on which
everything in <time.h> is based, and that a struct tm value that
represents a time outside the range of time_t is invalid. As you
admit, the standard doesn't actually say this, so I don't understand
how you came to this conclusion.

The actual standard defines several types: clock_t, time_t, and
struct tm. There is no indication that any of them is any more
fundamental than the others. There is no indication that manually
constructing a struct tm value is invalid. There's even an example in
7.23.2.3 that does exactly that (to determine the day of the week for
July 4, 2001); that example does depend on time_t, but it's clear that
you *can* construct a valid struct tm value that's not derived from a
time_t value.

[...]
[color=blue]
> It is this requirement that I consider the real bug in the standard.
> asctime() must be seen as part of a package, rather than as an
> independently defined entity.[/color]

Why? It's not a "bug", it's just something that you don't like.

[...]
[color=blue]
> From a realistic point of view, it makes no sense to fill a tm struct
> with values by hand and then pass it to asctime.[/color]

Sure it does. The standard says that this is allowed (unless you can
point to explicit wording that says otherwise).

I agree that making time_t the fundamental time type, and defining
everything else in <time.h> in terms of it, would have made for a
cleaner design. Perhaps whatever interface eventually replaces
<time.h> will do something like that. But that's a topic for
comp.std.c; here in comp.lang.c, we discuss the language as it's
actually defined.

--
Keith Thompson (The_Other_Keit h) kst-u@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.

[Dan Pop]

Re: lcc-win32

In <lnhdoqmgff.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:
[color=blue]
>Dan.Pop@cern.c h (Dan Pop) writes:[color=green]
>> In <lnmzynu9qc.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:
>>[color=darkred]
>>>Dan.Pop@cern .ch (Dan Pop) writes:
>>>[...]
>>>> Calling a <time.h> function with a date that cannot be represented by
>>>> time_t invokes undefined behaviour.
>>>
>>>That's not true for asctime(). The algorithm, which is presented in
>>>the standard (and is admittedly flawed) makes no reference to time_t.[/color]
>>
>> It doesn't have to. If you're passing asctime() a value out of range
>> for the <time.h> implementation, you're invoking undefined behaviour.
>> Admittedly, the standard fails to say so, leaving the algorithm to
>> define when an asctime call invokes undefined behaviour.[/color]
>
>So you're arguing that time_t is the fundamental type on which
>everything in <time.h> is based, and that a struct tm value that
>represents a time outside the range of time_t is invalid. As you
>admit, the standard doesn't actually say this, so I don't understand
>how you came to this conclusion.[/color]

I have discussed the issue at great length in comp.std.c, several months
ago. I see no point in rehashing it.
[color=blue][color=green]
>> It is this requirement that I consider the real bug in the standard.
>> asctime() must be seen as part of a package, rather than as an[/color][/color]
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^[color=blue][color=green]
>> independently defined entity.[/color]
> ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^
>Why?[/color]

Reading impaired? The answer was just above your question, readily
available for your perusal.

I hope you didn't ask why asctime() must be seen as part of a package,
because the answer should be obvious.
[color=blue]
>It's not a "bug", it's just something that you don't like.[/color]

Reading impaired? I didn't say it's a bug, I said "I consider the real
bug" which strongly implies a personal judgment, i.e. it's just something
that I don't like.
[color=blue]
>
>[...]
>[color=green]
>> From a realistic point of view, it makes no sense to fill a tm struct
>> with values by hand and then pass it to asctime.[/color]
>
>Sure it does. The standard says that this is allowed (unless you can
>point to explicit wording that says otherwise).[/color]

Many things the standard allows make no sense from a realistic point of
view. I have plenty of examples available, if needed.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

[Keith Thompson]

Re: lcc-win32

Dan.Pop@cern.ch (Dan Pop) writes:[color=blue]
> In <lnhdoqmgff.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:[color=green]
>>Dan.Pop@cern. ch (Dan Pop) writes:[/color][/color]
[...][color=blue][color=green][color=darkred]
>>> It is this requirement that I consider the real bug in the standard.
>>> asctime() must be seen as part of a package, rather than as an[/color][/color]
> ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^[color=green][color=darkred]
>>> independently defined entity.[/color]
>> ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^
>>Why?[/color]
>
> Reading impaired? The answer was just above your question, readily
> available for your perusal.[/color]

I see only a blatant assertion which you've chosen not to justify.
[color=blue]
> I hope you didn't ask why asctime() must be seen as part of a package,
> because the answer should be obvious.[/color]

No, I'm not reading impaired, but thank you for your kind concern.

I'm reading the actual standard. I don't know what you're reading.
[color=blue][color=green]
>>It's not a "bug", it's just something that you don't like.[/color]
>
> Reading impaired? I didn't say it's a bug, I said "I consider the real
> bug" which strongly implies a personal judgment, i.e. it's just something
> that I don't like.[/color]

Ok, so you don't like what the standard actually says. That's fine;
you might consider discussing it in comp.std.c.

What the standard actually *says* is internally consistent (if a bit
odd), and your interpretation of it is no more than wishful thinking.

Try this, Dan. Pretend that I've asserted that "Calling a <time.h>
function with a date that cannot be represented by time_t invokes
undefined behaviour." I'm sure you wouldn't have any trouble arguing
that I'm wrong.

--
Keith Thompson (The_Other_Keit h) kst-u@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.

[Dan Pop]

Re: lcc-win32

In <lnmzyhjfo6.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:
[color=blue]
>Dan.Pop@cern.c h (Dan Pop) writes:[color=green]
>> In <lnhdoqmgff.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:[color=darkred]
>>>Dan.Pop@cern .ch (Dan Pop) writes:[/color][/color]
>[...][color=green][color=darkred]
>>>> It is this requirement that I consider the real bug in the standard.
>>>> asctime() must be seen as part of a package, rather than as an[/color]
>> ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^[color=darkred]
>>>> independently defined entity.
>>> ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^
>>>Why?[/color]
>>
>> Reading impaired? The answer was just above your question, readily
>> available for your perusal.[/color]
>
>I see only a blatant assertion which you've chosen not to justify.[/color]

As I wrote below, I thought that the justification is obvious, even to
you.
[color=blue][color=green]
>> I hope you didn't ask why asctime() must be seen as part of a package,
>> because the answer should be obvious.[/color]
>
>No, I'm not reading impaired, but thank you for your kind concern.
>
>I'm reading the actual standard. I don't know what you're reading.[/color]

The same, but with an open mind, rather than anally clutching to the
strict wording which, quite often, fails to reflect the actual intent of
the authors.
[color=blue][color=green][color=darkred]
>>>It's not a "bug", it's just something that you don't like.[/color]
>>
>> Reading impaired? I didn't say it's a bug, I said "I consider the real
>> bug" which strongly implies a personal judgment, i.e. it's just something
>> that I don't like.[/color]
>
>Ok, so you don't like what the standard actually says. That's fine;
>you might consider discussing it in comp.std.c.[/color]

Memory impaired? I have already done it, several months ago, as I have
already pointed out in my previous message.
[color=blue]
>What the standard actually *says* is internally consistent (if a bit
>odd), and your interpretation of it is no more than wishful thinking.[/color]

If expecting <time.h> to provide the specification of a package, rather
than the descriptions of a bunch of *unrelated* functions is wishful
thinking, then you're right, of course.
[color=blue]
>Try this, Dan. Pretend that I've asserted that "Calling a <time.h>
>function with a date that cannot be represented by time_t invokes
>undefined behaviour." I'm sure you wouldn't have any trouble arguing
>that I'm wrong.[/color]

I'd argue both sides and finally agree with you, because I do consider
<time.h> as a package (with the obvious exception of the clock() function
and its associated stuff, which was better placed in <stdlib.h>, the
catch-all for anything that didn't belong elsewhere). It may not be a
perfect package, but it's still a package and the current specification
of asctime() looks like a brain fart of the committee.

The only *sensible* requirement about the size of the asctime output is
that it accomodates the largest year supported by the <time.h>
implementation, usually the largest year representable by time_t.
If int is a 64-bit type, there is no point in making the buffer large
enough to accomodate year LLONG_MAX, an entity devoid of any meaning
for any reasonable C program.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

[Keith Thompson]

Re: lcc-win32

Dan.Pop@cern.ch (Dan Pop) writes:[color=blue]
> In <lnmzyhjfo6.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:[/color]
[...][color=blue][color=green]
>>I'm reading the actual standard. I don't know what you're reading.[/color]
>
> The same, but with an open mind, rather than anally clutching to the
> strict wording which, quite often, fails to reflect the actual intent of
> the authors.[/color]

Perhaps you can provide some evidence that the actual intent of the
authors is consistent with your interpretation. I don't believe it
is.

[...]
[color=blue][color=green]
>>What the standard actually *says* is internally consistent (if a bit
>>odd), and your interpretation of it is no more than wishful thinking.[/color]
>
> If expecting <time.h> to provide the specification of a package, rather
> than the descriptions of a bunch of *unrelated* functions is wishful
> thinking, then you're right, of course.[/color]

I don't particularly expect <time.h> to provide the specification of a
"package". I don't know why you do. I understand that you wish it
did; so do I (see "wishful thinking", above) (I'm not 100% sure what
you mean by the word "package" anyway.)

Nor do I expect <stdlib.h> to provide the specification of a "package".

[...][color=blue]
> The only *sensible* requirement about the size of the asctime output is
> that it accomodates the largest year supported by the <time.h>
> implementation, usually the largest year representable by time_t.[/color]

What a pity that the standard doesn't actually say that. In fact what
the standard actually *does* say directly contradicts your
interpretation.

And I know this won't do any good, but take your personal abuse
("reading impaired" et al) and shove it.

--
Keith Thompson (The_Other_Keit h) kst-u@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.

[Dan Pop]

Re: lcc-win32

In <lnoeivhot5.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:
[color=blue]
>Dan.Pop@cern.c h (Dan Pop) writes:[color=green]
>> In <lnmzyhjfo6.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:[/color]
>[...][color=green][color=darkred]
>>>I'm reading the actual standard. I don't know what you're reading.[/color]
>>
>> The same, but with an open mind, rather than anally clutching to the
>> strict wording which, quite often, fails to reflect the actual intent of
>> the authors.[/color]
>
>Perhaps you can provide some evidence that the actual intent of the
>authors is consistent with your interpretation. I don't believe it
>is.[/color]

What do you believe the actual intent was? To provide a deliberately
broken specification for asctime()?

IMHO, they were looking for a simple way of specifying the actual format
of asctime's output and they made a less than optimal choice. They
didn't meant asctime to be seen as a standalone member of the package.
[color=blue][color=green]
>> If expecting <time.h> to provide the specification of a package, rather
>> than the descriptions of a bunch of *unrelated* functions is wishful
>> thinking, then you're right, of course.[/color]
>
>I don't particularly expect <time.h> to provide the specification of a
>"package". I don't know why you do.[/color]

Why don't we have a single header covering the whole of the standard C
library, something like <stdc.h> ? Because the standard C library was
logically divided into packages and each package assigned its own header.
All the "orphans" have been gathered together in <stdlib.h>.
[color=blue]
>I understand that you wish it
>did; so do I (see "wishful thinking", above)[/color]

I would have been perfectly happy with <stdc.h>, no wishful thinking.
I was merely commenting on what the committee actually did. If you
disagree, ask in comp.std.c.
[color=blue]
>(I'm not 100% sure what you mean by the word "package" anyway.)[/color]

Then get yourself an English dictionary and peruse it. If still in doubt,
post the most likely candidate definitions and I'll tell you which it is.
[color=blue]
>Nor do I expect <stdlib.h> to provide the specification of a "package".[/color]

Neither do I, for reasons *already* explained in my previous post.
Reading impaired?
[color=blue]
>[...][color=green]
>> The only *sensible* requirement about the size of the asctime output is
>> that it accomodates the largest year supported by the <time.h>
>> implementation, usually the largest year representable by time_t.[/color]
>
>What a pity that the standard doesn't actually say that. In fact what
>the standard actually *does* say directly contradicts your
>interpretation .[/color]

Indeed, if you anally clutch at the actually wording, without even
trying to see the intent. Anyway, I never filled a struct tm by hand
and then passed it to asctime and I don't plan to do that in the future,
so the actual definition happens to be good enough *for me*, even if it's
broken in the general context of the <time.h>.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

[Keith Thompson]

Re: lcc-win32

Dan, I'm not going to waste any more time on this.
I'm right, you're wrong, and I'm done here.

--
Keith Thompson (The_Other_Keit h) kst-u@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.