@MSGID: <wwvil7sxdig.fsf@LkoBDZeT.terraraq.uk>
04e3c4fd
@REPLY:
f8f989c1@invalid.invalid> 283d3a9b
@REPLYADDR Richard Kettlewell
<invalid@invalid.invalid>
@REPLYTO 2:5075/128 Richard Kettlewell
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
<wwvil7sxdig.fsf@LkoBDZeT.terraraq.uk>
<65SQM.565977$9o89.411905@fx05.ams4><wwvpm23d9fr.fsf@LkoBDZeT.terraraq.uk> f4ce$6edf891e$2b5c40c1$f8f989c1@invalid.invalid>
@TZUTC: 0100
@PID: Gnus/5.13 (Gnus v5.13) Emacs/27.1
(gnu/linux)
@TID: FIDOGATE-5.12-ge4e8b94
Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
> Richard Kettlewell wrote:
>> It`s more than 20 years since I last had to integrate a C library which
>> reported errors via longjmp() and I`m still bitter about it.
>
> I have never encountered a library which does that.  Which library was 
> that?

libpng

>> As a matter of API design, I`d rather C library communicated errors
>> via return values (and pointer parameters, where more complex error
>> information is required).
>
> Personally, i think that, at least for a library, an error should
> _only_ be communicated by return value.  If more complex information
> is required, then the return value can be made more complex.  I don`t
> think i`ve ever used a library that communicates information via a
> pointer parameter.

Return value plus a pointer to additional information can certainly be
transformed into a struct containing both, though there`s an impact on
source code verbosity, object code size and performance.

For example if the extra information goes up to, say, 64 bytes, putting
it in a return value commits you to a 64-byte copy on every
return. However if it`s a pointer parameter, you only need to fill in
the fields relevant to the error that actually happened. In the happy
path, where there`s no error, that`s none of them.

-- 
https://www.greenend.org.uk/rjk/
--- Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
 * Origin: terraraq NNTP server (2:5075/128)
SEEN-BY: 5005/49 5015/255 5019/40 5020/715 848 1042
4441 12000 5030/49 1081
SEEN-BY: 5058/104 5075/128 6078/80
@PATH: 5075/128 5020/1042 4441