[PATCH v1 1/3] Feature test macro overhaul
Yaakov Selkowitz
yselkowitz@cygwin.com
Fri Feb 12 18:08:00 GMT 2016
On 2016-02-12 08:58, Corinna Vinschen wrote:
> On Feb 12 07:59, Sebastian Huber wrote:
>> its good that you keep the FreeBSD __*_VISIBLE defines in place, so
>> that its still easy to use code from FreeBSD. At least for RTEMS this
>> is important, since we use the network, USB and SD/MMC stack from
>> FreeBSD.
>>
>> I am not sure if its a good thing to do the feature checks differently
>> in each C library. My approach would have been to us an existing
>> mechanism and in case of errors report them to the upstream.
>
> I'm also a bit concerned here. It decouples us partially from upstream.
> The changes don't look bad, mind, but it now looks a bit like a mix
> between Glibc and FreeBSD. Can we maintain this easily in future?
Having built thousands of packages for Cygwin, I can attest that our
feature test macros are lacking in several ways:
* combining -ansi/-std=c* -D_*_SOURCE doesn't always work as expected;
* several _*_SOURCE switches aren't recognized;
* some symbols don't have the proper guards.
Obviously, this is modeled after glibc's feature test macros documentation:
http://man7.org/linux/man-pages/man7/feature_test_macros.7.html
with some changes found upon testing, while maintaining the __*_VISIBLE
nomenclature already present instead of the __USE_* mentioned therein.
WRT style, I thought that being able to use #if instead of #ifdef (or
even #if defined() || defined() etc.) would be more readable,
particularly when a symbol can be switched on my multiple guards.
Similarly, e.g. __POSIX2001_VISIBLE would be easier to read than
__POSIX_VISIBLE >= 200112L, particularly in the cases where things were
in previous versions of POSIX.1 but removed in later versions.
WRT compatibility with FreeBSD, the only issue would be if entire
headers are copied therefrom. However, there are certainly some
FreeBSD-isms have to anyways be tweaked when doing so; I don't see how
this is any different.
--
Yaakov
More information about the Newlib
mailing list