On Sun, 12 Feb 2023, Christian Franke wrote:
During testing of _FORTIFY_SOURCE on current MSYS2, I found that __gets_chk()
is no longer provided. The *_chk() Functions from libssp.a were apparently
moved to libmingwex.a, but without __gets_chk().
Is this possibly because the FILE types of UCRT and MSVCRT differ?
If this change was intentional, I would suggest to apply this patch.
It's not entirely intentional.
When I added the ssp routines to libmingwex, I first set out to implement
the functions that we actually do end up calling in our headers - see
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/20220914073356.2126882-1-martin%40martin.st/#msg37707134.
This didn't include __gets_chk - I presume that was just an oversight on
my part, I'm sorry about that.
In a later patch, I added sample implementations of the functions that
aren't used by our headers, where I did include a copy of a __gets_chk
function:
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/20220914073356.2126882-3-martin%40martin.st/#msg37707133
In the end, we decided that we shouldn't apply that at the time as they
would essentially be unused - but this was based on my mistake that
__gets_chk wasn't used, while it actually is. (The sprintf functions are
indeed problematic though, since it's not clear whether they should defer
to the raw CRT printfs or the mingw reimplementations. But that shouldn't
be an issue for __gets_chk; that uses fgets() internally, and fgets() is a
symbol provided as is by all CRTs.)
I can split out the __gets_chk function implementation from that patch and
let you take it for a spin.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
