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/ _______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
