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 15:49:19 -0700
Organization: None to speak of
Lines: 37
Message-ID: <lnpnkdrqfk.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> <lnblvxthj9.fsf@kst-u.example.com> <ff9369c1-8c4b-4eb5-a21a-24a1a836b69d@googlegroups.com> <87mufhxksn.fsf@bsb.me.uk> <ln36h9tbw6.fsf@kst-u.example.com> <4b1b8896-4fa9-4904-a1dc-ef5a0cb0459b@googlegroups.com> <lny2z1rubm.fsf@kst-u.example.com> <a26fc677-686d-4d93-ba85-9d0f3430ba4e@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="46dcb8b74213274923523f422b46dcb1"; logging-data="5448"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18pVwxY4tBN5X41xQluHEDY"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:8hWgg+35B3mJMsmTX1Or0kD08mE= sha1:sHzgLlYdz4l4noe/78vjw9rtIkQ=
Xref: csiph.com comp.lang.c:146085

Thiago Adams <thiago.adams@gmail.com> writes:
> On Friday, September 6, 2019 at 6:25:27 PM UTC-3, Keith Thompson wrote:
[...]
>> If you want to define your own error type, I suggest *not* calling it
>> "errno_t" as C11 Annex K does.  Support for Annex K is not widespread,
>> and it's been proposed for removal in the next edition.
>> 
>> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm#adi>
>
> I think they should do a fix. In the worst case just ignore the 
> extra arguments and leave it for static analysis.

I don't think that will happen.

>> I like the idea of a consistent error reporting convention for library
>> functions, but existing and widely used libraries are *not* consistent,
>> and that's not going to change any time soon.  What is the intended
>> scope of your proposal?
> Sorry, I didn't understand you question.

For example, are you pushing for POSIX and other standards/libraries to
be updated to adopt your proposal?  Or just newly designed libraries?
Or just your own?

> The objective of having a error_t is very similar of having a bool.
> We have a common contract in the standard and other libs can use
> the same contract as well.
> When someone creates a multiplatform code, this type can be used.
> Doesn't matter if the SO is different, but interface is adapting the 
> contract.
> If I create my own code it doesn't help too much because the contract
> is by lib basis instead of universal.

-- 
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 */