Re: [Mingw-users] Secure crt functions not in header files
-----BEGIN PGP SIGNED MESSAGE-----
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
>> 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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
-----END PGP SIGNATURE-----
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: