Re: strncpy clarify result may not be null terminated

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 4236 bytes --]

Hi Jonny,

On Tue, Nov 07, 2023 at 02:19:56PM +0000, Jonny Grant wrote:
> 
> 
> On 07/11/2023 13:23, Alejandro Colomar wrote:
> > On Tue, Nov 07, 2023 at 11:52:44AM +0000, Jonny Grant wrote:
> >> We see things differently, I'm on the C standard side on this one. Would any information change your mind?
> > 
> > It's difficult to say, but I doubt it.  But let me ask you something:
> > In what cases would you find strncpy(3) appropriate to use, and why?
> > Maybe if I understand that it helps.
> > 
> > Kind regards,
> > Alex
> 
> I don't find strncpy appropriate 

Would any information change your mind in this regard?

Let me show you some structure to which you should write using strncpy(3):

$ man utmp | sed 's/^           //' | grepc -h utmp
struct utmp {
    short   ut_type;              /* Type of record */
    pid_t   ut_pid;               /* PID of login process */
    char    ut_line[UT_LINESIZE]; /* Device name of tty - "/dev/" */
    char    ut_id[4];             /* Terminal name suffix,
                                     or inittab(5) ID */
    char    ut_user[UT_NAMESIZE]; /* Username */
    char    ut_host[UT_HOSTSIZE]; /* Hostname for remote login, or
                                     kernel version for run-level
                                     messages */
    struct  exit_status ut_exit;  /* Exit status of a process
                                     marked as DEAD_PROCESS; not
                                     used by Linux init(1) */
    /* The ut_session and ut_tv fields must be the same size when
       compiled 32- and 64-bit.  This allows data files and shared
       memory to be shared between 32- and 64-bit applications. */
#if __WORDSIZE == 64 && defined __WORDSIZE_COMPAT32
    int32_t ut_session;           /* Session ID (getsid(2)),
                                     used for windowing */
    struct {
        int32_t tv_sec;           /* Seconds */
        int32_t tv_usec;          /* Microseconds */
    } ut_tv;                      /* Time entry was made */
#else
     long   ut_session;           /* Session ID */
     struct timeval ut_tv;        /* Time entry was made */
#endif

    int32_t ut_addr_v6[4];        /* Internet address of remote
                                     host; IPv4 address uses
                                     just ut_addr_v6[0] */
    char __unused[20];            /* Reserved for future use */
};


The fields 'ut_line', 'ut_user', amd 'ut_host' are fixed-width character
array without a terminating NUL.  I wish this API hadn't been designed
this way, and thus that strncpy(3) wouldn't be useful for writing to
these structures, but we got what we got.  strcpy(3) and strlcpy(3) will
both try to write a NUL byte, thus not being able to use the last one
byte.  I would happily waste that last byte, but then if you write
portable shadow utils that are compatible with other software that may
have written those fields previously, you need to be able to support
that last character, and so you need strncpy(3).


>- that's why I proposed a change to clarify the known defect in the man page of strncpy that C99 describes. Worth reading my first email if you're unclear.

I would love to find this API useless, and in that case, I'd go further
and add [[deprecated]] in the synopsis, and write a heavy statement in a
BUGS section.  But I can't do that while it's still a good function in
some cases (even if those cases are bad design, such as utmp(5)).

On the other hand, utmp(5) has other issues, like Y2038, and AFAIR it's
being deprecated, so maybe we could consider deprecating strncpy(3).

If I see enough proof that all APIs that require this function are
deprecated, I'll happily declare the function deprecated as well.
(in fact I already did some time ago, but then found this use with
utmp(5), which is why I removed the deprecation; see
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/man3/strncpy.3?id=30d458d1a6261221bad15e58f1862e0dda24f4a0>).

Cheers,
Alex

> 
> If you doubt the esteemed C standards, I won't add anything further.
> Kind regards Jonny

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]