> Well, that won't work well (at least > this way), but I agree we have to support it one way or another. Maybe > placing them in (almost) always included file would do the trick, but > that has other problems. That said, I'm fine with your crt solution.
I agree it won't work particularly well. If we were starting from scratch, I'd be *sorely* tempted to say that if people want intrinsic functions, they should include the intrinsic header. The same way I would say that if you want printf, you should include the stdio header. The idea of pulling particular prototypes out of a standard include file and pasting them all over seems nuts to me. However, it has been stressed to me repeatedly that compatibility with MSVC is a key goal and I find it hard to disagree. Given this constraint, this appears to be the best of the available options. That combined with *saying* that's how it works (which is why the comments are so long). I don't know that people spend a lot of time reading comments in system headers, but it's (slightly) better than nothing. > While I wasn't fun of adding new header in your previous patch (why > would we do that if it's included only from one file, intrin.h, > anyway?), we may add (yet another:/) new header for those shared intrins > and include it both from winnt.h and intrin.h. I'm not sure I completely understand how you envision this working. Are you talking about moving the prototypes from intrin.h to this new file too? How strongly do you feel about this? dw ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
