Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #3329

Re: Return value for error

From Keith Thompson <kst-u@mib.org>
Newsgroups comp.lang.c
Subject Re: Return value for error
Date 2011-05-05 14:10 -0700
Organization None to speak of
Message-ID <ln7ha4rgza.fsf@nuthaus.mib.org> (permalink)
References <e63ceea9-301d-4b90-9495-4e2a8085fae5@x1g2000yqb.googlegroups.com> <L6OdnYkzV8mMp13QnZ2dnUVZ_tidnZ2d@bestweb.net> <pan.2011.05.05.06.21.52.62000@nowhere.com> <lnvcxprw29.fsf@nuthaus.mib.org> <slrnis63qr.4fq.usenet-nospam@guild.seebs.net>

Show all headers | View raw


Seebs <usenet-nospam@seebs.net> writes:
> On 2011-05-05, Keith Thompson <kst-u@mib.org> wrote:
>> Nobody <nobody@nowhere.com> writes:
>>> On Tue, 03 May 2011 13:23:32 -0400, Kenneth Brody wrote:
>>>>   (7.26.2 reserves "macros that begin with E and a digit or E and an 
>>>> uppercase letter".)
>
>>> 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?
>
> 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.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Return value for error pozz <pozzugno@gmail.com> - 2011-05-03 01:31 -0700
  Re: Return value for error jacob navia <jacob@spamsink.net> - 2011-05-03 10:46 +0200
  Re: Return value for error Ike Naar <ike@otaku.freeshell.org> - 2011-05-03 09:04 +0000
    Re: Return value for error Ian Collins <ian-news@hotmail.com> - 2011-05-03 21:19 +1200
  Re: Return value for error James Kuyper <jameskuyper@verizon.net> - 2011-05-03 06:26 -0400
    Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-03 12:03 -0700
      Re: Return value for error "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-04 05:15 -0700
        Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-04 08:26 -0700
          Re: Return value for error "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-04 17:08 -0700
            Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-04 17:54 -0700
              Re: Return value for error "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-05 12:03 -0700
  Re: Return value for error James Dow Allen <jdallen2000@yahoo.com> - 2011-05-03 03:45 -0700
    Re: Return value for error Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-03 20:50 +0000
  Re: Return value for error pete <pfiland@mindspring.com> - 2011-05-03 07:50 -0400
    Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-03 12:04 -0700
  Re: Return value for error Martin Ambuhl <mambuhl@earthlink.net> - 2011-05-03 07:59 -0400
  Re: Return value for error Mark Storkamp <mstorkamp@yahoo.com> - 2011-05-03 08:46 -0500
  Re: Return value for error Stephen Sprunk <stephen@sprunk.org> - 2011-05-03 10:13 -0500
    Re: Return value for error William Ahern <william@wilbur.25thandClement.com> - 2011-05-03 13:08 -0700
  Re: Return value for error Kenneth Brody <kenbrody@spamcop.net> - 2011-05-03 13:23 -0400
    Re: Return value for error Peter Nilsson <airia@acay.com.au> - 2011-05-03 16:01 -0700
    Re: Return value for error Nobody <nobody@nowhere.com> - 2011-05-05 07:21 +0100
      Re: Return value for error Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-05 15:13 +0100
        Re: Return value for error Nobody <nobody@nowhere.com> - 2011-05-06 03:51 +0100
          Re: Return value for error James Kuyper <jameskuyper@verizon.net> - 2011-05-05 23:38 -0400
      Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-05 08:44 -0700
        Re: Return value for error Seebs <usenet-nospam@seebs.net> - 2011-05-05 20:49 +0000
          Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-05 14:10 -0700
            Re: Return value for error Seebs <usenet-nospam@seebs.net> - 2011-05-06 00:26 +0000
  Re: Return value for error Keith Thompson <kst-u@mib.org> - 2011-05-03 12:09 -0700

csiph-web