Re: All programs are undefined, Re: Why this works???

Keith Thompson said:

Kaz Kylheku <kkylheku@xxxxxxxxx> writes:

<snip>

On an implementation where division by zero is safe and predictable
(and documented as such), programs which divide by zero are also well-
defined. That doesn't make them well-defined standard C programs, just
well-defined programs of that dialect.

That's a poor analogy.

Ahem. Dem's fitin' woids, Keith - Kaz doesn't *do* poor analogies. :-)

I think you may have missed Kaz's point. What he's talking about is the
difference between "well-defined" in ISO C terms and "well-defined" in
terms of the capabilities of a particular machine about whose details ISO
is deliberately (and necessarily) ignorant.

Maybe a parallel example will serve to illustrate the difference. In terms
of ISO C, we can all agree that the behaviour of the following code
fragment is thoroughly, utterly, irrevocably, and bananararily undefined:

void printat(const char *s, int x, int y, int bg, int fg)
{
unsigned char *scrbase = (unsigned char *)0xB8000000UL + 160 * y + 2 * x;
while(*s != '\0')
{
*scrbase++ = (unsigned char)*s++;
if(bg >= 0 && fg >= 0 && bg < 16 && fg < 16)
{
*scrbase = ((bg << 4) | fg);
}
++scrbase;
}
} /* Did I get this right? It's been a while. */

If, however, this code is compiled for large memory model and executed
under MS-DOS on an x86 machine in 80x25 colour text mode, the behaviour is
perfectly well-defined *on that machine*. Many DOS programs used precisely
this kind of "dirty trick" to get decent display performance by stepping
around the BIOS and going straight to video RAM. I would not be at all
surprised if you'd used this trick yourself, back in the dim and distant.
If this technique were not well-defined under the above circumstances,
there would have been a lot of very, very angry customers demanding their
money back from suppliers of such programs as Norton Utilities,
Multi-Edit, PC Tools, 1-2-3, dBase, and even Turbo C's IDE. The writers of
these programs were able to rely on the well-definedness of this technique
within the context of the dialect of C they were using - Turbo C,
Microsoft C, etc.

There are times when you need to step outside what ISO C can do. When you
do so, you *have* to rely on the well-definedness of operations and
techniques the behaviour of which ISO C does not itself define.

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

Relevant Pages

  • Re: Number of weeks in year?
    ... >produce results incompatible with ISO 8601" ... >private int WeekNumber_Entire4DayWeekRule ... > StartWeekDayOfYear = StartWeekDayOfYear; ... > EndWeekDayOfYear = EndWeekDayOfYear; ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Garbage Collection - Stop Making Trash
    ... > as soon as the ECMA standard is ratified, it will be submitted to ISO. ... int main ... pointer, it cannot be moved by the GC and will not be garbage collected. ...
    (comp.lang.cpp)
  • Re: code portability
    ... All the ISO guys had to do was - nothing at all! ... wrongly assumes long int is precisely 32 bits is already broken, ... long as you can spare the space), and don't worry about changing data ... most companies don't switch compilers too often. ...
    (comp.lang.c)
  • Re: Prime numbers
    ... The technique I use has fixed-time modular reductions, ... Slows down when FPInt conversions are slow, ... You get different behaviour depending on how int() works (which ... The man who is always worrying about whether or not his soul would be ...
    (sci.math)
  • Re: VS2005 doesnt like its own suggestions
    ... But first, about BOOL, INT etc. ... ISO C++ can stay the same and so could int and long. ... The non-morbid reasons, which I lean to believe are the prevalent ...
    (microsoft.public.vc.language)