My idea is NOT to write wrappers for Microsoft extentions. First, they
are to enhance our own C code safety with more checkings; second, they
are not MS extensions. The only thing is, they are enlighted by and
have similar APIs as MS's safe CRT.

Thanks,
xiaofeng

On 7/9/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
I think that creating such wrappers and implementing non standard MS
extensions for another platforms is not a good idea. What will we do
if this extension will not be accepted? Rewrite everything again?

I agree that such extension is probably good. But we should wait until
community will accept them and widely used compilers will implement
them.

SY, Alexey

2006/7/7, Xiao-Feng Li <[EMAIL PROTECTED]>:
> 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]
>
>


--
Alexey A. Petrenko
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]

Reply via email to