l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2006 Dec 26 11:58

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] strerror deprecated?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] strerror deprecated?

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

> 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

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...

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.