Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: error_t proposal
Date: Fri, 06 Sep 2019 11:18:34 -0700
Organization: None to speak of
Lines: 34
Message-ID: <lnblvxthj9.fsf@kst-u.example.com>
References: <5d03868d-22f7-4c7f-9f9b-1e70d8d8e6f2@googlegroups.com> <slrnqn1n88.cdo.grahn+nntp@frailea.sa.invalid> <270b0679-c176-4e05-9d18-6dc6dcbdb75a@googlegroups.com> <lna7biv2pg.fsf@kst-u.example.com> <0a0905d7-2c2d-45c0-b028-9de1f98fc9e0@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="bdc446bce191e4e891bf0ef7ae57c831"; logging-data="1289"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/MiQroBJOUX1YpZ9nKtCrp"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:E+YC8O9Ir0YcxWxLlyNAuq0laO8= sha1:nDEjexCOvqh+9NtsyP2yx5KNheY=
Xref: csiph.com comp.lang.c:146070

Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> I am happy to have found errno_t in the C11 standard.
> I will not change bool for errno_t in my current programs (because 
> this creates a inverse logic) but I intend to use errno_t in new 
> programs.

Then your new programs won't compile with implementations that don't
support the optional Annex K (unless you define errno_t yourself).

> I am starting to think that is not so bad not having a constant
> for success.(that is zero by definition of errno_t)
> POSIX also don't have a 'no error' constant. Maybe if it had
> probably this would be the success constant for errno_t .
>
> Having the type errno_t  automatically shows the function contract.

I'll note that the intended use of errno_t is for the value of errno.
Most conventions don't have functions returning error codes.  Many POSIX
functions for example, return 0 for success and 1 for failure, with
errno set to indicate which error occurred.  (Linux kernel functions
that implement system calls typically return a non-negative value for
success or a negated E* value for failure, but that's mapped to setting
errno when a user-space program calls them.)

I agree it would be nice to have a convention that's (a) more consistent
and (b) returns both the result and the status from the function rather
than using the ugly errno mechanism.  But there's only so much you can
do given the existing standards and libraries.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */