Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <46700C09.5020102@roguewave.com>
Date: Wed, 13 Jun 2007 09:23:53 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: MSVC8 CRT "Secure Template Overloads" feature and stdcxx
References: <466ED999.4020306@epam.com> <466F6631.2060009@roguewave.com>
 <7BDB2168BEAEF14C98F1901FD2DE6438948E27@epmsa009.minsk.epam.com>
In-Reply-To: <7BDB2168BEAEF14C98F1901FD2DE6438948E27@epmsa009.minsk.epam.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Wednesday, June 13, 2007 6:36 AM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: MSVC8 CRT "Secure Template Overloads" feature and stdcxx
>>
>> Farid Zaripov wrote:
>>>  The MSVC8 CRT have the following feature: all  functions, working 
>>> with sting buffers (i.e. strcpy, strcat, sprintf, ...) have the 
>>> security-enhanced versions with suffix "_s"
>>> (i.e. strcpy_s, strcat_s, sprintf_s, ...). And if #defined macro
>>> _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES=1
>>> then will be defined template overloads of the such functions, i.e.:
>> So the templates are disabled by default, correct? And to 
>> enable them users would have to define the macro, both during 
>> configuration as well as while building and using the library.
> 
>   Correct.
> 
>>>  The proposed patch is attached, but I not sure about passing 0 as 
>>> va_list argument while testing vsprintf() and vswprintf().
>> I don't think that's guaranteed to be well-formed. va_list 
>> could be anything, including a struct with no conversion from 
>> int. But if you can get this issue resolved and if it 
>> compiles with all your compilers (i.e., all versions of MSVC 
>> and Intel C++ on Windows, as well as gcc on Linux and 
>> Cygwin), I think it should be safe to commit the change.
> 
>   Since va_list can be anything, we need to pass va_list type in
> function call.
> We can add function template <class T> get_t () { T t; return t; } to
> the libc_decl.sh
> and use the followinf declaration: vsprintf((char*)0,0,get_t<va_list>())
> in headers.inc.

Wouldn't vsprintf((char*)0,0,va_list()) work? My concern here
is with the va_list name: Is it required to be declared in the
same header as the functions that use it?

Martin

> 
>   The proposed patch of the libc_decl.sh:
> 
> 
> Index: libc_decl.sh
> ===================================================================
> --- libc_decl.sh	(revision 546575)
> +++ libc_decl.sh	(working copy)
> @@ -227,6 +227,15 @@
>  
>  #  endif   // no_namespace
>  
> +#include <stdarg.h>
> +
> +template <class T>
> +T get_t ()
> +{
> +    T t;
> +    return t;
> +}
> +
>  int main (int argc, char**)
>  {
>      // with gcc, prevent intrinsics from causing false positives
> 
> Farid.