Re: strscpy

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Tue, May 19, 2020 at 02:39:52PM +0200, Kamil Rytarowski wrote:
> On 19.05.2020 08:09, Robert Elz wrote:
> >     Date:        Mon, 18 May 2020 20:24:06 +0200
> >     From:        Kamil Rytarowski <n54%gmx.com@localhost>
> >     Message-ID:  <0fb06a8c-959b-4f8e-58ca-b94bac1fc036%gmx.com@localhost>
> >
> >   | This is a design of several standard UNIX APIs (write(2),read(2) etc).
> >
> > I know, but those were invented back when the (relevant) arg/result were
> > int - before there were any _t's at all, and when the likelihood of any
> > application ever doing I/O of 2^32 bytes or more was slim, and where it
> > was possible, it was also safe to test the result against -1, and when
> > it was not that, simply treat it as unsigned.
> >
> > Ideally we'd fix those old interfaces, but practically that's never going
> > to happen.
> >
> 
> I object to the claim that this is broken, it's the design and feature
> that we can receive error codes for very rare situations.

The interface misdesign is a result of the missing support in C for
easily returning more than one value. E.g. consider Python-like return of a
tuple:
   len, ec = read()
So that checking ec gives you the status of the operation and no further
semantic requirements are placed on len. That also means that there is
no point in having a magic "global" variable. It can even be extended to
allow proper status reports for partial operations, i.e. "There was an
IO error after reading 100MB".

Joerg