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 <[EMAIL PROTECTED]> 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: [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] > > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
