Re: [vox-tech] strerror deprecated?
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? Thanks, Peter One solution I have not heard mentioned today: don't use strerror at all. The few times I have used it in twenty years of programming, it has been for programs I did not plan on distributing anyway. Normally, I try to handle all defined errors in a manner appropriate to the context. For example, in an embedded system errors may be reported through LEDs, and ENOMEM is pretty useless information to the typical user of such a tool. In reality, errno is pretty useless information to users in most contexts... it is really debugging information, and incomplete for that purpose as well. -- --- Jeff NewmillerThe . . Go Live... DCN:<[EMAIL PROTECTED]>Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...1k --- ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] strerror deprecated?
On Tue, Dec 26, 2006 at 03:55:34PM -0800, Richard Harke wrote:
> Just pragmatically, I'm afraid. I was going to suggest a short test program
> that ran through the error no's but that just covers english, and if you're
> really determined, a small number of other languages. I expect that
> most languages will use short standard phrases but I have seen a few
> pathological translations (not from the computer field) that were wildly
> different in length. Maybe Bill Kendrick could comment as his Tuxpaint
> is supported for a large number of languages.
Well, certainly supporting up to 4x the bytes would be necessary in
some cases (I allow strings to be encoded UTF-8, so each output character
may be between 1 and 4 bytes long).
Of course, I'm simply wrapping 'gettext()' calls around the strings,
and using the results in my own functions, e.g.:
draw_tux_text(TUX_WAIT, gettext("Please wait..."), 1);
I don't need to worry about creating or destroying string buffers to hold
these... as gettext()'s man page says:
"The resulting string is statically allocated and must not be
modified or freed."
I DO need to worry about string buffers when doing any kind of manipulation,
just as I would with any other string... translated or not.
(e.g., if I want to strcat(), I need to malloc() the appropriate length to
hold all of the strings I'm concatenating)
--
-bill!
[EMAIL PROTECTED]
http://www.newbreedsoftware.com/
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] strerror deprecated?
On Tue, Dec 26, 2006 at 02:07:26PM -0800, Mark K. Kim wrote: > I don't think there is a way to "do it by the books" in this case. The > closest way I can think of is to use autoconf/automake. Another way > would be to create one Makefile per target platform. I just add targets to my Makefile for the exotic platforms: e.g.: make win32 make beos Of course, this fudges my ability to mix build-tweaking targets, but they're rarely used. (e.g., "make nosound", which disables sound support and, hence, dependency on SDL_mixer, in my games.) -- -bill! [EMAIL PROTECTED] http://www.newbreedsoftware.com/ ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] strerror deprecated?
On Tue, 2006-12-26 at 16:46 -0500, Peter Jay Salzman wrote: > For the record, strerror_r() isn't implemented in VC++, but it does appear > to be a drop in replacement for strerror_s(). > > BTW, when you say that all the error messages are a line long, are you > speaking pragmatically or from a standards view? I'm really trying to write > this "by the books." He's speaking pragmatically, I believe. The standards place no restraints on the size of an error string; but as a quality-of-implementation issue it'd be fairly broken to go beyond roughly that limit. I'd feel fairly safe, for instance, in using a 256-char buffer to store the result in: if it gets truncated to 255 chars, well so be it. :) -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] strerror deprecated?
On Tue December 26 2006 13:46, Peter Jay Salzman wrote: > > > Richard > > Thanks, Richard! > > For the record, strerror_r() isn't implemented in VC++, but it does appear > to be a drop in replacement for strerror_s(). > > BTW, when you say that all the error messages are a line long, are you > speaking pragmatically or from a standards view? I'm really trying to > write this "by the books." Just pragmatically, I'm afraid. I was going to suggest a short test program that ran through the error no's but that just covers english, and if you're really determined, a small number of other languages. I expect that most languages will use short standard phrases but I have seen a few pathological translations (not from the computer field) that were wildly different in length. Maybe Bill Kendrick could comment as his Tuxpaint is supported for a large number of languages. Richard ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] strerror deprecated?
On Tue, Dec 26, 2006 at 02:51:38PM -0500, Peter Jay Salzman wrote: > 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__ ... > Do you know of a better way to detect Linux/Windows than requiring someone > to comment/uncomment the Makefile? I don't think there is a way to "do it by the books" in this case. The closest way I can think of is to use autoconf/automake. Another way would be to create one Makefile per target platform. Once you get into the C-layer, you can use the defined variables predefined by the compiler (#ifdef(linux), #ifdef(_WIN32), etc.) But I don't think those exist at Makefile level. -Mark ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] strerror deprecated?
On Tue 26 Dec 06, 11:49 AM, Richard Harke <[EMAIL PROTECTED]> said: > > 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 Thanks, Richard! For the record, strerror_r() isn't implemented in VC++, but it does appear to be a drop in replacement for strerror_s(). BTW, when you say that all the error messages are a line long, are you speaking pragmatically or from a standards view? I'm really trying to write this "by the books." Pete ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] strerror deprecated?
On Tue 26 Dec 06, 10:37 AM, Micah Cowan <[EMAIL PROTECTED]> 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 > 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. Thanks, Micah. I took your advice about disabling that warning. Here's how. Put this: #ifdef __WIN32__ #define _CRT_SECURE_NO_DEPRECATE #endif 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) ifeq ($(OS),__WIN32__) # Don't forget to run vcvars32.bat! CC = cl.exe DEBUG= -Zi INCLUDES = -I"C:\Java\jdk1.5.0_10\include" \ -I"C:\Java\jdk1.5.0_10\include\win32" 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) else CC = g++ DEBUG= -g3 INCLUDES = OFILES = $(patsubst %.cpp, %.o, $(CFILES)) LDLIBS = CXXFLAGS = $(INCLUDES) -Wall -D$(OS) endif all: $(OFILES) $(CC) $(OFILES) $(LDLIBS) %.obj : %.cpp $(CC) -c $(CXXFLAGS) $< .PHONY: clean clean: 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 Thanks! Pete ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] strerror deprecated?
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 ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
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 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 vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] strerror deprecated?
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? Thanks, Peter -- How VBA rounds a number depends on the number's internal representation. You cannot always predict how it will round when the rounding digit is 5. If you want a rounding function that rounds according to predictable rules, you should write your own. -- MSDN, on Microsoft VBA's "stochastic" rounding function Peter Jay Salzman, email: [EMAIL PROTECTED] web: http://www.dirac.org/p PGP Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
