RFR: JDK-8160997 Solaris: deprecated <pwd.h> and <gid.h> interfaces should be replaced

[David Holmes]

Hi Alan,

tl;dr: reviewed as-is

More inline ...

On 14/07/2016 5:52 PM, Alan Burlison wrote:
> On 14/07/2016 02:20, David Holmes wrote:
>
>> One query: if pwd.h is not the last file included don't we need to undef
>>   _POSIX_PTHREAD_SEMANTICS again to ensure no other included definitions
>> are affected? If we don't need to do that then I wonder whether
>> _POSIX_PTHREAD_SEMANTICS should not simply be set via the build system
>> for all compilations?
>
> _POSIX_PTHREAD_SEMANTICS only affects a few APIs which changed between
> POSIX.1c Draft 6 and POSIX 1003.1c - Solaris implemented the draft
> version due to release scheduling issues, which was a mistake. Some of
> the differences don't matter for LP64 apps such as Java, the other APIs
> are less-frequently used. The main problems you tend to see are the
> user/group iteration APIs (as in this case) and directory enumeration.
> You could undef _POSIX_PTHREAD_SEMANTICS if you wanted but there's no
> real benefit and it would add yet more clutter.

Okay I looked further into the affect of this (I recalled we also use it 
in a test to deal with a sigwait API issue) and see that it changes the 
form of the function prototypes (and underlying implementation) so it 
won't silently change anything.

> As for setting it globally, no that wouldn't be a good idea. It's a
> workaround for a problem that will be gone in later Solaris releases,
> where you'll get the POSIX 1003.1c definitions by default and will have
> to explicitly ask for the old draft ones. At that point defining
> _POSIX_PTHREAD_SEMANTICS will have no effect. It is a transitional
> workaround for a misfeature and as such I believe needs to be restricted
> as much as possible by just adding it to the affected files, and then
> removing it altogether as soon as possible.

Looking further into this aspect I can't help but feel we should be 
defining:

_POSIX_C_SOURCE=200112L

which would also fix the current problem and more generally make it 
clear we are intending to use specific standard-based API's. But that is 
going somewhat further than the scope of the current fix - and may run 
into unexpected consequences (we've been somewhat lax at programming to 
specific language and API versions).

So I'm okay with the fix as it stands.

Thanks,
David