Re: strscpy
Joerg Sonnenberger <[email protected]> Tue, 19 May 2020 16:14:33 +0200
| Newsgroups | gmane.os.netbsd.devel.security |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> > > Message-ID: <[email protected]> > > > > | 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