Akim Demaille wrote: > Le 29 janv. 09 à 19:22, Ralf Wildenhues a écrit : >> For this one I'd prefer if Charles and/or Peter took care of it, they >> have a bunch of changes in this area and some discussion going on. >> Actually, I'd prefer to just be able to say "go!" once y'all have agreed >> on a common set of changes. :-) > > Maybe there are other means to address these warnings. At some > other place of our project, it seems that #defining > _CRT_SECURE_NO_DEPRECATE, _CRT_NONSTDC_NO_DEPRECATE, > _AFX_SECURE_NO_WARNINGS, and _ATL_SECURE_NO_WARNINGS might > suffice.
Well, we should do our best to make the libtool cwrapper as "invisible" as possible. So, if a client's code is _CRT_SECURE_NO_DEPRECATE clean, such that they don't need to define that macro, we shouldn't require them to change their entire build settings CFLAGS just to make our little wrapper compile silently. However, there is no WAY we're going to use MS's "improved" functions like StringCchLength() or StringCbCat(). So, *we* ought to #define those "shaddup, MS, I'm not using your 'safe' but proprietary replacements for standard libc functions" macros. However, the only ones that matter for the cwrapper is _CRT_SECURE_NO_DEPRECATE (and perhaps _CRT_NONSTDC_NO_DEPRECATE [*]). [*] except that we are already addressing that via the typical port-to-MSVC method of '#define foo _foo' for all posix functions we use. > Whatever the choice, this (msvc) is a real nuisance. You can say that again. And again. And several more times. -- Chuck
