libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pings


From: Charles Wilson
Subject: Re: Pings
Date: Thu, 29 Jan 2009 23:30:17 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]