Hello, Some pieces of code are still guarded by: #ifdef HAVE_FSTAT ... #endif I would expect all systems to have fstat() these days. It's pretty basic POSIX, and even Windows has had it for ages. Shouldn't we simply make those code blocks unconditional? It would avoid having to maintain unused fallback paths. Regards Antoine.
2013/5/17 Antoine Pitrou <solipsis@pitrou.net>:
Hello,
Some pieces of code are still guarded by: #ifdef HAVE_FSTAT ... #endif
I would expect all systems to have fstat() these days. It's pretty basic POSIX, and even Windows has had it for ages. Shouldn't we simply make those code blocks unconditional? It would avoid having to maintain unused fallback paths.
+1 (Maybe Snakebite has such an exotic system, though?) :) -- Regards, Benjamin
On Fri, 17 May 2013 09:15:29 -0500 Skip Montanaro <skip@pobox.com> wrote:
Some pieces of code are still guarded by: #ifdef HAVE_FSTAT ... #endif
Are there other guards for similarly common libc functions?
I don't think so. Someone should take a look though :-) Regards Antoine.
I've had a quick look with grep -R HAVE_ * | egrep '[.]c:'. Modules/posixmodule.c has HAVE_UTIME_H and it might be standard libc on all posix platforms. Objects/obmalloc.c has HAVE_MMAP… but I guess that's fine given other platforms might not have such facility. Depending on the granularity (on a per platform or per feature) probably yes, there aren't many left. I hope this helps On 17 May 2013, at 16:56, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Fri, 17 May 2013 09:15:29 -0500 Skip Montanaro <skip@pobox.com> wrote:
Some pieces of code are still guarded by: #ifdef HAVE_FSTAT ... #endif
Are there other guards for similarly common libc functions?
I don't think so. Someone should take a look though :-)
Regards
Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/a.cavallo%40cavallinux.eu
2013/5/17 Antoine Pitrou <solipsis@pitrou.net>:
Hello,
Some pieces of code are still guarded by: #ifdef HAVE_FSTAT ... #endif
I would expect all systems to have fstat() these days. It's pretty basic POSIX, and even Windows has had it for ages. Shouldn't we simply make those code blocks unconditional? It would avoid having to maintain unused fallback paths.
I was sure I'd seen a post/bug report about this: http://bugs.python.org/issue12082 The OP was trying to build Python on an embedded platform without fstat(). cf
On Sun, 19 May 2013 10:08:39 +0200 Charles-François Natali <cf.natali@gmail.com> wrote:
2013/5/17 Antoine Pitrou <solipsis@pitrou.net>:
Hello,
Some pieces of code are still guarded by: #ifdef HAVE_FSTAT ... #endif
I would expect all systems to have fstat() these days. It's pretty basic POSIX, and even Windows has had it for ages. Shouldn't we simply make those code blocks unconditional? It would avoid having to maintain unused fallback paths.
I was sure I'd seen a post/bug report about this: http://bugs.python.org/issue12082
The OP was trying to build Python on an embedded platform without fstat().
Ah, right. Ok, judging by the answers I'm being consistent in my opinions :-) I still wonder why an embedded platform can't provide at least some emulation of fstat(), even by returning fake values. Not providing such a basic function must break a lot of existing third-party software. Regards Antoine.
Fake values would probably cause hard to debug problems. It's a long standing Python tradition not to offer low level APIs that the platform doesn't have. — Sent from Mailbox On Sun, May 19, 2013 at 5:20 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 19 May 2013 10:08:39 +0200 Charles-François Natali <cf.natali@gmail.com> wrote:
2013/5/17 Antoine Pitrou <solipsis@pitrou.net>:
Hello,
Some pieces of code are still guarded by: #ifdef HAVE_FSTAT ... #endif
I would expect all systems to have fstat() these days. It's pretty basic POSIX, and even Windows has had it for ages. Shouldn't we simply make those code blocks unconditional? It would avoid having to maintain unused fallback paths.
I was sure I'd seen a post/bug report about this: http://bugs.python.org/issue12082
The OP was trying to build Python on an embedded platform without fstat(). Ah, right. Ok, judging by the answers I'm being consistent in my opinions :-) I still wonder why an embedded platform can't provide at least some emulation of fstat(), even by returning fake values. Not providing such a basic function must break a lot of existing third-party software. Regards Antoine.
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
On Sun, 19 May 2013 07:47:14 -0700 (PDT) "Guido van Rossum" <gvanrossum@gmail.com> wrote:
Fake values would probably cause hard to debug problems. It's a long standing Python tradition not to offer low level APIs that the platform doesn't have.
I meant the platform, not Python. Regards Antoine.
— Sent from Mailbox
On Sun, May 19, 2013 at 5:20 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 19 May 2013 10:08:39 +0200 Charles-François Natali <cf.natali@gmail.com> wrote:
2013/5/17 Antoine Pitrou <solipsis@pitrou.net>:
Hello,
Some pieces of code are still guarded by: #ifdef HAVE_FSTAT ... #endif
I would expect all systems to have fstat() these days. It's pretty basic POSIX, and even Windows has had it for ages. Shouldn't we simply make those code blocks unconditional? It would avoid having to maintain unused fallback paths.
I was sure I'd seen a post/bug report about this: http://bugs.python.org/issue12082
The OP was trying to build Python on an embedded platform without fstat(). Ah, right. Ok, judging by the answers I'm being consistent in my opinions :-) I still wonder why an embedded platform can't provide at least some emulation of fstat(), even by returning fake values. Not providing such a basic function must break a lot of existing third-party software. Regards Antoine.
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
On Mon, May 20, 2013 at 12:51 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 19 May 2013 07:47:14 -0700 (PDT) "Guido van Rossum" <gvanrossum@gmail.com> wrote:
Fake values would probably cause hard to debug problems. It's a long standing Python tradition not to offer low level APIs that the platform doesn't have.
I meant the platform, not Python.
For CPython derivatives like PyMite, it can help to get things to compile. Perhaps rather than dropping it, we can just replace all the complex fallback code with code that triggers 'RuntimeError("Operation requires fstat, which is not available on this platform")'. Derivatives that support fstat-free platforms will have a clear place to put their custom code, but we get the simpler assumption of fstat always being available for the code paths we care about (and can reasonably test). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, 20 May 2013 01:09:19 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
On Mon, May 20, 2013 at 12:51 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 19 May 2013 07:47:14 -0700 (PDT) "Guido van Rossum" <gvanrossum@gmail.com> wrote:
Fake values would probably cause hard to debug problems. It's a long standing Python tradition not to offer low level APIs that the platform doesn't have.
I meant the platform, not Python.
For CPython derivatives like PyMite, it can help to get things to compile.
It's not a CPython derivative. Regards Antoine.
Perhaps rather than dropping it, we can just replace all the complex fallback code with code that triggers 'RuntimeError("Operation requires fstat, which is not available on this platform")'.
Derivatives that support fstat-free platforms will have a clear place to put their custom code, but we get the simpler assumption of fstat always being available for the code paths we care about (and can reasonably test).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (7)
-
Antoine Pitrou -
Antonio Cavallo -
Benjamin Peterson -
Charles-François Natali -
Guido van Rossum -
Nick Coghlan -
Skip Montanaro