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

Groups > comp.lang.c > #3162 > unrolled thread

Return value for error

Back to article view | Back to comp.lang.c

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#3206

Kenneth Brody <kenbr...@spamcop.net> wrote:
> pozz wrote:
> > #define ERROR_OK  0
> > #define ERROR_UNDEFINED 1
> > #define ERROR_WRONGVALUE 2
>
> Nit:
>
> Those are, technically, all reserved for implementation-
> defined error codes.
>   (7.26.2 reserves "macros that begin with E and a digit
> or E and an uppercase letter".)

Strictly only in the precence of <errno.h>, but it's still best
to avoid EXXX macro names. Header include guards are a common trap.

--
Peter

[toc] | [prev] | [next] | [standalone]

#3250

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.

[toc] | [prev] | [next] | [standalone]

#3269

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.

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

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#3348

On Thu, 05 May 2011 15:13:14 +0100, Ben Bacarisse 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.
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#3349

On 05/05/2011 10:51 PM, Nobody wrote:
> On Thu, 05 May 2011 15:13:14 +0100, Ben Bacarisse wrote:
...
>> 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.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#3272

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?

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

[toc] | [prev] | [next] | [standalone]

#3326

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 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
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#3329

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"

[toc] | [prev] | [next] | [standalone]

#3340

Some time ago:
>>>> 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".)

And then:

On 2011-05-05, Keith Thompson <kst-u@mib.org> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> 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:

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.

However, I would never want to write code which gambled on <errno.h>
not having gotten somehow invoked.

> 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
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#3188

pozz <pozzugno@gmail.com> writes:
> A very simple question. What do you use as the return value of a
> function for error/ok results?
> I can't decide between 0 for error and !=0 for ok, or 0 for ok and !=0
> for errors.
>
> If !=0 is ok, I can write:
>
>   if (myfunction()) printf("OK\n");
>
> but I have only one error code (0), while, in some cases, it could be
> useful to have more informations about the type of error.
>
> If !=0 is error I can have several error codes, but I have to write
>
>   if (!myfuction()) printf("OK\n");
>
> that apparently seems myfunction has not terminated with success.

Just because you're checking whether a result is equal to zero, you
don't *have* to use the "!" operator.

Personally, I use "!" only for values that are logically Boolean
(zero means false, anything non-zero means true, and there's no
meaningful distinction among different non-zero values).  So I
might write the above as:

    if (myfunction() == 0) printf("OK\n");

Or I might define a constant of some sort with the value 0
to make the code clearer, as you suggest:

> Another strategy is to define custom error code:
>
> #define ERROR_OK  0
> #define ERROR_UNDEFINED 1
> #define ERROR_WRONGVALUE 2
>
> and so on, and always write:
>
>   if (myfuction() == ERROR_OK) printf("OK\n");

(but not with a name that's reserved to the implementation).

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web