Re: using "(void)" casts to purposefully ignore return values

[David Holland <dholland-current%netbsd.org@localhost>]

On Fri, Aug 26, 2011 at 10:27:23AM +0930, Brett Lymn wrote:
 > > And again, if you pass the same strings to strcat, demons fly out of
 > > your nose. None of the string functions are meant to accept invalid
 > > input;
 > 
 > No arugment there - but there is some belief that strl* magically make
 > it ok and that you cannot, ever, screw up.  

Uh... not that I've seen/heard. There are plenty of quite obvious
counterexamples:

e.g.

   strlcpy(NULL, str, len);

or

   void foo(char *s) {
      strlcat(s, "qwerty", sizeof(s));
   }

or

   strlcat(buf1, buf2, sizeof(buf2));

 > What I am saying is that attitude is wrong.

Obviously.

 > At least strlcat will tell you that you have
 > something wrong if the return value is checked, and that is the crux of
 > my objection, why I spoke up in the first place - it is not always ok to
 > ignore the returns from strl* because this may rise up and bit you by
 > producing a string that is not nul terminated.

No, it cannot, unless you pass it an invalid string in the first place.

 > > I don't see why the man page even bothers to define what
 > > happens in this case. Arguably, it shouldn't.
 > 
 > No, it is properly documenting the interface. Plenty of our man pages
 > have something along the lines of "passing this function crap will lead
 > to undefined results".

Yes, precisely: it should say "if dst is not null-terminated, the
behavior is undefined." And not attempt to define it.

-- 
David A. Holland
dholland%netbsd.org@localhost