Many POSIX functions aren’t available on every system, especially embedded ones.

The first patch introduces guards around some of these functions and add them to AC_CHECK_FUNCS in the configure.ac; the second one recompile every changed generated file, using autoreconf -fi and clinic.

This issue is still present in latest 3.5, all the way down to 2.7.

Removed the unwanted introduced function, and added a comment signaling the end of the HAVE_TTYNAME #ifdef.

The full patch is attached, the diff with the previous version can be found at http://linkmauve.fr/files/getedig.patch

3.2 and 3.3 are only for security fixes now.

HAVE_SYS_RESOURCE_H still is used for #include in several files.

If guards are added to pwd functions, shouldn't it be added to grp and spwd functions? Is there a platform that have pwd.h, but not getpwuid, getpwnam or getpwent. May be instead testing the existence of separate functions adds the test about the existence of pwd.h in configure?

Personally, I'd rather answer that it's not our problem if some systems are not POSIX-compliant. Maintainers of such systems can always maintain a patch to disable the missing functionality. Adding conditionals everywhere has a non-trivial maintenance cost.

> Many POSIX functions aren’t available on every system, especially embedded ones.

What do you call "embedded systems"? I worked on set top boxes (the box to watch television) between 2011 and 2013 and we had a regular Linux kernel with all POSIX functions. Most of the time, the CPU was a slow MIPS. The tool chain was based on GCC. For some hardware, we used the µlibc but this C library provides all functions required by Python.

> Personally, I'd rather answer that it's not our problem if some systems are not POSIX-compliant. Maintainers of such systems can always maintain a patch to disable the missing functionality. Adding conditionals everywhere has a non-trivial maintenance cost.

I agree. Anyway, in the embedded world, softwares are usually old and heavily patched. For example, in 2013 we still used Python 2.5.2 with a lot of patches. For example, patches for cross compilation. But also backported features like HTTP Keep-Alive or HTTPS checks.

Technically, you can easily fork Python repository and keep your patches up to date using rebase.

We defined better rules to support officially a platform. A requirement is for example to have a buildbot running tests daily on the platform. I'm not sure that you are able to host a public buildbot for each custom embedded platform...

Android looks a more important target and it was already discussed to setup a Android buildbot.

I'm in favor of *dropping* all these annoying #ifdef because it's harder to review, maintain and debug such code. Here is my contribution: issue #23753 "Drop HAVE_FSTAT: require fstat() to compile/use Python". A concrete example: we are working on a Python implementation of io.FileIO and I don't want to see hasattr(os, 'fstat') in the Python code because it has a performance cost *at runtime* (see issue #21859).

See also the new Mobile-SIG mailing list which is maybe more appropriate to discuss such changes:
https://mail.python.org/mailman/listinfo/mobile-sig

On Mon, Mar 23, 2015 at 09:05:20PM +0000, STINNER Victor wrote:
> 
> STINNER Victor added the comment:
> 
> > Many POSIX functions aren’t available on every system, especially embedded ones.
> 
> What do you call "embedded systems"? I worked on set top boxes (the box to watch television) between 2011 and 2013 and we had a regular Linux kernel with all POSIX functions. Most of the time, the CPU was a slow MIPS. The tool chain was based on GCC. For some hardware, we used the µlibc but this C library provides all functions required by Python.

My target platforms have been the Newlib-based Wii and 3DS homebrew toolchains, which emulate a POSIX system on top of the raw hardware (or in the case of the 3DS, a proprietary micro-kernel.

> 
> > Personally, I'd rather answer that it's not our problem if some systems are not POSIX-compliant. Maintainers of such systems can always maintain a patch to disable the missing functionality. Adding conditionals everywhere has a non-trivial maintenance cost.
> 
> I agree. Anyway, in the embedded world, softwares are usually old and heavily patched. For example, in 2013 we still used Python 2.5.2 with a lot of patches. For example, patches for cross compilation. But also backported features like HTTP Keep-Alive or HTTPS checks.

There is a port of Python 2.5.something for the Wii, terribly outdated, and this is why I wanted to merge the non-specifics parts of my port upstream, as I thought it would help everyone in that case.

> 
> Technically, you can easily fork Python repository and keep your patches up to date using rebase.
> 
> We defined better rules to support officially a platform. A requirement is for example to have a buildbot running tests daily on the platform. I'm not sure that you are able to host a public buildbot for each custom embedded platform...

I can provide such a buildbot on my spare Wii.  Not really for the 3DS yet, as the homebrew scene is much younger there and unrecoverable lockups happen.

> 
> Android looks a more important target and it was already discussed to setup a Android buildbot.
> 
> I'm in favor of *dropping* all these annoying #ifdef because it's harder to review, maintain and debug such code. Here is my contribution: issue #23753 "Drop HAVE_FSTAT: require fstat() to compile/use Python". A concrete example: we are working on a Python implementation of io.FileIO and I don't want to see hasattr(os, 'fstat') in the Python code because it has a performance cost *at runtime* (see issue #21859).

On those two platforms, fstat() is correctly defined and works fine, so it shouldn’t be a problem to drop its #ifdef.

> 
> See also the new Mobile-SIG mailing list which is maybe more appropriate to discuss such changes:
> https://mail.python.org/mailman/listinfo/mobile-sig
> 
> ----------
> nosy: +haypo
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue22623>
> _______________________________________

> My target platforms have been the Newlib-based Wii and 3DS homebrew toolchains, which emulate a POSIX system on top of the raw hardware (or in the case of the 3DS, a proprietary micro-kernel.

What do you think of my idea of maintaining a fork of the Python repository to store your patches, and rebase them sometimes?

Would it be an acceptable solution?