[vox-tech] strerror deprecated?

[Micah Cowan]

On Tue, 2006-12-26 at 12:30 -0500, Peter Jay Salzman wrote:
> Hi all,
> 
> Trying to write portable/correct code between Linux and MS Visual C++.
> 
> The cl.exe compiler is telling me that "strerror() is deprecated".  Is that
> true?  I never heard such a thing.  Tried Googling and couldn't find any
> mention of strerror() being deprecated.

I recently saw a similar message (for some other user: I'm not compiling
on MS these days) about strncpy(). Rest assured, strerror() is not and
will not be deprecated.

> The compiler also told me that strerror() was unsafe.  After thinking about
> it for a second, I'm guessing it meant "thread unsafe".

Thread unsafe... I'm starting to think they're going to issue that
warnign for anything that's actually portable and in the standard
library...

> Lastly, the compiler told me that I should use strerror_s() which is more
> safe.

Same for strncpy(): strncpy_s().

> I looked at the prototype for this function and it requires a buffer,
> the buffer's length, and the errno.  Passing a char * to be filled by a
> function when you don't know how large of a buffer that function wants
> hardly sounds like a good idea.

Well, since you pass the buffer's length, it will probably safely
truncate the message.

If it was designed well enough that it works like snprintf(), you could
pass it a 0 to get the size of the buffer you could pass it.

> How should this function be used safely?
> Keep allocating memory until the buffer isn't filled all the way?  Sounds
> like I would need to write my own strerror function just to make sure the
> buffer is large enough.  Why would a standards committee do such a thing?

Oh, they wouldn't. The Standard has absolutely no concept whatever of
strerror_s() (or indeed, of thread safety). It's an MS-ism.

> 
> Lastly, strerror_s doesn't appear in any man pages on my Linux system.
> However, it does appear to be similar to strerror_r() which my man pages say
> is POSIX compliant (under a suitable #define).

I'd forgotten about that. It seems to suffer from the same problem,
though: no way to determine appropriate string buffer size.

> What's the quickest fastest way of using strerror_r if on Linux and
> strerror_s if on Windows?

Are you writing a threaded program? If not, ignore Windows' broken
warnings: they're completely bogus. Better yet, find a way to disable
them.

If you are, I'd suggest wrapping strerror() with a locking mechanism,
use plain strerror() to get the static string and check its size, and
proceed however you like. I'd probably use a snprintf()-style mechanism,
or perhaps something more like strerrordup().

I'd start the wrapper with something other than "str" followed by
lowercase letters, as that's reserved to the implementation.
str_error_dup() would be fine, though.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/