This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Michael.Felt
Recipients David.Edelsohn, Michael.Felt, vstinner, xdegaye
Date 2018-01-03.17:21:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <ab91b317-1783-7e7b-a675-5b57a7e5e3a6@felt.demon.nl>
In-reply-to <1514986870.5.0.467229070634.issue32390@psf.upfronthosting.co.za>
Content
On 03/01/2018 14:41, David Edelsohn wrote:
> David Edelsohn <dje.gcc@gmail.com> added the comment:
>
> _ALL_SOURCE is overkill. It probably is too big a club for this regression.

Maybe. Clearly it is a big club. The documentation - if you can find any 
- is ancient and/or confusing. For example the xlc compiler reference 
quide (v12 is what I referenced, not the latest, but what I found) only 
has a single reference to any "_SOURCE" macro (-D_POSIX_SOURCE).

I do not know 'why' AIX and Linux differ in the way they name things. I 
do not want to care either - which is why I, personally, am less 
concerned about the size of the club. People much more clever than I 
decided that many variable names should be without two underscores 
(_ALL_SOURCE is defined) while others felt they must have two 
underscores (_ALL_SOURCE is undefined).

IMHO: 15+ years ago IBM (AIX) worked to find a method to simplify 
porting. And, I hope somewhere someone knows what these all meant. The 
practice seems to be to always define _ALL_SOURCE (see configure.ac:
   +882  # checks for UNIX variants that set C preprocessor variables
   +883  AC_USE_SYSTEM_EXTENSIONS
   +884
https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Posix-Variants.html

Here is where I read that _ALL_SOURCE is for AIX3. I can neither deny 
nor affirm that that is (still) accurate. But that is what working with 
autotools does. Throws a sauce over everything that may, or maynot be 
what is needed.

I considered it 'interesting' that <sys/types.h> at least talks a bit 
about _POSIX_SOURCE and _ALL_SOURCE.

>   However, the AIX header definition of fsid compatible with the current Python posixmodule.c code is bracketed by _ALL_SOURCE.
>
> AFAICT, the change to posixmodule.c made assumptions about fsid based on Linux and not required by POSIX. This didn't simply introduce a testsuite regression, but broke the build on AIX. The posixmodule.c code should be corrected or should be reverted.

Maybe reverting the change is better than using the "big club". But, 
asis, AIX is dead to development. Was it possible to have AIX included 
in the PR test process I would hope that the PR would never have been 
merged.

IMHO - this is a spelling issue, going back years. But if you use a 
UK-only spelling checker and try and use only US spelling rules - and 
v.v. - there will be 'issues'. What is the solution with the most 
clarity? Above my pay grade to answer.

In any case the previous issue that saw adding fsid as a solution was 
not fully tested across all platforms. Currently AIX is broken. Someone 
needs to decide how to restore a supported platform - and where the 
discussion on fsid either restarts or continues.

In short - I am just a messenger - you are the experts. :)

>
> ----------
> nosy: +vstinner
> title: AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed -> AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue32390>
> _______________________________________
>
History
Date User Action Args
2018-01-03 17:21:14Michael.Feltsetrecipients: + Michael.Felt, vstinner, xdegaye, David.Edelsohn
2018-01-03 17:21:14Michael.Feltlinkissue32390 messages
2018-01-03 17:21:14Michael.Feltcreate