On Mon, 11 Sep 2017, Martin Storsjö wrote:

On Mon, 11 Sep 2017, Jacek Caban wrote:

Hi Martin,

On 11.09.2017 14:48, Martin Storsjö wrote:
+_ctime32
+; _ctime32_s replaced by emu
+_ctime64
+; _ctime64_s replaced by emu


This doesn't look right, we should use .def file to expose those. I
noticed a few similar other cases in the patch.


In general, we should use as few compatibility tricks possible for
ucrtbase as much as since we can depend on those functions being present
in runtime. Having something like you're working on was actually the
main reason I moved a lot of compatibility code from mingwex into
libmsvcrt.a a few years ago. There are more things that could be moved
away from mingwex like that. From your other patch, for example, it
looks like we may not need mingw variants of printf/scanf family when
targetting ucrtbase, so maybe we could even move them to libmsvcrt.a as
well. I'm not sure.

Yes, those shouldn't be needed any longer. They aren't used by default at all either, unless __USE_MINGW_ANSI_STDIO is defined. If it is, we still use our own routines for safety, but if others are ok with it, we can probably change it. But it might be easier to make each of those changes a separate patch/discussion later, after we've got a first common state merged.

Anyway, that doesn't have to block integration of your work, but it'd be
nice to take into account when doing design decisions. For this patch,
just please review those "replaced by emu" cases since they shouldn't be
needed for ucrtbase.

Sure, I can try to have a look through those and see if I can figure out what the situation is.

Thanks for pointing these out; I went through all the functions that I had commented out in this patch, and almost all of them were in replacements in secapi/* that only was built into libmsvcrt.a but not into the numbered ones. So after uncommenting those, only a few functions are uncommented (that are replaced by libmingwex).

If there's no other comments/objections, I'll push this patchset soon.

// Martin
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to