After some reading about the C++ standards, I believe that older standards do not prohibit having future-looking functions or classes in place. That said, I also find nothing regarding any such "future-looking functions or classes" in Clang [note: some people call these "extensions", like as provided by the GNU project -- and, thus requested via "-std=gnu++XY" instead of the usual "-std=c++XY".
I'm investigating this issue more today, trying a list similar to what Jeff Dalton did for this GCC bug for C < https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 > except for C++. The good news is that we now have the legacy support project where such overlooked functions can be declared (if part of the ABI but not API), and/or defined (if not part of either the ABI or API when they should be). I believe that either can be accomplished pretty straight forwardly. We'll see & more as I find it! - MLD On Tue, Feb 5, 2019, at 12:07 AM, Joshua Root wrote: > On 2019-2-5 13:59 , Michael Dickens wrote: > > The interesting strangeness is that the clang++ compilers (both Apple and > > MP) do not generate errors when using -std=c++98 or -std=c++03 ... which is > > wrong! The #warning printout indicates that the correct __cplusplus is > > selected, but the build should not succeed! All g++ compilers correctly > > error out with these -std settings. > > > > This lack of compliance at least by default is troubling! Maybe I'm missing > > something here? Are there some other flags I should be setting to keep > > clang from figuring out the c++ standard and using it instead of what I > > specify -- if this is the issue? > > Are you certain that the C++98/03 standards prohibit the standard > library from providing this function? It may well be that an > implementation is compliant as long as everything specified in the > standard is present and behaves correctly; providing additional > functionality may be irrelevant. > > - Josh
