On Sat, Mar 15, 2014 at 12:21:40AM +0100, Matthias Andree wrote:
>
> > At some point there will be something nasty caused by the silent
> > truncation of strings.
>
> There are strlcpy and strlcat, which take the output buffer capacity,
> and permit checking if truncation happened or no.
>
> > snprintf() is a lot better than sprintf(), but calling any of
> > the alternatives 'safe' is a complete misnomer.
>
> As though you knew all of the alternatives. If you confine yourself to
> C89-sanctioned alternatives, well, yes, but see above for others.
They are only 'safe' in that you pass the length of the target buffer.
There are still plenty of ways things can go wrong.
To make them 'safe' would need 'fat pointers' and run time checks
(possibly done by the hardware) to ensure that the code didn't
write beyond the memory that was supposed to be accessible from the
pointer.
> > Some system's header files have started forcing programs to check
> > the error returns from some library functions.
> > That gets to be a PITA - in some cases you really don't care.
>
> Cast to void.
Nope - that isn't enough.
I got away with 'if (foo(...));' - but I'm sure it won't last.
> > Also any program that looks at the return value from fprintf()
> > is probably broken anyway!
>
> Why? Buffering doesn't make error checking useless.
True, but any error is most likely to happen during the fflush()
that happens during fclose();
So if you care about errors do "fflush(); err = ferror(); fclose();"
Or call ferror() at at appropriate point in a program loop to
terminate early. Checking every fprintf() just makes the code unreadable.
David
--
David Laight: da...@l8s.co.uk
