The checks in my code example below can be asserts or defined for
debug mode only, if people worry about the performance AND are almost
sure about the safety. But I don't think they are only for debugging
purpose. Optimizations can be done to reduce the overhead.
Thanks,
xiaofeng
On 7/7/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
I would suggest another approach.
Since the safe CRT APIs are mostly similar to the original counterpart
but enforcing safety checks and validations, we can take them as
coding conventions, so as to achieve both the safety and portability.
For example, with strcpy, we do this way:
step 1. write a safe version strcpy_s on platforms that have no safe
CRT support, see below.
step 2. replace all strcpy(dst, src) invocations with strcpy_s(dst, count, src);
This version of strcpy_s is only for illustration purpose and follow
the standard safety checkings.
#define MAX_STR_LEN (1<<30)
#ifndef SAFE_CRT
int strcpy_s(dst, count, src)
{
if( dst != null && count > 0 && count <= MAX_STR_LEN )
dst[0] = '\0';
if( dst == NULL || src == NULL ) return -1;
if( count == 0 || count > MAX_STR_LEN ) return -1;
if( count <= strlen(src) ) return -1; //strlen should use safer version
if( mem_overlap (dst, src) ) return -1;
strcpy(dst, src);
return 0;
}
#endif
Thanks,
xiaofeng
On 7/7/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> On Thursday 06 July 2006 14:35 Xiao-Feng Li wrote:
> > Ok, then I will get back to VC7 at the moment. :-) Let's wait till
> > its acceptance by the community.
> >
> > Actually I don't see them as new APIs; instead, I view them as
> > enforced good coding conventions that help to achieve better security,
> > e.g., always check the buffer size in debug mode. (Personally I like
> > the changes immediately when I met them. My only question was why we
> > didn't do that earlier. :-)
>
> If they were just drop in replacements of the old functions this could be done
> quickly. But they are not compatible for the most part and so may complicate
> the code significantly to support both old (e.g. VC7 and older, cyginw/mingw
> targets) and new version.
>
> You can use includes from Platform SDK which has headers compatible with old
> API [1] unless MS has changed new versions of Platform SDK to have this
> secure stuff and no alternative since I wrote that email.
>
> > On 7/6/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> > > I think the key reason is that this is non-standard stuff from
> > > microsoft's for-fee toolchain, and people in OSS try to avoid having a
> > > dependency on that.
> > >
> > > I wouldn't mind supporting this at some point a) once it becomes a
> > > standard and b) has broad acceptance, but I'm guessing that's going to
> > > take years.
> > >
> > > People who have used the free version of MSFT tools seem to just set the
> > > flag as you note.
>
> There are two flags. I've found the second in [2]. But I didn't try to use the
> because I used Platform SDK includes workaround. Maybe defining them is still
> not enough.
>
> [1]
>
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/<208da7a50606011434i405b7d5ao4be8a9fefc52e183%40mail.gmail.com>
>
> [2]
>
http://www.wxwidgets.org/wiki/index.php/MSVC_.NET_Setup_Guide#Version_Specific_Comments_.26_Instructions
>
> --
> Gregory Shimansky, Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
