They are also non-standard and make your code not compile on Linux.

The _s functions are 50% security and 50% vendor lock-in from Microsoft.

> El 16 feb 2016, a las 10:25, McLeod, John <[email protected]> escribió:
> 
> The _s functions do a better job of avoiding buffer overruns.  IIRC, they 
> force the programmer to tell the function the size of the target buffer.  
> 
> -----Original Message-----
> From: boinc_dev [mailto:[email protected]] On Behalf Of 
> Richard Haselgrove
> Sent: Tuesday, February 16, 2016 8:18 AM
> To: Richard Haselgrove <[email protected]>; Rom Walton 
> <[email protected]>; [email protected]
> Subject: Re: [boinc_dev] client in master is broken
> 
> And the resulting client failed with "A buffer overrun has occurred in 
> boinc.exe which has corrupted the program's internal state. Press Break to 
> debug the program or Continue to terminate the program."
> 
> Pressing Break dropped me into the source at 
> 
> 
>>    boinc.exe!__raise_securityfailure(_EXCEPTION_POINTERS * 
>> ExceptionPointers) Line 85    C
> boinc.exe!__report_gsfailure(unsigned __int64 StackCookie) Line 241    C 
> boinc.exe!__GSHandlerCheck(_EXCEPTION_RECORD * ExceptionRecord, void * 
> EstablisherFrame, _CONTEXT * ContextRecord, _DISPATCHER_CONTEXT * 
> DispatcherContext) Line 91    C 
> ntdll.dll!00000000775b8bbd()    Unknown 
> ntdll.dll!00000000775a875f()    Unknown 
> ntdll.dll!00000000775dd348()    Unknown 
> msvcr120.dll!000007fef313c3f9()    Unknown 
> ffffffffffffffff()    Unknown 
> 0000000000000080()    Unknown 
> boinc.exe!strlcat(char * dst, const char * src, unsigned __int64 size) Line 
> 78    C++ 
> boinc.exe!get_processor_features(char * vendor, char * features, int 
> features_size) Line 1198    C++ 
> boinc.exe!get_processor_info(char * p_vendor, int p_vendor_size, char * 
> p_model, int p_model_size, char * p_features, int p_features_size, double & 
> p_cache, int & p_ncpus) Line 1305    C++ 
> 
> 
> On Tuesday, 16 February 2016, 12:59, Richard Haselgrove 
> <[email protected]> wrote:
> 
> 
> 
> Rom,
> 
> The fix you made last night solved the build problem in VS2013 - thanks.
> 
> But your overnight work on the 'low hanging fruit' has triggered a huge 
> number of VS2013 warnings - 469 when building boinccmd, which includes the 
> client build as part of the solution.
> 
> All seem to be C4996 - sample below. In each case, the 'consider using' 
> suggestion seems to be to replace the function (several different functions 
> are named) with function_s
> 
> e.g.
> 
> Warning 469 warning C4996: 'ctime': This function or variable may be unsafe. 
> Consider using ctime_s instead. To disable deprecation, use 
> _CRT_SECURE_NO_WARNINGS. See online help for details.
> 
> D:\Sources_build\boinc_head\lib\gui_rpc_client_print.cpp 238 1 boinccmd
> 
> 
> On Monday, 15 February 2016, 20:29, Rom Walton <[email protected]> wrote:
> 
> 
> 
> Should be fixed now.
> 
> ----- Rom
> 
> -----Original Message-----
> From: boinc_dev [mailto:[email protected]] On Behalf Of 
> Richard Haselgrove
> Sent: Monday, February 15, 2016 3:09 PM
> To: [email protected]
> Subject: Re: [boinc_dev] client in master is broken
> 
> I also found that the Windows VS2013 solution failed to build the client from 
> tags 7.6.24, 7.6.25, and head.
> Managed to fix it by adding references to '..\lib\project_init.cpp' and 
> '..\lib\project_init.h' to the <ItemGroup> lists in both 
> boinc_cli_vs2013.vcxproj and libboinc_staticcrt_vs2013.vcxproj
> 
> With that adjustment, head (debug) seems to be running. 
> 
> 
> 
> On Tuesday, 9 February 2016, 13:31, Oliver Bock <[email protected]> 
> wrote:
> 
> 
>> On 09/02/16 14:10 , Rom Walton wrote:
>> Should be fixed now.
> 
> Please, please, please. It's been about three years since we migrated to git. 
> BOINC moved to GitHub just recently and tries to adopt a community governance 
> model. It should really be possible by now that devs start using feature 
> branches for development and save everyone else from periodic headaches. It's 
> not hard by any means and it comes with huge incentives for everyone involved.
> 
> So please, use feature branches for development; merge to master when you're 
> done with testing; don't break master; be happy; make everyone else happy...
> 
> THANKS!
> 
> 
> _______________________________________________
> boinc_dev mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
> 
> 
> 
> _______________________________________________
> boinc_dev mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
> 
> _______________________________________________
> boinc_dev mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
> _______________________________________________
> boinc_dev mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
> _______________________________________________
> boinc_dev mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
> _______________________________________________
> boinc_dev mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to