Mail Archives: djgpp/2000/03/21/21:20:21
In article <38D7E5F5 DOT ED6FB969 AT bigfoot DOT com>,
Richard Dawe <richdawe AT bigfoot DOT com> wrote:
> By the way, I think you mean "in user code they _may_ lead to undefined
> behavior" rather than "in user code they lead to undefined behavior",
> which is a bit harsh. ;)
"Undefined behaviour" doesn't imply programs crashing or otherwise
malfunctioning. "Undefined behavior" is merely undefined: on some
platforms it may work just fine, on others there may be silent
errors, and on still others there may be a spectacular crash. It may
even be so that on all current platforms the program works fine, but
there is a potential for malfunction on future platforms.
If one #define's a symbol which belongs to the system namespace
rather than the user namespace, one runs the risk of a name collision.
This name collision may cause a compile-time error (e.g. if some
system header already has #define'd the same symbol), or some silent
error (if some other system header behaves differently if this
symbol is #define'd). There's no guarantee of there being an error,
but there is a possibility.
"Defined behaviour" on the other hand means a guarantee that the
program should behave in a specific way, on all standard-conforming
platforms. "Undefined behaviour" is merely the absence of this
guarantee -- but it doesn't mean there'll be an error on every
standard-conforming platform.
Therefore it is quite appropriate to say in this case that it leads
to undefined behaviour: the program may work, but there's no guarantee
that it works.
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
- Raw text -