Re: lib/53640: getnstr(3) shall read at most n characters, not n-1

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

The following reply was made to PR lib/53640; it has been noted by GNATS.

From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: lib/53640: getnstr(3) shall read at most n characters, not n-1
Date: Sat, 29 Sep 2018 17:57:28 +0300

 On Sat, Sep 29, 2018 at 16:46:42 +0300, Valery Ushakov wrote:
 
 > > While the NetBSD curses(3) behavior might be defendable it diverges
 > > from the idiom of gets(3) + fgets(3). fgets(3) is documented to read
 > > at most N-1 characters and it does so.
 
 Well, it looks to me that exactly opposite is true.  The NetBSD
 behavior uses the same idiom for fgets() and getnstr() as you pass the
 buffer size in both cases.
 
 In your test code you use A[4] with:
 
     fgets(A, 4, stdin);
 
 to read 3 characters, but:
 
     getnstr(A, 3);
 
 Which in the ncurses case, that you claim to be correct, also reads 3
 characters, but only reads 2 with NetBSD curses.  In other words, to
 read 3 characters with NetBSD curses you need
 
     genstr(A, 4);
 
 which is nicely parallel to fgets(A, 4, ...)
 
 Solaris - both its "traditional" curses (that one doesn't have
 getnstr(), only wgetnstr()) and XPG4 curses - has the same behavior as
 NetBSD.  While its man page says:
 
      The getnstr(),  mvgetnstr(),  mvwgetnstr()  and   wgetnstr()
      functions  read  at  most n characters.  These functions are
      used to prevent overflowing the input buffer.
   [...]
      n      Is the maximum number  of  characters  to  read  from
             input.
 
 it actually treats n as the complete buffer size and will read at most
 n-1 characters, always NUL-terminating the buffer.
 
 NetBSD manual actually does't say that it reads n characters, it says:
 
   Calling getnstr(), wgetnstr(), mvgetnstr() or mvwgetnstr() is effectively
   the same as calling getch() repeatedly until a newline is received or the
   character limit limit is reached.  Once this happens the string is NULL
   terminated and returned in str.
 
 and you can get into sophistry about what reaching the limit actually
 means :), since the string needs to be NUL terminated (which is
 explicitly stated) within the limit (which is NOT explicitly stated,
 but is, I think, a natural interpretation, giving e.g. fgets), you can
 argue that reading n-1 character is counted as reaching the limit n.
 
 ncurses manual doesn't say anything about nul-terminating the input
 string.
 
 To sum it up
 
 1) all manual pages that I checked suck at precisely specifying what
    the functions actually do
 
 2) observed NetBSD behavior looks a better, more consistent choice
 
 
 -uwe