Defining standard macros

7 views
Skip to first unread message

Jack Klein

unread,
Nov 12, 2001, 8:43:46 PM11/12/01
to
This is based on a question that came up in comp.lang.c++, but I am
not sure about the legality of this issue under the standard for
either language.

Is a compiler allowed to define a standard macro in a header other
than the one specified by the standard?

The particular poster had a problem with multiple definitions because
his compiler's <stdlib.h> defined the macro errno. Is this behavior
conforming?

Doing a quick file search, I noticed that compilers from Microsoft,
Borland, and also DJGPP seem to do this. MetroWerks and lcc-win32 do
not.

If it is not strictly conforming for an implementation to define errno
in any header other than <errno.h> (or <cerrno> for C++), what about a
standard header including <errno.h>?

Is it legal for an implementation's standard headers to define a
standard macro either by definition or by inclusion if the user's
program does not directly include the standard header specified?

--
Jack Klein
Home: http://JK-Technology.Com

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]

Jun Woong

unread,
Nov 12, 2001, 11:29:23 PM11/12/01
to
In article <14puut42kuncimdh4...@4ax.com>, Jack Klein says...

>
>This is based on a question that came up in comp.lang.c++, but I am
>not sure about the legality of this issue under the standard for
>either language.
>
>Is a compiler allowed to define a standard macro in a header other
>than the one specified by the standard?
>
>The particular poster had a problem with multiple definitions because
>his compiler's <stdlib.h> defined the macro errno. Is this behavior
>conforming?
>
>Doing a quick file search, I noticed that compilers from Microsoft,
>Borland, and also DJGPP seem to do this. MetroWerks and lcc-win32 do
>not.
>
>If it is not strictly conforming for an implementation to define errno
>in any header other than <errno.h> (or <cerrno> for C++), what about a
>standard header including <errno.h>?
>
>Is it legal for an implementation's standard headers to define a
>standard macro either by definition or by inclusion if the user's
>program does not directly include the standard header specified?
>
[I post this only on csc]

This problem has a possibility to make people confused, I think this
should be fixed to express the intention well.

In general, a conforming implementation can't do that.

But we need to note that errno is a reserved identifier as having the
external linkage (7.5 and footnote 143). Thus a user can't do

char *errno;

or

#define errno ...

whether <errno.h> #included or not (4th item of 7.1.3 and 7.1.3p2).

And 7.5 also reserves it as a macro name, in which case it is
reserved ONLY when <errno.h> #included. (3rd item of 7.1.3) Once
<errno.h> is #included, a user can't do

#undef errno
{
int errno; // the purpose isn't to access an actual object, but ...

because we should consider that the wording of 7.5 ("If a macro
definition is suppressed in order to access an actual object, or a
program defines an identifier with the name errno, the behavior is
undefined") is absolute; I recall a discussion with Clive. But what
about just #undefining errno?

#include <errno.h>
#undef errno

.. // undefine errno, but never use it for other purpose!

I think this is legal regardless of #include <errno.h>.

A strange(?) but correct thing that a user can do with errno when
<errno.h> not #included is:

{
int errno; // Note that this has no linkage.
// I assume that the cited wording above from 7.5
// affects only when <errno.h> #included, and think
// it's correct understanding.

If an implementation defines errno as a macro in (e.g.,) <stdlib.h>,
then it would brake a s.c.program that does the second one above
without an implementation magic.

#include <stdlib.h>

int main(void)
{
int errno = 0;
return errno;
}


Thanks.

--
Jun Woong (myco...@hanmail.net)
Dept. of Physics, Univ. of Seoul

Jun Woong

unread,
Nov 13, 2001, 2:17:52 PM11/13/01
to
In article <14puut42kuncimdh4...@4ax.com>, Jack Klein says...
>
>This is based on a question that came up in comp.lang.c++, but I am
>not sure about the legality of this issue under the standard for
>either language.
>
>Is a compiler allowed to define a standard macro in a header other
>than the one specified by the standard?
>
>The particular poster had a problem with multiple definitions because
>his compiler's <stdlib.h> defined the macro errno. Is this behavior
>conforming?
>
>Doing a quick file search, I noticed that compilers from Microsoft,
>Borland, and also DJGPP seem to do this. MetroWerks and lcc-win32 do
>not.
>
>If it is not strictly conforming for an implementation to define errno
>in any header other than <errno.h> (or <cerrno> for C++), what about a
>standard header including <errno.h>?
>
>Is it legal for an implementation's standard headers to define a
>standard macro either by definition or by inclusion if the user's
>program does not directly include the standard header specified?
>

This problem has a possibility to make people confused, I think this


should be fixed to express the intention well.

In general, a conforming implementation can't do that.

But we need to note that errno is a reserved identifier as having the
external linkage (7.5 and footnote 143). Thus a user can't do

char *errno;

or

#define errno ...

whether <errno.h> #included or not (4th item of 7.1.3 and 7.1.3p2).

And 7.5 also reserves it as a macro name, in which case it is
reserved ONLY when <errno.h> #included. (3rd item of 7.1.3) Once
<errno.h> is #included, a user can't do

#undef errno
{
int errno; // the purpose isn't to access an actual object, but ...

because we should consider that the wording of 7.5 ("If a macro
definition is suppressed in order to access an actual object, or a
program defines an identifier with the name errno, the behavior is
undefined") is absolute; I recall a discussion with Clive. But what
about just #undefining errno?

#include <errno.h>
#undef errno

... // undefine errno, but never use it for other purpose!

char *errno;

or

#define errno ...

#include <errno.h>
#undef errno

... // undefine errno, but never use it for other purpose!

I think this is legal regardless of #include <errno.h>.

A strange(?) but correct thing that a user can do with errno when
<errno.h> not #included is:

{
int errno; // Note that this has no linkage.
// I assume that the cited wording above from 7.5
// affects only when <errno.h> #included, and think
// it's correct understanding.

If an implementation defines errno as a macro in (e.g.,) <stdlib.h>,
then it would brake a s.c.program that does the second one above
without an implementation magic.

#include <stdlib.h>

int main(void)
{
int errno = 0;
return errno;
}


Thanks.


--
Jun Woong (myco...@hanmail.net)
Dept. of Physics, Univ. of Seoul

---

Michiel Salters

unread,
Nov 13, 2001, 2:21:19 PM11/13/01
to
In article <14puut42kuncimdh4...@4ax.com>, Jack Klein says...
>
>This is based on a question that came up in comp.lang.c++, but I am
>not sure about the legality of this issue under the standard for
>either language.
>
>Is a compiler allowed to define a standard macro in a header other
>than the one specified by the standard?

Yes, because each standard header may include any other standard header.
In general, if a.h should define X, it can also include b.h which actually
defines X. The users of b.h can't determine whether b.h defined X or included
a.h and got X as a side effect. Another way of looking at it is that all
standard headers could be implemented as "#include <stdall.h>" which
would be the union of std headers.

Regards,
Michiel Salters

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel...@cmg.nl

Douglas A. Gwyn

unread,
Nov 13, 2001, 2:22:11 PM11/13/01
to
Jack Klein wrote:
> Is a compiler allowed to define a standard macro in a header other
> than the one specified by the standard?

No, although some macros are specified as being defined in
multiple standard headers. The exact rules are near the
beginning of the library section of the C standard.

> The particular poster had a problem with multiple definitions because
> his compiler's <stdlib.h> defined the macro errno. Is this behavior
> conforming?

There is no such thing as "conforming behavior". Presumably
you wonder if the *implementation* conforms to the standard.
>From the information supplied, we cannot determine that.

The usual problem with errno is that some source files have
explicitly coded a declaration:
extern int errno;
But errno does not *have* to refer to an object of type int
having external linkage, and if some (possibly conforming)
implementation took advantage of the *actual* specification
to make errno a macro that, e.g. invokes a function or a
compiler intrinsic, that could easily conflict with the
explicit declaration in the program.

> If it is not strictly conforming for an implementation to define errno
> in any header other than <errno.h> (or <cerrno> for C++), what about a
> standard header including <errno.h>?

That would define errno, nicht wahr?

> Is it legal for an implementation's standard headers to define a
> standard macro either by definition or by inclusion if the user's
> program does not directly include the standard header specified?

? The requirements of the standard are much clearer to me
than this question is.

James Kuyper Jr.

unread,
Nov 14, 2001, 5:20:07 AM11/14/01
to
Michiel Salters wrote:
>
> In article <14puut42kuncimdh4...@4ax.com>, Jack Klein says...
> >
> >This is based on a question that came up in comp.lang.c++, but I am
> >not sure about the legality of this issue under the standard for
> >either language.
> >
> >Is a compiler allowed to define a standard macro in a header other
> >than the one specified by the standard?
>
> Yes, because each standard header may include any other standard header.

This thread is cross-posted to both comp.std.c and comp.std.c++. Your
statement is not true in C. It is true in C++; see 17.4.4.1p1 of the C++
standard; however, even in C++ code it only applies to the C++ headers -
it doesn't apply to the C headers that are also legal to include in C++
programs.

The logic showing that this is prohibited in C is somewhat subtle. The
relevant clauses of the C standard are the ones in 7.3.1p1, governing
reserved identifiers:

"...
--_ Each macro name in any of the following subclauses (including the
future library directions) is reserved for use as specified if any of
its associated headers is included; unless explicitly stated otherwise
(see 7.1.4).
...
--_ Each identifier with file scope listed in any of the following
subclauses (including the future library directions) is reserved for use
as a macro name and as an identifier with file scope in the same name
space if any of its associated headers is included."

Since those identifiers are reserved ONLY if the relevant headers are
#included, they cannot be defined in any of the other headers, directly
or by #inclusion. Otherwise, code that used those identifiers in a
non-reserved fashion would break.

For instance, imagine that <math.h> #includes <float.h>. Then the
following perfectly legal code would break:

#include <math.h>
// DBL_MAX is not reserved, since <float.h> has NOT been #included.
double DBL_MAX(const char *p) { return nan(p);}

Granted, that code represents extremely bad coding practice, but it is
legal.

Lawrence Kirby

unread,
Nov 14, 2001, 1:22:11 PM11/14/01
to
In article <LK3I7.22738$xS6....@www.newsranger.com>
Michiel...@cmg.nl "Michiel Salter" writes:

>In article <14puut42kuncimdh4...@4ax.com>, Jack Klein says...
>>
>>This is based on a question that came up in comp.lang.c++, but I am
>>not sure about the legality of this issue under the standard for
>>either language.
>>
>>Is a compiler allowed to define a standard macro in a header other
>>than the one specified by the standard?
>
>Yes, because each standard header may include any other standard header.

The C standard gives no such permission.

>In general, if a.h should define X, it can also include b.h which actually
>defines X. The users of b.h can't determine whether b.h defined X or included
>a.h and got X as a side effect.

If a.h unconditionally defines X and b.h is not permitted to define X then
b.h cannot include a.h.

>Another way of looking at it is that all
>standard headers could be implemented as "#include <stdall.h>" which
>would be the union of std headers.

This is not true in C, I'd be surprised if it is true in C++. Standard C
headers have a set of identifiers that they must define in the appropriate
way. There are also reserved sets of identifiers, some related to particular
headers. A standard header can define identifiers that are generally
reserved or which are reseved when that particular header is included. It
cannot define other identifiers.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------

Bruce Wheeler

unread,
Nov 14, 2001, 1:22:14 PM11/14/01
to
On Wed, 14 Nov 2001 10:20:07 GMT, "James Kuyper Jr." <kuy...@wizard.net>
wrote:

...
[snip]

As you say, the C standard states "if any of its associated headers is
included", not "if and only if any of its associated headers is
included".

>Since those identifiers are reserved ONLY if the relevant headers are
>#included, they cannot be defined in any of the other headers, directly
>or by #inclusion.

Wouldn't it be possible for an implementor to argue that it is
implementation-defined whether the 'only if' implication holds, ie, that
the above statement need not necessarily hold?

Regards,
Bruce Wheeler

Niklas Matthies

unread,
Nov 14, 2001, 6:21:12 PM11/14/01
to
On Wed, 14 Nov 2001 18:22:14 GMT, Bruce Wheeler <bruce....@siemens.at> wrote:
> On Wed, 14 Nov 2001 10:20:07 GMT, "James Kuyper Jr." <kuy...@wizard.net> wrote:
> >Michiel Salters wrote:
[···]

> >"...
> >--_ Each macro name in any of the following subclauses (including the
> >future library directions) is reserved for use as specified if any of
> >its associated headers is included; unless explicitly stated otherwise
> >(see 7.1.4).
> >...
> >--_ Each identifier with file scope listed in any of the following
> >subclauses (including the future library directions) is reserved for use
> >as a macro name and as an identifier with file scope in the same name
> >space if any of its associated headers is included."
> >
> ...
> [snip]
>
> As you say, the C standard states "if any of its associated headers is
> included", not "if and only if any of its associated headers is
> included".
>
> >Since those identifiers are reserved ONLY if the relevant headers are
> >#included, they cannot be defined in any of the other headers, directly
> >or by #inclusion.
>
> Wouldn't it be possible for an implementor to argue that it is
> implementation-defined whether the 'only if' implication holds, ie, that
> the above statement need not necessarily hold?

Another way to argue would be to say that "if any of its associated
headers are included" also encompasses inclusion some other standard
header that itself happens to include one of the "associated headers".

-- Niklas Matthies
--
You have moved your mouse. Windows must be rebooted for the
changes to take effect.

James Kuyper Jr.

unread,
Nov 15, 2001, 11:56:33 AM11/15/01
to
Lawrence Kirby wrote:
...

> >Another way of looking at it is that all
> >standard headers could be implemented as "#include <stdall.h>" which
> >would be the union of std headers.
>
> This is not true in C, I'd be surprised if it is true in C++.

Section 17.4.4.1p1 of the C++ standard explicitly allows any C++
standard header to #include and other C++ standard header. This
permission does not extend to the headers inherited from C.

Jun Woong

unread,
Nov 15, 2001, 11:56:47 AM11/15/01
to
bruce....@siemens.at (Bruce Wheeler) wrote in message news:<3bf2619c...@news.siemens.at>...

> On Wed, 14 Nov 2001 10:20:07 GMT, "James Kuyper Jr." <kuy...@wizard.net> wrote:
[...]

> >
> >"...
> >--_ Each macro name in any of the following subclauses (including the
> >future library directions) is reserved for use as specified if any of
> >its associated headers is included; unless explicitly stated otherwise
> >(see 7.1.4).
> >...
> >--_ Each identifier with file scope listed in any of the following
> >subclauses (including the future library directions) is reserved for use
> >as a macro name and as an identifier with file scope in the same name
> >space if any of its associated headers is included."
> >
> ...
> [snip]
>
> As you say, the C standard states "if any of its associated headers is
> included", not "if and only if any of its associated headers is
> included".
>
> >Since those identifiers are reserved ONLY if the relevant headers are
> >#included, they cannot be defined in any of the other headers, directly
> >or by #inclusion.
>
> Wouldn't it be possible for an implementor to argue that it is
> implementation-defined whether the 'only if' implication holds, ie, that
> the above statement need not necessarily hold?
>

An implementor of a conforming implementation can't:
- declare other identifiers than the C Standard permits to reserve and
- #include a standard header in other standard headers.

I'm not sure whether I saw these in a part of the C Standard or other
C books (in which case "everyone knows" clause :). But the first
requirement implies the second, and the first requirement can be
derived from 7.1.3p1 and 7.1.3p2 of the C Standard:

] Each header declares or defines all identifiers listed in its
] associated subclause, and optionally declares or defines identifiers
] listed in its associated future library directions subclause and
] identifiers which are always reserved either for any use or for use
] as file scope identifiers.
]
] - items, some of which are cited by James Kuyper
]
] No other identifiers are reserved.

Is this unreasonable interpretation?

If an experienced implementor which claims that his implementation
conforms to the C Standard violates any of the above requirements, I
would think it's due to complexity of the Standard, not a deficient
description of the Standard; for example, it's hard to know that a


conforming implementation can't do

#define offsetof(s,m) ((NULL)[...])

even in <stddef.h>.


--
Jun Woong (myco...@hanmail.net)
Dept. of Physics, Univ. of Seoul

---

Clive D. W. Feather

unread,
Nov 15, 2001, 2:34:39 PM11/15/01
to
In article <3bf2619c...@news.siemens.at>, Bruce Wheeler
<bruce....@siemens.at> writes

>As you say, the C standard states "if any of its associated headers is
>included", not "if and only if any of its associated headers is
>included".

It is a general principle of the C Standard that only those things
stated apply; if it isn't stated, it doesn't apply.

In this case, it says:

[#1] Each header declares or defines all identifiers listed


in its associated subclause, and optionally declares or
defines identifiers listed in its associated future library
directions subclause and identifiers which are always
reserved either for any use or for use as file scope
identifiers.

[...]
[#2] No other identifiers are reserved.

That's it. A header declares the things it says it declares. It might
declare various reserved names if they're reserved. NOTHING ELSE.

If the intention was that a name could be declared by any header if any
other header reserved it, then there would be no point in having stuff
reserved by only one header.

>Wouldn't it be possible for an implementor to argue that it is
>implementation-defined whether the 'only if' implication holds,

No, because the standard doesn't say so.

Any more than an implementation could say "it is implementation-defined
whether 2 + 2 is 4".

--
Clive D.W. Feather, writing for himself | Home: <cl...@davros.org>
Tel: +44 20 8371 1138 (work) | Web: <http://www.davros.org>
Fax: +44 20 8371 4037 (D-fax) | Work: <cl...@demon.net>
Written on my laptop; please observe the Reply-To address


======================================= MODERATOR'S COMMENT:
No C++-standard-related material in this post; please consider splitting the thread.

Andrew Koenig

unread,
Nov 15, 2001, 3:17:52 PM11/15/01
to
Clive> That's it. A header declares the things it says it declares. It might
Clive> declare various reserved names if they're reserved. NOTHING ELSE.

On the other hand, any C++ header is permitted to include any other
C++ header. This is a difference from C. I personally think it's
unfortunate, but it's there, and it is intentional.

--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark

Bruce Wheeler

unread,
Nov 16, 2001, 5:43:28 AM11/16/01
to
(Posting only to comp.std.c, following the recommendation of the
comp.std.c++ moderator.)

On Thu, 15 Nov 2001 19:34:39 GMT, "Clive D. W. Feather"
<cl...@on-the-train.demon.co.uk> wrote:

>In article <3bf2619c...@news.siemens.at>, Bruce Wheeler
><bruce....@siemens.at> writes
>>As you say, the C standard states "if any of its associated headers is
>>included", not "if and only if any of its associated headers is
>>included".
>
>It is a general principle of the C Standard that only those things
>stated apply; if it isn't stated, it doesn't apply.
>

Thanks for the clarification. Thanks also to Jun Woong for his response.
However, a few points remain unclear to me.

I would interpret this to say that 'what the C standard doesn't
disallow, it allows', rather than what it doesn't allow, it disallows'.
Would you disagree with that interpretation?

>In this case, it says:
>
> [#1] Each header declares or defines all identifiers listed
> in its associated subclause, and optionally declares or
> defines identifiers listed in its associated future library
> directions subclause and identifiers which are always
> reserved either for any use or for use as file scope
> identifiers.
>[...]
> [#2] No other identifiers are reserved.
>

Aha, that's the key. James Kuyper didn't quote #2 above. I didn't
understand the power of that statement on first reading. It provides the
'only if' implication I was seeking. However, given that three fairly
major implementations misapplied this section in the current context
(assuming the wording is the same in C90), the statement could perhaps
be more clear.

>>Wouldn't it be possible for an implementor to argue that it is
>>implementation-defined whether the 'only if' implication holds,
>
>No, because the standard doesn't say so.
>
>Any more than an implementation could say "it is implementation-defined
>whether 2 + 2 is 4".
>

I assume you are referring to
6.5.6 Additive operators
...
[#5] The result of the binary + operator is the sum of the
operands.
Assuming the definition of 'sum' is adequately covered by section 3, and
has a meaning consistent with normal mathematical usage, it seems quite
clear what addition in the integer types must do, absent other
considerations, such as overflow (ie 2 + 2 seems mandated to equal 4).
There seems to be less subtlety here than in the identifier declaration
case above.

However, your example is perhaps not a good one :-).

As you certainly know, whether 2.0 + 2.0 == 4.0 is implementation
defined.

5.2.4.2.2
[#4]
The accuracy of the floating-point operations (+, -, *, /) and of the
library functions in <math.h> and  <complex.h> that   return 
floating-point   results  is  implementation defined.  The
implementation may state that the accuracy  is unknown.

This is one of my least favorite paragraphs in the C standard!

>--
>Clive D.W. Feather, writing for himself | Home: <cl...@davros.org>
>Tel: +44 20 8371 1138 (work) | Web: <http://www.davros.org>
>Fax: +44 20 8371 4037 (D-fax) | Work: <cl...@demon.net>
>Written on my laptop; please observe the Reply-To address
>
>
>======================================= MODERATOR'S COMMENT:
> No C++-standard-related material in this post; please consider splitting the thread.
>

Regards,
Bruce Wheeler

John E. Gwyn

unread,
Nov 16, 2001, 6:57:31 PM11/16/01
to
Bruce Wheeler wrote:
> 5.2.4.2.2
> [#4]
> The accuracy of the floating-point operations (+, -, *, /) and of the
> library functions in <math.h> and <complex.h> that return
> floating-point results is implementation defined. The
> implementation may state that the accuracy is unknown.
> This is one of my least favorite paragraphs in the C standard!

However, it is useful, since it forces implementations to advertise
their f.p. accuracy, which can at least embarrass implementors into
doing a reasonable job. It is not feasible to *require* particular
accuracy standards in general, due to the wide variety of f.p.
hardware that exists. Newer platforms tend to provide *almost*
IEEE/IEC f.p. conformance, and if you really want to specify binding
to that additional set of requirements, C99 provides an optional
binding for that purpose.

Bruce Wheeler

unread,
Nov 19, 2001, 6:01:18 AM11/19/01
to

Thanks for the insight.

However, would it have been impossible (or inadvisable) to mandate
something like the following, at least for the standard operators
(perhaps also for the library functions in <math.h> and <complex.h>)?

'If the operands are representable values and the correct result of the
operation is also a representable value, the operation shall return this
representable value', or at least 'the operation shall return this
representable value, or the larger or smaller representable value
immediately adjacent to this representable value, chosen in an
implementation-defined manner' (in the spirit of 6.4.4.2 #3).

Regards,
Bruce Wheeler

James Kuyper Jr.

unread,
Nov 19, 2001, 7:14:02 AM11/19/01
to
Bruce Wheeler wrote:
...

> However, would it have been impossible (or inadvisable) to mandate
> something like the following, at least for the standard operators
> (perhaps also for the library functions in <math.h> and <complex.h>)?
>
> 'If the operands are representable values and the correct result of the
> operation is also a representable value, the operation shall return this
> representable value', or at least 'the operation shall return this
> representable value, or the larger or smaller representable value
> immediately adjacent to this representable value, chosen in an
> implementation-defined manner' (in the spirit of 6.4.4.2 #3).

Yes, it is inadviseable, because on many platforms that would mean that
some operations could only be implemented, if at all, by the use of
extremely slow algorithms. The fundamental problem is the sensitivity of
the result to the value of the argument. For y=f(x), the relevant
measure is (df/dx)*(x/y). When that measure is large, it's very
expensive (and perhaps impossible) to achieve that goal. Section
6.4.4.2p3 is essentially talking about rounding, for which that measure
is exactly 1.0.

It's trivial to construct examples for which that measure is effectively
infinite. For example, consider sin(nextafter(4.0*atan(1.0),0.0)), or
even worse, sin(1e37). Try to figure out efficient alogorithms that
will handle those cases to the precision you're suggesting. I used
nextafter() in these examples to avoid any possibilities of special-case
handling.

Bruce Wheeler

unread,
Nov 19, 2001, 10:18:35 AM11/19/01
to

Thanks for pointing this out.

After contemplating your examples, and rereading the 'float' chapter in
PJ Plauger's 'The C Standard Library', I concede that it may not be
possible to specify accuracy beyond the what is in the C standard, if C
is to be implementable over a large class of platforms. It does seem
best to leave floating-point accuracy as implementation-defined :-(.

'There have even been some come computers (not designed by Cray) that
scrub the four least significant bits when you multipy by one!'
...
'If the C Standard had tried to outlaw this behavior, it would never
have been approved'.

from Plauger, 'The C Standard Library', p 59 (referring to C89, but
still relevant to C99).

Regards,
Bruce Wheeler

John E. Gwyn

unread,
Nov 20, 2001, 1:22:46 AM11/20/01
to
Bruce Wheeler wrote:
> After contemplating your examples, and rereading the 'float' chapter in
> PJ Plauger's 'The C Standard Library', I concede that it may not be
> possible to specify accuracy beyond the what is in the C standard, if C
> is to be implementable over a large class of platforms. It does seem
> best to leave floating-point accuracy as implementation-defined :-(.

Thanks for finally concluding that there is good reason for the
standard being the way it is on this issue.

In practice, it's not a big problem, for a variety of reasons:
(1) If IEEE f.p. is desired, there is a standard way to specify that.
(2) If f.p. performance (accuracy and/or speed) is a procurement issue,
it is normally determined by running benchmark tests.
(3) Properly educated numerical programmers understand that f.p.
provides inherently only an approximation to the real number system,
and they take stability etc. into account when designing algorithms.
(4) Algorithms that are tricky to code well enough are frequently
available off-the-shelf via third-party libraries.

Another way of putting it is that anyone whose code depends on 1./3
equalling 3./9 is either too ignorant to be allowed to code critical
algorithms or else is an expert who should know how to ensure that
such requirements *will* be met.

Reply all
Reply to author
Forward
0 new messages