Do not rely on secure API functions when using MinGW-w64

Do not rely on secure API functions when using MinGW-w64

Windows XP does not provide secure API functions in msvcrt.dll but
newer versions of Windows do. Avoid using secure API functions for
compatibility with msvcrt.dll on Windows XP.

Contributed by net147@gmail.com

BUGS=
TEST=

Committed: https://code.google.com/p/v8/source/detail?r=13603

[Yang, 2013-02-06 10:34:24]

On 2013/02/04 13:04:49, Net147 wrote:

I'm confused. Is v8_localtime_s et al. something that MinGW provides?

[Net147, 2013-02-06 10:39:52]

On 2013/02/06 10:34:24, Yang wrote:
> On 2013/02/04 13:04:49, Net147 wrote:
> 
> I'm confused. Is v8_localtime_s et al. something that MinGW provides?

Nope. It's so the functions don't conflict if MinGW defines localtime_s,
fopen_s, etc. in its headers.

[Yang, 2013-02-06 10:47:50]

On 2013/02/06 10:39:52, Net147 wrote:
> On 2013/02/06 10:34:24, Yang wrote:
> > On 2013/02/04 13:04:49, Net147 wrote:
> > 
> > I'm confused. Is v8_localtime_s et al. something that MinGW provides?
> 
> Nope. It's so the functions don't conflict if MinGW defines localtime_s,
> fopen_s, etc. in its headers.

So if I understood correctly, the current behavior is that when
MINGW_HAS_SECURE_API is not defined, we define our own set of *_s functions.
Otherwise, we rely on the ones provided by msvcrt.dll.

The CL changes so that we always use our own set of *_s functions. The reason
being that while newer msvcrt.dll provides those *_s functions, the one in
Windows XP does not.

Is that correct?

[Net147, 2013-02-06 10:49:07]

On 2013/02/06 10:47:50, Yang wrote:
> On 2013/02/06 10:39:52, Net147 wrote:
> > On 2013/02/06 10:34:24, Yang wrote:
> > > On 2013/02/04 13:04:49, Net147 wrote:
> > > 
> > > I'm confused. Is v8_localtime_s et al. something that MinGW provides?
> > 
> > Nope. It's so the functions don't conflict if MinGW defines localtime_s,
> > fopen_s, etc. in its headers.
> 
> So if I understood correctly, the current behavior is that when
> MINGW_HAS_SECURE_API is not defined, we define our own set of *_s functions.
> Otherwise, we rely on the ones provided by msvcrt.dll.
> 
> The CL changes so that we always use our own set of *_s functions. The reason
> being that while newer msvcrt.dll provides those *_s functions, the one in
> Windows XP does not.
> 
> Is that correct?

Yes.

[Yang, 2013-02-06 10:58:36]

On 2013/02/06 10:49:07, Net147 wrote:
> On 2013/02/06 10:47:50, Yang wrote:
> > On 2013/02/06 10:39:52, Net147 wrote:
> > > On 2013/02/06 10:34:24, Yang wrote:
> > > > On 2013/02/04 13:04:49, Net147 wrote:
> > > > 
> > > > I'm confused. Is v8_localtime_s et al. something that MinGW provides?
> > > 
> > > Nope. It's so the functions don't conflict if MinGW defines localtime_s,
> > > fopen_s, etc. in its headers.
> > 
> > So if I understood correctly, the current behavior is that when
> > MINGW_HAS_SECURE_API is not defined, we define our own set of *_s functions.
> > Otherwise, we rely on the ones provided by msvcrt.dll.
> > 
> > The CL changes so that we always use our own set of *_s functions. The
reason
> > being that while newer msvcrt.dll provides those *_s functions, the one in
> > Windows XP does not.
> > 
> > Is that correct?
> 
> Yes.

LGTM. Landing.

[Yang, 2013-02-06 10:59:56]

Committed manually as r13603 (presubmit successful).

[Murakamy2013, 2013-07-05 08:04:17]

On 2013/02/06 10:59:56, Yang wrote:
> Committed manually as r13603 (presubmit successful).

Vcvnm