Libc++ Windows fixes

Clang Frontend
#1

Hi guys,

I know this is more patchwork than it's currently worth, but every bit
helps of course!

Attached is some small fixes for libc++:
- cerrno: like in Boost's cerrno, define the missing error constants
if they are undefined (which most of them are for Windows)
- __locale: include the correct Windows headers to pull in the
correct constants and use those for Windows.
- locale: don't include nl_types.h on windows, as it is unavailable
on that platform.

I hope I can get more fixes which are as trivial as these soon.

I do not have commit access (which seems to be a rarity around here),
and was told to shout loud for someone that would like to commit this.
so here it is:
SHOUT!
Please commit when you feel you're OK with it.

Thanks!

Ruben

#2

This is a larger patch with a bit more changes. I added a
win32/support.h/cpp to add any missing functionality. For now that's
only a simple enum and a simple vasprintf implementation.

Note that to get as far as this, with the current _STD macro problem
(because it is used internally in the MS headers), you need to add a
temporary workaround #define in the problematic file. That does not
have to be committed!

The cerrno macro's are from Boost, so "yes, they are correct", and
"no, there are no license restrictions whatsoever". The _strto*_l
functions are available on Windows msvcrt version 7. That's the
default somewhere Vista/7-ish, so those aren't available on XP. I
believe the Linux locale patch also takes into consideration providing
a Windows alternative with little or no modification.

I'm quite sure the win32/support.h/cpp isn't the nicest solution,
please do as you wish, there just needs to be a central place to add
missing fundamental functionality. Perhaps a larger splitting of OS
dependent functionality might be appropriate in the future.

As of with this patch (which includes the _STD clash workaround, I am
now stranded at the catopen call in __locale, which as a little
googling shows is very non-Windows-ish, and perhaps needs a lot more
than just extra constants, #defines and #includes.

I would be pleased if anyone would commit at least the part of it they like :slight_smile:

Thanks,

Ruben

windows2.patch (7.6 KB)

#3

I’m really glad for the windows fixes, because at times I do develop on Windows.

But… (and I don’t want to be too much of a stickler for licensing) I understand the Boost license does require you to include the BSL in files that use Boost code (http://www.boost.org/LICENSE_1_0.txt).

#4

Boost libraries are not necessarily under the BSL, and the copyright disclaimer requires reproduction in order to take BSLed code. I don't think Chris Lattner wants to mix in foreign-licensed code for that reason.

Sean

#5

The file the code comes from should contain copyright details,
including the name of the copyright owner who could possibly release
the code under another license.

#6

The person to contact would be
http://www.boost.org/users/people/beman_dawes.html

If someone "official" from libc++/LLVM/Clang could ask him, there's
probably a better chance of success instead of everyone asking
everyone who needs to be asked and told what. Specifically me not
knowing who Mr. Dawes should inform about what license type which I
wouldn't know would be acceptable under the terms which I couldn't
negotiate. I think you get my drift :slight_smile:

I don't hope that a bunch of constant defines would tickle his toes
much. I could persuade you I got them from pure white room reverse
engineering and I give them to you as a gift :-)?

Ruben

#7

As a backup, the ACE library also has lots of these definitions, maybe
even better (a lot less magic numbers) and they only need the
copyright notice reproduced, which could be in comments above the
#define's?

Ruben

#8

My apologies for the increased amount of spam about this, but I just
noticed mingw-w64 provides these definitions under Public Domain (ie
no copyright assigned). You can find it here:

http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-headers/include/psdk_inc/_wsa_errnos.h?revision=3546&view=markup

Would this be a more troublefree and acceptable source? I can ask the
mingw-w64 devs if PD conflicts with libc++ licensing, I'm sure they'll
be more than happy to help my effort.

Ruben

#9

This is a larger patch with a bit more changes. I added a
win32/support.h/cpp to add any missing functionality. For now that's
only a simple enum and a simple vasprintf implementation.

Note that to get as far as this, with the current _STD macro problem
(because it is used internally in the MS headers), you need to add a
temporary workaround #define in the problematic file. That does not
have to be committed!

I'll just change _STD to _VSTD (versioned std). Is _VSTD already taken on windows?

The cerrno macro's are from Boost, so "yes, they are correct", and
"no, there are no license restrictions whatsoever". The _strto*_l
functions are available on Windows msvcrt version 7. That's the
default somewhere Vista/7-ish, so those aren't available on XP. I
believe the Linux locale patch also takes into consideration providing
a Windows alternative with little or no modification.

These constants appear to me to be public knowledge (i.e. no copyright issues).

I'm quite sure the win32/support.h/cpp isn't the nicest solution,
please do as you wish, there just needs to be a central place to add
missing fundamental functionality. Perhaps a larger splitting of OS
dependent functionality might be appropriate in the future.

As of with this patch (which includes the _STD clash workaround, I am
now stranded at the catopen call in __locale, which as a little
googling shows is very non-Windows-ish, and perhaps needs a lot more
than just extra constants, #defines and #includes.

I would be pleased if anyone would commit at least the part of it they like :slight_smile:

Let me commit the _STD -> _VSTD first, and then create a new patch using that.

Howard

#10

This is a larger patch with a bit more changes. I added a
win32/support.h/cpp to add any missing functionality. For now that's
only a simple enum and a simple vasprintf implementation.

Note that to get as far as this, with the current _STD macro problem
(because it is used internally in the MS headers), you need to add a
temporary workaround #define in the problematic file. That does not
have to be committed!

I'll just change _STD to _VSTD (versioned std). Is _VSTD already taken on windows?

a "grep -r "_VSTD" ." in the MSVC 10 include directory, the mingw-w64
include directory, and the Windows SDK v7.1 include directory turned
up no results, so this should be fine.

The cerrno macro's are from Boost, so "yes, they are correct", and
"no, there are no license restrictions whatsoever". The _strto*_l
functions are available on Windows msvcrt version 7. That's the
default somewhere Vista/7-ish, so those aren't available on XP. I
believe the Linux locale patch also takes into consideration providing
a Windows alternative with little or no modification.

These constants appear to me to be public knowledge (i.e. no copyright issues).

Good to know. Although the bottom of the mingw-w64 header here
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-headers/include/psdk_inc/_wsa_errnos.h?revision=3546&view=markup
seems to imply there are more sensible defines (without that many
magic numbers, mostly to WSAE* codes which ought to come from
<winsock2.h>). I cannot judge the difference though...

I'm quite sure the win32/support.h/cpp isn't the nicest solution,
please do as you wish, there just needs to be a central place to add
missing fundamental functionality. Perhaps a larger splitting of OS
dependent functionality might be appropriate in the future.

As of with this patch (which includes the _STD clash workaround, I am
now stranded at the catopen call in __locale, which as a little
googling shows is very non-Windows-ish, and perhaps needs a lot more
than just extra constants, #defines and #includes.

I would be pleased if anyone would commit at least the part of it they like :slight_smile:

Let me commit the _STD -> _VSTD first, and then create a new patch using that.

Thanks! I'd like to do more, but I think I've reached my knowledge and
capability limits. Some Windows guru (or even better, a Windows C++
guru) will have to step up and implement more of libc++ to be usable.
Remember that the _strto*_l functions are very new, and most probably
don't work on XP, and may not work on Vista. I look to the Linux patch
on this and *hope* it is general/compatible enough to work without
much modification on Windows as well.

Ruben

#11

2011/6/30 Ruben Van Boxem <vanboxem.ruben@gmail.com>

2011/6/30 Howard Hinnant <hhinnant@apple.com>:

This is a larger patch with a bit more changes. I added a
win32/support.h/cpp to add any missing functionality. For now that’s
only a simple enum and a simple vasprintf implementation.

Note that to get as far as this, with the current _STD macro problem
(because it is used internally in the MS headers), you need to add a
temporary workaround #define in the problematic file. That does not
have to be committed!

I’ll just change _STD to _VSTD (versioned std). Is _VSTD already taken on windows?

a “grep -r “_VSTD” .” in the MSVC 10 include directory, the mingw-w64
include directory, and the Windows SDK v7.1 include directory turned
up no results, so this should be fine.

The cerrno macro’s are from Boost, so “yes, they are correct”, and
“no, there are no license restrictions whatsoever”. The _strto*_l
functions are available on Windows msvcrt version 7. That’s the
default somewhere Vista/7-ish, so those aren’t available on XP. I
believe the Linux locale patch also takes into consideration providing
a Windows alternative with little or no modification.

These constants appear to me to be public knowledge (i.e. no copyright issues).

Good to know. Although the bottom of the mingw-w64 header here

http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-headers/include/psdk_inc/_wsa_errnos.h?revision=3546&view=markup

seems to imply there are more sensible defines (without that many
magic numbers, mostly to WSAE* codes which ought to come from
<winsock2.h>). I cannot judge the difference though…

I’m quite sure the win32/support.h/cpp isn’t the nicest solution,
please do as you wish, there just needs to be a central place to add
missing fundamental functionality. Perhaps a larger splitting of OS
dependent functionality might be appropriate in the future.

As of with this patch (which includes the _STD clash workaround, I am
now stranded at the catopen call in __locale, which as a little
googling shows is very non-Windows-ish, and perhaps needs a lot more
than just extra constants, #defines and #includes.

I would be pleased if anyone would commit at least the part of it they like :slight_smile:

Let me commit the _STD → _VSTD first, and then create a new patch using that.

Thanks! I’d like to do more, but I think I’ve reached my knowledge and
capability limits. Some Windows guru (or even better, a Windows C++
guru) will have to step up and implement more of libc++ to be usable.
Remember that the _strto*_l functions are very new, and most probably
don’t work on XP, and may not work on Vista. I look to the Linux patch
on this and hope it is general/compatible enough to work without
much modification on Windows as well.

I have finally gotten to more libc++ Windows work, and attached is a patch that addresses some of the issues that pop up. I know it’s a lot to take in, but most changes are pretty logical (or I wouldn’t have been able to find/code them). I’m currently facing implementing wcsnrtombs and after that there’s the more troubling issue of catgets and associates, which I’m quite worried about, as Win32 is almost orthogonal to this whole API. Ideas for that are very welcome.

The patch explained:

  • include/__config/type_traits: add a define _LIBCXX_HAS_FEATURE_IS_BASE_OF for MSVC and GCC, which both have this, but not __has_feature, which is Clang-only. Modify <type_traits> accordingly.
  • include/locale: Win32 does not have nl_types, which really sucks… big time.
  • include/cerrno: the missing error constants, very much acceptable as said by Howard in this thread some time ago.
  • include/__locale: include the new support/win32/locale.h header, and leave out the missing xlocale.h. Maybe a stupid name, but I haven’t found a better name for it. Maybe once the whole win32 stuff is complete, some refactoring is in order. The mask type is defined and all values are defined to the correct values (extracted from mingw-w64 headers).
  • include/support/win32/support.h: a place for missing functions’ declarations to live.
  • include/support/win32/locale.h: locale-related stuff (duh!) missing or otherwise defined in Win32 headers.
  • CMakeLists.txt: add the new files, only on Win32.
  • src/support/win32/support.cpp: implementation of functions in include/support/win32/support.h.

All this should work for both MinGW(-w64)/GCC and Microsoft/MSVC headers/libraries. Note the *_l functions are only available on recent Windows versions, which should be good enough for now. Especially the locale stuff (up till now!) should work for more than only plain “C” locale.

One point of attention: the FIXME in the new locale.h header needs attention: Win32 needs to call a function to enable thread-local locales, and then setlocale operates on the thread’s locale, which is great. But this function needs to be called somewhere before everything else (in some static initialization function or something). On top of that, I’m not quite sure that what I do in my short implementation of uselocale is correct. I think it is, and it definitely is inefficient.

I tested this on GCC and Clang built for mingw-w64.

Please review and commit if you’re OK. Thanks!

Ruben

PS: any further help is very much appreciated!

windows-locale.patch (10.9 KB)

#12

I've slightly modified your patch (enclosed below) for your review. My modification consisted of changes only to <__config> and <type_traits>.

I've confirmed that there is no impact to OS X. I have no opinion on what this does for _WIN32 (if others do, please speak up). If you (and everyone else) is ok with this patch, then add to this patch your entry in CREDITS.TXT and post back. I'll commit it.

Thanks,
Howard

windows-locale.patch (11 KB)

#13

2011/9/22 Howard Hinnant <hhinnant@apple.com>

Thanks! I’d like to do more, but I think I’ve reached my knowledge and
capability limits. Some Windows guru (or even better, a Windows C++
guru) will have to step up and implement more of libc++ to be usable.
Remember that the _strto*_l functions are very new, and most probably
don’t work on XP, and may not work on Vista. I look to the Linux patch
on this and hope it is general/compatible enough to work without
much modification on Windows as well.

I have finally gotten to more libc++ Windows work, and attached is a patch that addresses some of the issues that pop up. I know it’s a lot to take in, but most changes are pretty logical (or I wouldn’t have been able to find/code them). I’m currently facing implementing wcsnrtombs and after that there’s the more troubling issue of catgets and associates, which I’m quite worried about, as Win32 is almost orthogonal to this whole API. Ideas for that are very welcome.

The patch explained:

  • include/__config/type_traits: add a define _LIBCXX_HAS_FEATURE_IS_BASE_OF for MSVC and GCC, which both have this, but not __has_feature, which is Clang-only. Modify <type_traits> accordingly.
  • include/locale: Win32 does not have nl_types, which really sucks… big time.
  • include/cerrno: the missing error constants, very much acceptable as said by Howard in this thread some time ago.
  • include/__locale: include the new support/win32/locale.h header, and leave out the missing xlocale.h. Maybe a stupid name, but I haven’t found a better name for it. Maybe once the whole win32 stuff is complete, some refactoring is in order. The mask type is defined and all values are defined to the correct values (extracted from mingw-w64 headers).
  • include/support/win32/support.h: a place for missing functions’ declarations to live.
  • include/support/win32/locale.h: locale-related stuff (duh!) missing or otherwise defined in Win32 headers.
  • CMakeLists.txt: add the new files, only on Win32.
  • src/support/win32/support.cpp: implementation of functions in include/support/win32/support.h.

All this should work for both MinGW(-w64)/GCC and Microsoft/MSVC headers/libraries. Note the *_l functions are only available on recent Windows versions, which should be good enough for now. Especially the locale stuff (up till now!) should work for more than only plain “C” locale.

One point of attention: the FIXME in the new locale.h header needs attention: Win32 needs to call a function to enable thread-local locales, and then setlocale operates on the thread’s locale, which is great. But this function needs to be called somewhere before everything else (in some static initialization function or something). On top of that, I’m not quite sure that what I do in my short implementation of uselocale is correct. I think it is, and it definitely is inefficient.

I tested this on GCC and Clang built for mingw-w64.

Please review and commit if you’re OK. Thanks!

I’ve slightly modified your patch (enclosed below) for your review. My modification consisted of changes only to <__config> and <type_traits>.

I’ve confirmed that there is no impact to OS X. I have no opinion on what this does for _WIN32 (if others do, please speak up). If you (and everyone else) is ok with this patch, then add to this patch your entry in CREDITS.TXT and post back. I’ll commit it.

I’m definitely OK with the changes, it’s a bit more streamlined now. I also found a tab vs 4 spaces on a line that I fixed. Added me as “initial Windows patches”-contributor. Hopefully I can expand on that later :slight_smile:

Thanks for the quick response!

Ruben

windows-locale.patch (11.3 KB)

#14

2011/9/22 Ruben Van Boxem <vanboxem.ruben@gmail.com>

2011/9/22 Howard Hinnant <hhinnant@apple.com>

Thanks! I’d like to do more, but I think I’ve reached my knowledge and
capability limits. Some Windows guru (or even better, a Windows C++
guru) will have to step up and implement more of libc++ to be usable.
Remember that the _strto*_l functions are very new, and most probably
don’t work on XP, and may not work on Vista. I look to the Linux patch
on this and hope it is general/compatible enough to work without
much modification on Windows as well.

I have finally gotten to more libc++ Windows work, and attached is a patch that addresses some of the issues that pop up. I know it’s a lot to take in, but most changes are pretty logical (or I wouldn’t have been able to find/code them). I’m currently facing implementing wcsnrtombs and after that there’s the more troubling issue of catgets and associates, which I’m quite worried about, as Win32 is almost orthogonal to this whole API. Ideas for that are very welcome.

The patch explained:

  • include/__config/type_traits: add a define _LIBCXX_HAS_FEATURE_IS_BASE_OF for MSVC and GCC, which both have this, but not __has_feature, which is Clang-only. Modify <type_traits> accordingly.
  • include/locale: Win32 does not have nl_types, which really sucks… big time.
  • include/cerrno: the missing error constants, very much acceptable as said by Howard in this thread some time ago.
  • include/__locale: include the new support/win32/locale.h header, and leave out the missing xlocale.h. Maybe a stupid name, but I haven’t found a better name for it. Maybe once the whole win32 stuff is complete, some refactoring is in order. The mask type is defined and all values are defined to the correct values (extracted from mingw-w64 headers).
  • include/support/win32/support.h: a place for missing functions’ declarations to live.
  • include/support/win32/locale.h: locale-related stuff (duh!) missing or otherwise defined in Win32 headers.
  • CMakeLists.txt: add the new files, only on Win32.
  • src/support/win32/support.cpp: implementation of functions in include/support/win32/support.h.

All this should work for both MinGW(-w64)/GCC and Microsoft/MSVC headers/libraries. Note the *_l functions are only available on recent Windows versions, which should be good enough for now. Especially the locale stuff (up till now!) should work for more than only plain “C” locale.

One point of attention: the FIXME in the new locale.h header needs attention: Win32 needs to call a function to enable thread-local locales, and then setlocale operates on the thread’s locale, which is great. But this function needs to be called somewhere before everything else (in some static initialization function or something). On top of that, I’m not quite sure that what I do in my short implementation of uselocale is correct. I think it is, and it definitely is inefficient.

I tested this on GCC and Clang built for mingw-w64.

Please review and commit if you’re OK. Thanks!

I’ve slightly modified your patch (enclosed below) for your review. My modification consisted of changes only to <__config> and <type_traits>.

I’ve confirmed that there is no impact to OS X. I have no opinion on what this does for _WIN32 (if others do, please speak up). If you (and everyone else) is ok with this patch, then add to this patch your entry in CREDITS.TXT and post back. I’ll commit it.

I’m definitely OK with the changes, it’s a bit more streamlined now. I also found a tab vs 4 spaces on a line that I fixed. Added me as “initial Windows patches”-contributor. Hopefully I can expand on that later :slight_smile:

Thanks for the quick response!

I spotted another type in the CMakeLists file (missing …support/… subdirectory). Attached patch fixes that.

Ruben

windows-locale.patch (11.3 KB)

#15

- include/__config/type_traits: add a define _LIBCXX_HAS_FEATURE_IS_BASE_OF
for MSVC and GCC, which both have this, but not __has_feature, which is
Clang-only. Modify <type_traits> accordingly.

I noticed that you're testing _MSC_VER 1400, which is VS 2005.
However, I couldn't find any documentation of is_base_of for anything
before Visual Studio 2008 (_MSC_VER 1500). Unfortunately, I don't
have VS 2005 to test for sure, but this may require a second look. Or
I could be wrong. :wink:

All this should work for both MinGW(-w64)/GCC and Microsoft/MSVC
headers/libraries. Note the *_l functions are only available on recent
Windows versions, which should be good enough for now. Especially the locale
stuff (up till now!) should work for more than only plain "C" locale.

It's more dependent on the MSVCRT version on the system than the OS.
I've seen the _l versions of the APIs with VS 2005, and the claimed
support (assuming the proper redist is installed) is as far back as
Windows 95.

Overall, I think the patch looks good though.

~Aaron

#16

2011/9/22 Aaron Ballman <aaron@aaronballman.com>

2011/6/30 Ruben Van Boxem <vanboxem.ruben@gmail.com>

  • include/__config/type_traits: add a define _LIBCXX_HAS_FEATURE_IS_BASE_OF
    for MSVC and GCC, which both have this, but not __has_feature, which is
    Clang-only. Modify <type_traits> accordingly.

I noticed that you’re testing _MSC_VER 1400, which is VS 2005.
However, I couldn’t find any documentation of is_base_of for anything
before Visual Studio 2008 (_MSC_VER 1500). Unfortunately, I don’t
have VS 2005 to test for sure, but this may require a second look. Or
I could be wrong. :wink:

MSVS2005 page detailing __is_base_of. the 2003 page doesn’t have this page, so I assume it does not support it.
http://msdn.microsoft.com/en-us/library/ms177194%28v=vs.80%29.aspx

All this should work for both MinGW(-w64)/GCC and Microsoft/MSVC
headers/libraries. Note the *_l functions are only available on recent
Windows versions, which should be good enough for now. Especially the locale
stuff (up till now!) should work for more than only plain “C” locale.

It’s more dependent on the MSVCRT version on the system than the OS.
I’ve seen the _l versions of the APIs with VS 2005, and the claimed
support (assuming the proper redist is installed) is as far back as
Windows 95.

Ok, good to know. After checking MSDN again, I did find all these functions in VS2005 doc pages, so that could mean XP has decent support (if kept up to date). I never understood how Windows, msvcrt.dll and the redistributable packages worked…

Overall, I think the patch looks good though.

Great news, thanks!

Ruben

#17

Patch committed revision 140328.

Howard

#18

> - include/__config/type_traits: add a define
> _LIBCXX_HAS_FEATURE_IS_BASE_OF
> for MSVC and GCC, which both have this, but not __has_feature, which is
> Clang-only. Modify <type_traits> accordingly.

I noticed that you're testing _MSC_VER 1400, which is VS 2005.
However, I couldn't find any documentation of is_base_of for anything
before Visual Studio 2008 (_MSC_VER 1500). Unfortunately, I don't
have VS 2005 to test for sure, but this may require a second look. Or
I could be wrong. :wink:

MSVS2005 page detailing __is_base_of. the 2003 page doesn't have this page,
so I assume it does not support it.
http://msdn.microsoft.com/en-us/library/ms177194(v=vs.80).aspx

I stand corrected. When I was looking at the page for the feature,
for some reason the "Other Versions" menu only listed VS 2008 and VS
2010 for me.

> All this should work for both MinGW(-w64)/GCC and Microsoft/MSVC
> headers/libraries. Note the *_l functions are only available on recent
> Windows versions, which should be good enough for now. Especially the
> locale
> stuff (up till now!) should work for more than only plain "C" locale.

It's more dependent on the MSVCRT version on the system than the OS.
I've seen the _l versions of the APIs with VS 2005, and the claimed
support (assuming the proper redist is installed) is as far back as
Windows 95.

Ok, good to know. After checking MSDN again, I did find all these functions
in VS2005 doc pages, so that could mean XP has decent support (if kept up to
date). I never understood how Windows, msvcrt.dll and the redistributable
packages worked...

It's of a bit strange world. The basic rule of thumb that never fails
is: assume there's never any MS CRT installed, and have your installer
include the DLLs or merge modules that come with the VC++ install in
the redist directory. But you can't really rely on any specific CRT
being installed. For instance, I'm on Win7 ultimate, and I've got
CRTs for 2010 and 2003 but not 2008 or 2005. :-/

~Aaron

#19

2011/9/22 Howard Hinnant <hhinnant@apple.com>

Patch committed revision 140328.

Thanks!

Now that I’ve got your attention, on to more… involved… matters :slight_smile:

In order to support libc++'s current implementation using cat[gets|open|close] and nl_types.h (which I ignored for now), I would need to pull in some external code, namely mingw’s libcatgets and a supporting iconv library. These can all go under support/win32 and leave all other platforms unchanged of course, and leave the rest of libc++ as coherent as possible on all platforms. I understand Howard has an acceptable aversion to including too much foreign code in libc++, and hope you can see the need for this here.

There are some issues though:

  • libcatgets is licensed under GPLv2. If I can go through with this, I can ask/plead/beg the original author to allow a license change or ask him to make an exception for libc++. I know of no existing alternative.
  • for the iconv part, GNU libiconv is of course out of the question. There are two projects of interest: APR-iconv (Apache License 2.0) and win-iconv (BSD 2-clause license), the latter being tiny but primitive. The first is a truly first class implementation as far as I can see, and with minor refactoring could be included in the libc++ Windows build.
  • I am not an Open Source license lawyer, and do not know what would be acceptable for libc++ in this regard.

I want to ask what’s “best”, before starting with the implementation. The only real alternative is writing all this (ie catgets with supporting iconv code) from scratch, which I don’t see myself doing in the near to distant future. Another way is to completely replace libc++ parts that use/rely on these API’s, but this would make libc++ a lot more assymetric across platforms. In theory, these support files could help other platforms where these API’s are missing.

Please let me know what you think. Thanks!

Ruben

#20

I can only accept code that is copyrightable by the licenses in LICENSE.TXT and is not encumbered by any other copyright. To do otherwise will inhibit further acceptance of libc++.

Howard