Return value for error

[Keith Thompson]

Yeah, but that's just the standard being greedy. No common implementation
has error macros which include an underscore. Most vendors are aware that
what the standard allows is less important than what their customers will
allow.

Perhaps, but it's not difficult to avoid identifiers stasrting with 'E'.
For example, header guard macros can start with "H_". If you can be
100% sure without much more effort than it takes to be 99% sure, why not
do it?

 

[Kleuskes & Moos]

In my experience, at least some implementations define macros for
the is*() functions, macros that work by indexing into arrays.
isalpha(65535) will go well outside the bounds of the array,
with unpredictable results.

True. That would be another acceptable implementation of undefined
behavior, not the most convenient one, but still.

 (At least one implementation I've
seen defensively allows for small negative arguments, so (signed)
char arguments work as they should, even though the standard doesn't
require them to.  But you shouldn't depend on that.)

Depending on undefined behavior is a no-no of epic proportions anyway,
however conveniently the actual implementation deals with it. But
that's kicking in an open door...

Tjuus,

Kleuske.

 

[Seebs]

Perhaps, but it's not difficult to avoid identifiers stasrting with 'E'.
For example, header guard macros can start with "H_". If you can be
100% sure without much more effort than it takes to be 99% sure, why not
do it?

Yes.

I'd also point out: While they may not have *error* macros that begin
with an E followed by a digit or uppercase letter and which then contain
underscores... They may have OTHER macros that do, and they're allowed
to. 7.26.2, though it is obviously referring in this case to the EFOO
convention, does not actually state that such macros are reserved only
if they are macros which expand to an integer constant intended to be
stored in errno to reflect some possible error condition.

I find things like:

E_BAD_ARGUMENT
EX_DATAERR
E_SYSTEM_ERROR
ERR_NUM
EX_USAGE
ERROR_DISK_FULL
ERR_BOOTSEQ_FAIL
EAI_FAIL

In all, the headers on the first system I tried define more than 600
macros with names which start with a capital E followed by a digit or
capital letter. (And about 20 which follow it with an underscore, which
*isn't* reserved!)

-s

 

[Keith Thompson]

Yes.

I'd also point out: While they may not have *error* macros that begin
with an E followed by a digit or uppercase letter and which then contain
underscores... They may have OTHER macros that do, and they're allowed
to. 7.26.2, though it is obviously referring in this case to the EFOO
convention, does not actually state that such macros are reserved only
if they are macros which expand to an integer constant intended to be
stored in errno to reflect some possible error condition.

I think you mean 7.26.3, which says:

Macros that begin with E and a digit or E and an uppercase
letter may be added to the declarations in the <errno.h> header.

So if you don't have a #include <errno.h> (directly or indirectly),
you're still theoretically safe in using identifiers starting with
'E' -- though it's still a bad idea.

7.26p1 does say:

The following names are grouped under individual headers for
convenience. All external names described beloware reserved no
matter what headers are included by the program.

but I don't think macro names are considered "external names".

I find things like:

E_BAD_ARGUMENT
EX_DATAERR
E_SYSTEM_ERROR
ERR_NUM
EX_USAGE
ERROR_DISK_FULL
ERR_BOOTSEQ_FAIL
EAI_FAIL

In all, the headers on the first system I tried define more than 600
macros with names which start with a capital E followed by a digit or
capital letter. (And about 20 which follow it with an underscore, which
*isn't* reserved!)

Which means, for example, that an implementation that makes
E_BAD_ARGUMENT visible to a program that doesn't include <errno.h>
is non-conforming.

 

[Seebs]

Some time ago:
And then:

I think you mean 7.26.3, which says:

Yes. I was just quoting the earlier text, I didn't actually *look*.

So if you don't have a #include <errno.h> (directly or indirectly),
you're still theoretically safe in using identifiers starting with
'E' -- though it's still a bad idea.
Yeah.

but I don't think macro names are considered "external names".

I think you're right.

Which means, for example, that an implementation that makes
E_BAD_ARGUMENT visible to a program that doesn't include <errno.h>
is non-conforming.

Yes.

And, with the underscore, I think even if you do include <errno.h>,
it's non-conforming.

In practice, though... There are cases where I think it makes sense to
be more conservative than what is nominally guaranteed by the spec, and
I think this is one of them. I would rather not bet on implementors
not polluting the E* macro namespace.

-s

 

[Nobody]

I'll take your word for that, but every conforming implementation does
have macros that start with a E and which do include an underscore
(EXIT_SUCCESS and EXIT_FAILURE).

Right. But those *will* exist if <stdlib.h> is included.

[So does this mean that the standard conflicts with itself? A literal
reading of 7.26.3 suggests that <errno.h> is allowed to define those
macros; does this mean that including both <errno.h> and <stdlib.h>
invokes UB?]

But avoiding any (purely upper-case) macro starting with the most
common letter in the English language simply because the standard says
that it *might* be used by an implementation is overkill.

It *could* happen, although in terms of probability, I'd be more concerned
about being struck by lightning, hit by a meteorite, mauled by an escaped
tiger, etc.

 

[James Kuyper]

I'll take your word for that, but every conforming implementation does
have macros that start with a E and which do include an underscore
(EXIT_SUCCESS and EXIT_FAILURE).

Right. But those *will* exist if <stdlib.h> is included.

[So does this mean that the standard conflicts with itself? A literal
reading of 7.26.3 suggests that <errno.h> is allowed to define those
macros; does this mean that including both <errno.h> and <stdlib.h>
invokes UB?]

7.1.2p4: "Standard headers may be included in any order; each may be
included more than once in a given scope, with no effect different from
being included only once, except that the effect of including <assert.h>
depends on the definition of NDEBUG (see 7.2)."

This implies that, if <errno.h> and <stdlib.h> both define those macros,
those definitions must be protected against the kinds of problems you're
thinking of. It's not very difficult; they're both "object-like" macros;
so giving both macros the same replacement list is sufficient to satisfy
the "shall" in 6.10.3p2.