You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Xiao-Feng Li <xi...@gmail.com> on 2006/07/06 04:54:13 UTC
Strategy for Harmony to work with Visual Studio 2005?
It has lots of "secure enhancement" API changes. What's the strategy
for those APIs support in Harmony?
Thanks,
xiaofeng
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Ivan Volosyuk <iv...@gmail.com>.
On 7/6/06, Xiao-Feng Li <xi...@gmail.com> wrote:
> Visual Studio 2005 (Whidbey VC8) C runtime library (CRT) has changed
> some compilation rules and APIs for better security or ISO/ANSI
> conformance. Many changes are "breaking", i.e., incompatible. For
> example, it adds safer counterparts for many functions like `strcpy_s'
> for `strcpy', `sprintf_s' for `sprintf', etc. In this example, the
> safer version has an additional parameter asking for the buffer size
> of the destination string to prevent buffer overflow [1] .
Just wondering. What is the function sprintf_s for? ISO C99 has
another function: snprintf() which makes the job. Linux has the second
function. It looks like that this functions should go to port library
from now on.
--
Ivan
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Alexey Petrenko <al...@gmail.com>.
OK. Security is always good.
But I think that it is better to use C99 functions mentioned by Ivan.
I've checked that snprintf function is implemented in glibc and MSVS 2003.
SY, Alexey
2006/7/10, Xiao-Feng Li <xi...@gmail.com>:
> 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 <al...@gmail.com> 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 <xi...@gmail.com>:
> > > 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 <gs...@gmail.com> 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 <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Alexey A. Petrenko
> > Intel Middleware Products Division
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Alexey A. Petrenko
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <al...@gmail.com> 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 <xi...@gmail.com>:
> > 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 <gs...@gmail.com> 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 <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> Alexey A. Petrenko
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Alexey Petrenko <al...@gmail.com>.
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 <xi...@gmail.com>:
> 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 <gs...@gmail.com> 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 <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Alexey A. Petrenko
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <xi...@gmail.com> 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 <gs...@gmail.com> 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 <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <gs...@gmail.com> 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 <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Gregory Shimansky <gs...@gmail.com>.
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 <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Can someone just collect the info that is known and summarize? I'd
prefer a document for the website, but if you'd rather work on the wiki
and we can harvest from there later, that works for me as well...
geir
Sanket Sharma wrote:
> Hmm..
>
> Let me go check previous mails. I think I can be of some help here...
>
> Regards,
> Sanket
>
>
> -----Original Message-----
> From: Thorbjørn Ravn Andersen [mailto:thunderaxiom@gmail.com]
> Sent: Mon 7/10/2006 4:16 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: Strategy for Harmony to work with Visual Studio 2005?
>
> Tim Ellison skrev den 10-07-2006 10:41:
>> Thorbjørn,
>>
>> When you figure this out can you please write up the summary so we can
>> put it on the project webpages?
>>
> Sure, but just copying all the manifests did not work, so right now I
> have - temporarily - given up.
>
> Where are all the Visual Studio gurus? :) An effort here might help
> getting more on the bandwaggon :)
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
RE: Strategy for Harmony to work with Visual Studio 2005?
Posted by Sanket Sharma <sa...@zensar.com>.
Hmm..
Let me go check previous mails. I think I can be of some help here...
Regards,
Sanket
-----Original Message-----
From: Thorbj�rn Ravn Andersen [mailto:thunderaxiom@gmail.com]
Sent: Mon 7/10/2006 4:16 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Strategy for Harmony to work with Visual Studio 2005?
Tim Ellison skrev den 10-07-2006 10:41:
> Thorbj�rn,
>
> When you figure this out can you please write up the summary so we can
> put it on the project webpages?
>
Sure, but just copying all the manifests did not work, so right now I
have - temporarily - given up.
Where are all the Visual Studio gurus? :) An effort here might help
getting more on the bandwaggon :)
--
Thorbj�rn
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
This email may contain confidential or privileged information for the
intended recipient(s) and the views expressed in the same are not
necessarily the views of Zensar Technologies Ltd. If you are not the intended
recipient or have received this e-mail by error, its use is strictly
prohibited, please delete the e-mail and notify the sender. Zensar
Technologies Ltd. does not accept any liability for virus infected mails.
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Tim Ellison skrev den 10-07-2006 10:41:
> Thorbjørn,
>
> When you figure this out can you please write up the summary so we can
> put it on the project webpages?
>
Sure, but just copying all the manifests did not work, so right now I
have - temporarily - given up.
Where are all the Visual Studio gurus? :) An effort here might help
getting more on the bandwaggon :)
--
Thorbjørn
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Tim Ellison <t....@gmail.com>.
Thorbjørn,
When you figure this out can you please write up the summary so we can
put it on the project webpages?
Thanks
Tim
Thorbjørn Ravn Andersen wrote:
> Gregory Shimansky skrev den 07-07-2006 15:01:
>> Do you mean you have an error that there is no manifest file present?
>> This has
>> been answered too in the same threads about using VC 8.0. I just
>> copied all the manifests created in native-src/win.IA32 to
>> deloy/jdk/jre/bin manually to see if it works.
>>
> Well, it just complains that the msvcr8.dll is not present, and I am
> aware that this has been discussed earlier but have not had the time to
> grok the answers yet.
>
> I am currently reading up on the matter, but as I am used to the gcc
> toolchain there is a lot to get right in the mind.
>
> If it is sufficient to copy manifests I will try that, and if needed add
> it to the deployment part in the appropriate build.xml
>
> --
> Thorbjørn
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Gregory Shimansky skrev den 07-07-2006 15:01:
> Do you mean you have an error that there is no manifest file present?
> This has
> been answered too in the same threads about using VC 8.0. I just copied all
> the manifests created in native-src/win.IA32 to deloy/jdk/jre/bin manually to
> see if it works.
>
Well, it just complains that the msvcr8.dll is not present, and I am
aware that this has been discussed earlier but have not had the time to
grok the answers yet.
I am currently reading up on the matter, but as I am used to the gcc
toolchain there is a lot to get right in the mind.
If it is sufficient to copy manifests I will try that, and if needed add
it to the deployment part in the appropriate build.xml
--
Thorbjørn
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Gregory Shimansky <gs...@gmail.com>.
On Friday 07 July 2006 16:00 Thorbjørn Ravn Andersen wrote:
> Matt Benson skrev den 06-07-2006 19:25:
> > Some particulars may be slightly different from one
> > machine to the next, but in general this works; we
> > need to get this info in the wiki IMHO
>
> Agreed. I have starting to write such an entry, but is currently
> stopped by the VSMCR8.DLL problem of VS2005 Express so the compiled
> "java.exe" will not start.
>
> When I have a fully working compilation path of classlib with the IBM VM
> I'll get it finished.
Do you mean you have an error that there is no manifest file present? This has
been answered too in the same threads about using VC 8.0. I just copied all
the manifests created in native-src/win.IA32 to deloy/jdk/jre/bin manually to
see if it works.
Rana also found 2 (using mt tool and using resource compiler) recipes how to
embed this stuff into executables and DLLs but I didn't try them.
To make this work out of the box the build of classlib should be improved,
probably it is easier to do from ant after native sources compilation is done
by make.
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Matt Benson skrev den 06-07-2006 19:25:
> Some particulars may be slightly different from one
> machine to the next, but in general this works; we
> need to get this info in the wiki IMHO
Agreed. I have starting to write such an entry, but is currently
stopped by the VSMCR8.DLL problem of VS2005 Express so the compiled
"java.exe" will not start.
When I have a fully working compilation path of classlib with the IBM VM
I'll get it finished.
--
THorbjørn
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Gregory Shimansky <gs...@gmail.com>.
On Thursday 06 July 2006 21:25 Matt Benson wrote:
> This particular mail (by Gregory) contains
>
> (a) a link to another mail (of his) describing how to
> get the MSFT tools to work, and
> (b) a link to a JIRA issue containing the necessary
> patches to use NASM for assembly:
If you don't want to make changes to too many classlib files and just use MS
free toolchain there is a link from Rana's email [1] to free MASM distributed
by Miscrosoft.
It was not available by the time I made my NASM port. It may be used later
when we support full stack of free as in speech toolchains on win32.
[1] http://article.gmane.org/gmane.comp.java.harmony.devel/9291/
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Matt Benson <gu...@yahoo.com>.
This particular mail (by Gregory) contains
(a) a link to another mail (of his) describing how to
get the MSFT tools to work, and
(b) a link to a JIRA issue containing the necessary
patches to use NASM for assembly:
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/%3c200606270155.23051.gshimansky@gmail.com%3e
Some particulars may be slightly different from one
machine to the next, but in general this works; we
need to get this info in the wiki IMHO.
-Matt
--- Geir Magnusson Jr <ge...@pobox.com> wrote:
> Don't take my word here - we need opines from
> others, especially the
> people that work a lot on windows...
>
> geir
>
>
> 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. :-)
> >
> > Thanks,
> > xiaofeng
> >
> > On 7/6/06, Geir Magnusson Jr <ge...@pobox.com>
> 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.
> >>
> >> geir
> >>
> >> >
> >> > Thanks,
> >> > xiaofeng
> >> >
> >> > [1]
>
http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/
> >> > [2]
>
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf
> >> >
> >> > On 7/6/06, Geir Magnusson Jr <ge...@pobox.com>
> wrote:
> >> >>
> >> >>
> >> >> Xiao-Feng Li wrote:
> >> >> > It has lots of "secure enhancement" API
> changes. What's the strategy
> >> >> > for those APIs support in Harmony?
> >> >>
> >> >> Huh? What APIs in Visual Studio?
> >> >>
> >> >> geir
> >> >>
> >> >>
> >> >>
>
---------------------------------------------------------------------
> >> >> Terms of use :
> http://incubator.apache.org/harmony/mailing.html
> >> >> To unsubscribe, e-mail:
> harmony-dev-unsubscribe@incubator.apache.org
> >> >> For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> >> >>
> >> >>
> >> >
> >> >
>
---------------------------------------------------------------------
> >> > Terms of use :
> http://incubator.apache.org/harmony/mailing.html
> >> > To unsubscribe, e-mail:
> harmony-dev-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> >> >
> >> >
> >> >
> >>
> >>
>
---------------------------------------------------------------------
> >> Terms of use :
> http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail:
> harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> >
>
---------------------------------------------------------------------
> > Terms of use :
> http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail:
> harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> >
> >
> >
>
>
---------------------------------------------------------------------
> Terms of use :
> http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail:
> harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Don't take my word here - we need opines from others, especially the
people that work a lot on windows...
geir
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. :-)
>
> Thanks,
> xiaofeng
>
> On 7/6/06, Geir Magnusson Jr <ge...@pobox.com> 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.
>>
>> geir
>>
>> >
>> > Thanks,
>> > xiaofeng
>> >
>> > [1] http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/
>> > [2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf
>> >
>> > On 7/6/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> >>
>> >>
>> >> Xiao-Feng Li wrote:
>> >> > It has lots of "secure enhancement" API changes. What's the strategy
>> >> > for those APIs support in Harmony?
>> >>
>> >> Huh? What APIs in Visual Studio?
>> >>
>> >> geir
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Xiao-Feng Li <xi...@gmail.com>.
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. :-)
Thanks,
xiaofeng
On 7/6/06, Geir Magnusson Jr <ge...@pobox.com> 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.
>
> geir
>
> >
> > Thanks,
> > xiaofeng
> >
> > [1] http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/
> > [2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf
> >
> > On 7/6/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >>
> >>
> >> Xiao-Feng Li wrote:
> >> > It has lots of "secure enhancement" API changes. What's the strategy
> >> > for those APIs support in Harmony?
> >>
> >> Huh? What APIs in Visual Studio?
> >>
> >> geir
> >>
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 7/6/06, Geir Magnusson Jr <ge...@pobox.com> 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.
Honestly that seems like the best approach to me. Otherwise, you'll
get tons of warnings from code that's intended to be portable across C
compilers, which can't possibly be expected to switch to the
microsoft-only APIs. Switching to the microsoft-only APIs inside of
specialized parts of the tree that are only used on windows is one
thing, but even then I'd advise against it since it ties you too
closely to their toolchain.
-garrett
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Xiao-Feng Li wrote:
> Visual Studio 2005 (Whidbey VC8) C runtime library (CRT) has changed
> some compilation rules and APIs for better security or ISO/ANSI
> conformance. Many changes are "breaking", i.e., incompatible. For
> example, it adds safer counterparts for many functions like `strcpy_s'
> for `strcpy', `sprintf_s' for `sprintf', etc. In this example, the
> safer version has an additional parameter asking for the buffer size
> of the destination string to prevent buffer overflow [1] .
>
> I personally like the changes, since they make code safer. But Harmony
> classlib and DRLVM have tons of warnings or failures when compiled
> with VC8. Some are from the code themselves, some are from supporting
> codes. The suggested solutions by Microsoft for the security changes
> are either to temporarily define _CRT_SECURE_NO_DEPRECATE for
> compilation or to use the changed APIs since Microsoft said they
> submit the work to standard committee. (Btw, the security changes are
> the major part, but there are still warnings/failures caused by other
> changes.)
>
> I don't know how other people solve(d) the problem in their Harmony
> compilation, but to use `#ifdef' for every call site of the changed
> function looks ugly. Probably we could group all those APIs into a
> port layer.
>
> Since Microsoft has submitted their work to standard committee, looks
> like those safe APIs will soon become standardized [2]. We may finally
> have to support them (why not?). Microsoft has tried to produce some
> tool that can automatically translate the code to work with the safe
> CRT, but this approach doesn't work in many situations. Another
> workaround proposed by Microsoft is to overload the original function
> with a wrapper function that invokes the safer version, but it doesn't
> work for C code.
>
> Since this issue is not specific to Harmony, it's a little bit
> surprising that I failed to google much useful information in open
> source commuinty. Or I missed something obvious?
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.
geir
>
> Thanks,
> xiaofeng
>
> [1] http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/
> [2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf
>
> On 7/6/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>>
>> Xiao-Feng Li wrote:
>> > It has lots of "secure enhancement" API changes. What's the strategy
>> > for those APIs support in Harmony?
>>
>> Huh? What APIs in Visual Studio?
>>
>> geir
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Xiao-Feng Li <xi...@gmail.com>.
Visual Studio 2005 (Whidbey VC8) C runtime library (CRT) has changed
some compilation rules and APIs for better security or ISO/ANSI
conformance. Many changes are "breaking", i.e., incompatible. For
example, it adds safer counterparts for many functions like `strcpy_s'
for `strcpy', `sprintf_s' for `sprintf', etc. In this example, the
safer version has an additional parameter asking for the buffer size
of the destination string to prevent buffer overflow [1] .
I personally like the changes, since they make code safer. But Harmony
classlib and DRLVM have tons of warnings or failures when compiled
with VC8. Some are from the code themselves, some are from supporting
codes. The suggested solutions by Microsoft for the security changes
are either to temporarily define _CRT_SECURE_NO_DEPRECATE for
compilation or to use the changed APIs since Microsoft said they
submit the work to standard committee. (Btw, the security changes are
the major part, but there are still warnings/failures caused by other
changes.)
I don't know how other people solve(d) the problem in their Harmony
compilation, but to use `#ifdef' for every call site of the changed
function looks ugly. Probably we could group all those APIs into a
port layer.
Since Microsoft has submitted their work to standard committee, looks
like those safe APIs will soon become standardized [2]. We may finally
have to support them (why not?). Microsoft has tried to produce some
tool that can automatically translate the code to work with the safe
CRT, but this approach doesn't work in many situations. Another
workaround proposed by Microsoft is to overload the original function
with a wrapper function that invokes the safer version, but it doesn't
work for C code.
Since this issue is not specific to Harmony, it's a little bit
surprising that I failed to google much useful information in open
source commuinty. Or I missed something obvious?
Thanks,
xiaofeng
[1] http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/
[2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf
On 7/6/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Xiao-Feng Li wrote:
> > It has lots of "secure enhancement" API changes. What's the strategy
> > for those APIs support in Harmony?
>
> Huh? What APIs in Visual Studio?
>
> geir
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: Strategy for Harmony to work with Visual Studio 2005?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Xiao-Feng Li wrote:
> It has lots of "secure enhancement" API changes. What's the strategy
> for those APIs support in Harmony?
Huh? What APIs in Visual Studio?
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org