Web lists-archives.com

Re: [Mingw-users] Secure crt functions not in header files

Hash: SHA1

On 25/05/17 23:40, John Brown wrote:
> On Thursday, May 25, 2017 1:45 PM, Keith Marshall wrote:
>> On 25/05/17 16:44, John Brown wrote:
>> I see that functions such as printf_s described at 
>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt
>> are present in /mingw/lib/libmsvcr80.a but I cannot find them in any
>> MinGW header file (at least not in /mingw/include/*.h). Is there a 
>> particular reason for that?
>> Perhaps because no one has been sufficiently taken in by
>> Microsoft's lies, (in what way do such functions provide added
>> security?  What user authentication mechanisms do they provide?),
>> to be bothered to submit patches to add them.
> The section entitled "Additional Security Features" at the link that I
> provided explains what is more secure about these functions. It seems
> to be mainly about avoiding buffer overruns as opposed to user
> authentication.

And Google will turn up any number of references, which explain why 
they are inappropriately described as security enhancing, and indeed 
if anything may actually be prejudicial to security; Microsoft have 
chosen to promote them thus, to engender and exploit FUD.

>> Realistically, the only security related aspect of the majority of
>> such functions is that they secure an increased level of Microsoft
>> lock-in; I am not enthusiastic about encouraging their use.
> If you feel so strongly about it, then surely you should exclude these
> functions from the import libraries?  I only asked because they were
> in the libraries but not in the header files.

That's not an unreasonable suggestion.  However, right now the import 
libraries reflect what our pexports tool says is provided by the union 
of all currently support MSVCRT.DLL versions, as documented here:

Obviously, that union will necessarily be more comprehensive than the 
list of exports from any one version of MSVCRT.DLL, particularly in the 
case of the versions from older versions of Windows itself.  To support 
linking with any MSVCRT.DLL version, the import library must cover all 
eventualities -- there is no way to make a single implib selective for 
multiple similarly named DLLs; the only selectivity possible is that 
which is achievable by selective exposure of prototypes in headers.

Notwithstanding the above, and given that we want to keep msvcrt-xref 
fully comprehensive, while still generating libmsvcrt.a from the same 
symbol reference source, there are some symbols explicitly filtered 
out of the import libraries; we could extend the list of such symbols, 
if the user population deems it desirable.  I will be guided by the 
wishes of any significant number of users here; if you think we should 
exclude Microsoft's *_s() nonsense, please say so; if you think we 
should support it, please submit patches via the feature request 

- -- 

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
Version: GnuPG v2.0.20 (GNU/Linux)


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
MinGW-users mailing list

This list observes the Etiquette found at
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

You may change your MinGW Account Options or unsubscribe at:
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe