[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] strncpy(3), die, die, die.

From: Steffen Nurpmeso
Subject: Re: [Nmh-workers] strncpy(3), die, die, die.
Date: Sun, 30 Oct 2016 01:59:28 +0200
User-agent: s-nail v14.9.0-pre1-107-g14b5a3a

Hi.  Damn it's late...

Ralph Corderoy <address@hidden> wrote:
 |> Therefore i think a function like the Linux strscpy()
 |That was a new one to me.  I found it, https://manned.org/strscpy.9
 |It's defined in the Linux kernel.
 |    ssize_t strscpy(char * dest, const char * src, size_t count);
 |Does nothing if count is zero.  Otherwise, it's dest's size.
 |Copies src to dest, as much as fits, truncating, and ensuring it's NUL
 |Returns -E2BIG if truncation occurs.

Yes, it is pretty new - i think it essentially is what strncpy()
should have been from the beginning.  Effectively

  FL ssize_t
  n_strscpy(char *dst, char const *src, size_t dstsize){
     ssize_t rv;

     if(LIKELY(dstsize > 0)){
        rv = 0;
           if((dst[rv] = src[rv]) == '\0')
              goto jleave;
        }while(--dstsize > 0);
        dst[--rv] = '\0';
  #ifdef HAVE_DEVEL
        assert(dstsize > 0);
     rv = -1;
     return rv;

You know, -E2BIG and POSIX ssize_t is allowed to be invalid, but
i don't get the fun behind that.  ssize_t is not ISO C, that is
anything else but fun, in my opinion.
The Linux kernel guys have used their usual optimization.  (I
really thought it is the same that i have seen around Y2K for
generic strlen().  Or was it GNU LibC strlen()?  But that one.)
Also ~U (!U)ing this (late!):

 |> i use asprintf() for this kind of thing.
 |It's nice, but it might do the formatting work twice, and the return
 |value needs checking, not just for "out of memory" errors, the char** is
 |not guaranteed to be NULL on error with GNU, and that checking conflicts
 |with the "minimal call-site change" that's my aim.

In my opinion that is really terrible.  Indeed i am very, very
prowd of my context idea, especially so now that i have been
pointed to Plan9 and i have seen that the really extraordinary
guys had the same idea.  I.e., you have a format context object
and call in, from I/O stream, dynamic string, stack buffer,
whatever, and it does as much as it can, and gives back a status.
Then you can feed in more buffer and continue where it stopped
(not restart) if you want to.  The standard I/O goes the very
opposite way, you feed in a string and at the back of the scene it
dispatches readily prepared data, but that interface not
standardized.  That is _so_ terrible.  Always hated it.
Good night, and a nice Sunday!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]