Re: [vox-tech] strerror deprecated?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] strerror deprecated?
On Tue 26 Dec 06, 10:37 AM, Micah Cowan <firstname.lastname@example.org> said:
> 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.
I took your advice about disabling that warning. Here's how. Put this:
in the source code file, above the header that declares strerror (or strncpy
as the case may be).
In the Makefile I define __WIN32__ since I'm not using windows.h, which is
where I believe that thing is defined:
# Uncomment one of these.
OS = __WIN32__
# OS = __LINUX__
TARGET = One_Loan_API_Demo
CFILES = $(wildcard *.cpp)
# Don't forget to run vcvars32.bat!
CC = cl.exe
DEBUG = -Zi
INCLUDES = -I"C:\Java\jdk1.5.0_10\include" \
OFILES = $(patsubst %.cpp, %.obj, $(CFILES))
LDLIBS = -link "C:\Java\jdk1.5.0_10\lib\jvm.lib"
CXXFLAGS = -nologo -EHsc $(INCLUDES) $(DEBUG) -Za -MT -W3 -D$(OS)
CC = g++
DEBUG = -g3
OFILES = $(patsubst %.cpp, %.o, $(CFILES))
CXXFLAGS = $(INCLUDES) -Wall -D$(OS)
$(CC) $(OFILES) $(LDLIBS)
%.obj : %.cpp
$(CC) -c $(CXXFLAGS) $<
rm -rf core $(TARGET).class $(OFILES)
Do you know of a better way to detect Linux/Windows than requiring someone
to comment/uncomment the Makefile?
How the hell did I end up programming on Windows? :-P
vox-tech mailing list