Re: strscpy

[Kamil Rytarowski <n54%gmx.com@localhost>]

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.

It's very unlikely to have single operation such as byte transfer that
matches the whole size of the address space. I have only once noted one
project having a workaround for >2GB write()/read() in 32bit address
space. It had a very specific use-case of IIRC gathering debug logs from
the kernel on a 32bit architecture.

> But for new interface design, there is no excuse for getting this kind of
> thing wrong.
>
>   | Even if we want to use larger values in some APIs and they are in theory
>   | allowed, we get EFBIG that is the system-wide maximum (2**63).
>
> On NetBSD as it exists currently, sure - but this is supposed to be a
> portable API, that can be used anywhere - if we had a pdp-11 port, it
> would still use 16 bit size_t and 15 bit ssize_t (off_t would be much
> larger, but that's irrelevant).
>

16bit address space support will never be possible in a modern generic
purpose operating system like NetBSD. This domain is for systems like
Fuzix or BSD 2.11.

However if we would port only this function to PDP-11, strscpy() we have
no way to avoid overlapping memory regions and this is not the domain of
this function.

> kre
>