[vox-tech] strerror deprecated?
Richard Harke
rharke at earthlink.net
Tue Dec 26 11:49:49 PST 2006
On Tue December 26 2006 09:30, 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.
>
> The compiler also told me that strerror() was unsafe. After thinking about
> it for a second, I'm guessing it meant "thread unsafe".
>
> Lastly, the compiler told me that I should use strerror_s() which is more
> safe. 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. 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?
>
> 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).
>
> What's the quickest fastest way of using strerror_r if on Linux and
> strerror_s if on Windows?
I would try the strerror_r() on MS just in case there is a doc error.
As far as buffer length -- I believe all the standard error messages
are less than a line long, i.e. less than 80 chars. Of course, if you expect
to use locales other than "C", you will probably need to double or
triple this to allow for multi-byte chars. (The locale correctness is a
motivation to use strerror and kin)
If streeror_r doesn't work on MS, there is the old and ugly macro
method:
#ifdef MS
#define Strerror_r() strerror_s()
#else
#defiene Strerror_r() strerror()
#endif
But you knew that. Sorry I can't suggest anything more elegant.
Richard
More information about the vox-tech
mailing list