[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [TSVN] Running 64 bit prototype of TSVN 1.2.1 built with VS2005

From: Erik Anderson <erikba_at_teamworkgroup.com>
Date: 2005-08-20 02:33:29 CEST

_strcpy_s ?!? Whatever happened to strncpy?

-----Original Message-----
From: Joseph Galbraith [mailto:galb@vandyke.com]
Sent: Friday, August 19, 2005 5:40 PM
To: dev@tortoisesvn.tigris.org
Subject: Re: [TSVN] Running 64 bit prototype of TSVN 1.2.1 built with
VS2005

Mark Phippard wrote:
> Stefan Fuhrmann <stefanfuhrmann@alice-dsl.de> wrote on 08/19/2005
01:48:01
> PM:
>>> Or, once I have VS2005 myself we could just get rid of the 'unsafe'
>>> functions ;)
>> That would be nice. Since TSVN is bound to Win32 anyway, there is
>> no compelling reason to stick with the std C functions.
>
> Didn't Will Dean (or perhaps Stefan) make a bunch of changes from using
> Win32 file API's to using std C functions because the latter were orders

> of magnitude faster? Perhaps not the same functions being talked about
> here?

I don't think so.

The functions referred to here are MS replacements for C runtime
functions that write to a buffer without taking a size
argument for the output buffer, such as strcpy(), sprintf(), etc.

MS provides replacement functions _strcpy_s which take
an additional parameter, the length of the output buffer.

I believe there are other functions which they've replaced
for various reasons attempting to make programs less like
to have buffer overflows-- I'm not familiar with the
reasoning behind all of them.

Thanks,

Joseph

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org

  • application/x-pkcs7-signature attachment: smime.p7s
Received on Sat Aug 20 02:34:37 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.