[issue28503] [Patch] '_crypt' module: fix implicit declaration of crypt(), use crypt_r() where available
Ed Schouten <e...@nuxi.nl> added the comment: Ah, you folks switched to Git + Github in the mean time. Nice! I've just sent this pull request: https://github.com/python/cpython/pull/4691 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28503] [Patch] '_crypt' module: fix implicit declaration of crypt(), use crypt_r() where available
Ed Schouten <e...@nuxi.nl> added the comment: Having looked at various implementations of crypt() and crypt_r(), I can't think of a reason why there would be any significant difference in performance. On systems like FreeBSD, crypt() is just a simple wrapper around crypt_r(): https://svnweb.freebsd.org/base/head/lib/libcrypt/crypt.c?view=markup#l134 If there would be any difference in performance, it would also be astronomically small compared to the computation time spent by the cryptographic hash functions themselves. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Ed Schouten added the comment: Looks good to me! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Ed Schouten added the comment: CloudABI uses a structure type, which is exactly why I filed this bug report. Instead of speculating about what kind of type existing implementations use, please just focus on the specification to which we're trying to stick: POSIX. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html "All of the types shall be defined as arithmetic types of an appropriate length, with the following exceptions: [...] pthread_key_t [...]" -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Ed Schouten added the comment: It can also be a structure or a union. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28619] [Patch] Stop using inet_ntoa() when possible.
New submission from Ed Schouten: Modern C code should use inet_ntop()/inet_pton() as opposed to inet_addr()/inet_aton()/inet_ntoa(). Though the former functions may typically act as drop-in replacements for the latter, the inet_addr()/inet_aton() functions still have the advantage over inet_pton() of allowing you to parse IPv4 addresses that don't use the dotted quad notation (e.g. '0x0a01' for 10.0.0.1). There is no difference between inet_ntop() and inet_ntoa(), as they both always print the address in dotted quad form. inet_ntop() does have the advantage of being thread-safe, as inet_ntoa() uses internal storage for the return value. In other words, we'd better not use inet_ntoa() at all. Attached is a patch for Python's socketmodule that changes the existing call to inet_ntoa() to use inet_ntop() when available. This has the advantage of fixing the build on CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), which intentionally omits any APIs that are thread-unsafe. -- components: Extension Modules files: patch-inet_ntoa.diff keywords: patch messages: 280109 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Stop using inet_ntoa() when possible. versions: Python 3.7 Added file: http://bugs.python.org/file45364/patch-inet_ntoa.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28503] [Patch] '_crypt' module: fix implicit declaration of crypt(), use crypt_r() where available
New submission from Ed Schouten: The '_crypt' module provides a binding to the C crypt(3) function. It is used by the crypt.crypt() function. Looking at the C code, there are a couple of things we can improve: - Because crypt() only depends on primitive C types, we currently get away with calling it without it being declared. Ensure that we include , which is the POSIX header file declaring this. - The disadvantage of crypt() is that it's thread-unsafe. Systems like Linux and recent versions of FreeBSD nowadays provide crypt_r() as a replacement. This function allows you to pass in a 'crypt_data' object that will hold the resulting string for you. Extend the code to use this function when available. This patch is actually needed to make this module build on CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). CloudABI's C library doesn't provide any thread-unsafe functions, meaning that crypt_r() is the only way you can crypt passwords. -- components: Extension Modules files: crypt.diff keywords: patch messages: 279186 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] '_crypt' module: fix implicit declaration of crypt(), use crypt_r() where available versions: Python 3.6 Added file: http://bugs.python.org/file45185/crypt.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28502] [Patch] Make os.chdir() optional
New submission from Ed Schouten: CloudABI is a POSIX-like strongly sandboxed runtime environment, for which we got Python to work (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). Patches for this are slowly being upstreamed. CloudABI uses a capability-based security model, similar to Capsicum (https://www.cl.cam.ac.uk/research/security/capsicum/). With this model, the file system can only be accessed by using file descriptors to directories. Files inside of them can be used by using openat() (in Python: os.open(dirfd=...). This means that there is no need to provide support for process working directories. chdir() is therefore entirely absent. It looks like chdir() is only used by Python in its posixmodule. The attached patch adds a new Autoconf check and adds the proper #if logic around its implementation. Changes to the Autoconf/Automake files are not provided by this patch, as my versions of these tools generate files containing unnecessary changes. -- components: Extension Modules files: chdir-optional.diff keywords: patch messages: 279183 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make os.chdir() optional versions: Python 3.6 Added file: http://bugs.python.org/file45184/chdir-optional.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28501] [Patch] Make os.umask() optional
New submission from Ed Schouten: CloudABI is a POSIX-like strongly sandboxed runtime environment, for which we got Python to work (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). Patches for this are slowly being upstreamed. As CloudABI uses a capability-based security model as opposed to a discretionary access control system, there is no support for UNIX credentials and permissions. This means that umask() is also absent. It looks like umask() is only used by Python in its posixmodule. The attached patch adds a new Autoconf check and adds the proper #if logic around its implementation. Changes to the Autoconf/Automake files are not provided by this patch, as my versions of these tools generate files containing unnecessary changes. -- components: Extension Modules files: umask-optional.diff keywords: patch messages: 279182 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make os.umask() optional versions: Python 3.6 Added file: http://bugs.python.org/file45183/umask-optional.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27701] [posixmodule] [Refactoring patch] Simply call into *at() functions unconditionally when present
Ed Schouten added the comment: Attached is an updated version of the patch that applies cleanly against Python 3.6.0b2. -- Added file: http://bugs.python.org/file45181/27701.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28148] [Patch] Also stop using localtime() in timemodule
Ed Schouten added the comment: I've been brainwashed by https://google.github.io/styleguide/cppguide.html#Function_Parameter_Ordering over the last couple of years, which is why I thought `localtime()/localtime_r()`'s way of ordering the arguments made most sense here. ;-) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28148] [Patch] Also stop using localtime() in timemodule
Ed Schouten added the comment: Does this patch look all right to you? -- Added file: http://bugs.python.org/file44667/patch-pytime-localtime-gmtime ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28148] [Patch] Also stop using localtime() in timemodule
Ed Schouten added the comment: As a person who keeps a close eye on the Austin Group mailing lists (i.e., 'the POSIX working group'), my guess is that it's very unlikely that POSIX will ever add those *_s() extensions. Here's a discussion on Reddit that actually captures all of the arguments pretty well: https://www.reddit.com/r/C_Programming/comments/3ivi77/eli5_why_does_glibc_still_not_support_the/ That said, any API will do. The localtime_r() function has the disadvantage that the return value is a bit odd: can it return any other tm structure than the one provided? localtime_s() is a bit weird in that its input argument is stored after the output argument. Both functions also unnecessarily pass the time_t by reference. Maybe we can just pick a prototype that's as Pythonesque as possible that also fixes these shortcomings. Any thoughts? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28148] [Patch] Also stop using localtime() in timemodule
Ed Schouten added the comment: Hi Alexander, I'm absolutely no expert when it comes to the Python codebase, so I've got a question. If we're going to movein this to Include/pytime.h, we should likely introduce full wrappers that have a name starting with _PyTime_, right? This header seem to be part of the installation, so we should likely not declare any commonly used symbols there. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28156] [Patch] posixmodule: Make the presence of os.getpid() optional
New submission from Ed Schouten: CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) does not provide getpid(). Though this may sound quite silly at first, there is quite a good reason for this. One of the things that CloudABI wants to achieve is making large scale (cluster/cloud) computing easier. In such an environment there is rarely a need for having machine-local unique process identifiers. They have to be globally unique and preferably not recycled. POSIX requires that pid_t is a signed integer that must have a positive value. Most C compilers only provide full support for integers up to 64 bits in size. This means that CloudABI could only provide 63-bit process identifiers, which is far smaller than, say, a UUID. For this reason we've decided to omit getpid() altogether. Attached is a patch that makes use of the already existing HAVE_GETPID definition in pyconfig.h to disable the os.getpid() function that is part of the posixmodule. -- components: Extension Modules files: patch-no-getpid messages: 276470 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] posixmodule: Make the presence of os.getpid() optional versions: Python 3.6 Added file: http://bugs.python.org/file44664/patch-no-getpid ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28156> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28148] [Patch] Also stop using localtime() in timemodule
Changes by Ed Schouten <e...@nuxi.nl>: -- title: Also stop using localtime() in timemodule -> [Patch] Also stop using localtime() in timemodule ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28153] [Patch] selectmodule: Make kqueue()'s event filters optional
New submission from Ed Schouten: Just like the BSDs and Mac OS X, CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) provides support for kqueue(). Its implementation, however, is far more limited. It can only be used for polling on descriptors (EVFILT_READ/EVFILT_WRITE) and waiting on timers (EVFILT_TIMER). The existing selectmodule already allows some filters to be present optionally (e.g., EVFILT_NETDEV). The attached patch extends this work by only defining the filter and corresponding filter flags when available. I've also added guards around EV_SYSFLAGS and EV_FLAG1. EV_SYSFLAGS is a flag that's typically only used by the kernel to trim off flags that are only used internally. EV_FLAG1 is an example of such a flag, which seems to be used by FreeBSD to mark incoming AIO events as validated. I would even go as far as to remove these two flags from the module entirely, but let's not take the risk. -- components: Extension Modules files: patch-kqueue-EVFILT messages: 276459 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] selectmodule: Make kqueue()'s event filters optional versions: Python 3.6 Added file: http://bugs.python.org/file44662/patch-kqueue-EVFILT ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28148] Also stop using localtime() in timemodule
New submission from Ed Schouten: In issue 28067, we changed _datetimemodule to stop using localtime() and gmtime(), which is nice. I actually needed such a change for CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) which does not provide the thread-unsafe variants. Only localtime_r() and gmtime_r() are provided. If we're starting to make use of these functions, let's complete this by also changing timemodule to use them. I've attached a patch. Maybe it now makes sense to move the Windows wrappers to some header file, so that they can be shared between both modules. What would be the right location for this? -- components: Extension Modules files: patch-no-gmtime-localtime messages: 276421 nosy: EdSchouten priority: normal severity: normal status: open title: Also stop using localtime() in timemodule versions: Python 3.6 Added file: http://bugs.python.org/file44660/patch-no-gmtime-localtime ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28081] [Patch] timemodule: Complete Autoconf bits for clock_*() functions: make clock_getres() and clock_settime() optional
New submission from Ed Schouten: Our Autoconf bits already test for the presence of the POSIX 2008 clock_gettime() and clock_getres() functions, which is nice. Still, I'd like to make two improvements there: 1. In timemodule.c, properly guard the use of clock_getres() bits with HAVE_CLOCK_GETRES instead of using HAVE_CLOCK_GETTIME. There don't seem to be any shared functions/structures/etc., so we can safely decouple them. 2. For consistency, also add Autoconf bits for clock_settime(). In timemodule.c, use HAVE_CLOCK_SETTIME as a guard. The reason why I'm sending in this patch is because CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) does provide clock_gettime() and clock_getres(), but not clock_settime(). The reason for this is that CloudABI is meant for running unprivileged/sandboxed code. There is no need to provide an API for adjusting system-wide clocks. Do note that this patch does not contain any changes to Autoconf generated files. -- components: Extension Modules files: patch-clock_settime messages: 275827 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] timemodule: Complete Autoconf bits for clock_*() functions: make clock_getres() and clock_settime() optional Added file: http://bugs.python.org/file44563/patch-clock_settime ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27701] [posixmodule] [Refactoring patch] Simply call into *at() functions unconditionally when present
Ed Schouten added the comment: Hmmm... Taking a second look at my patch: I still think it's conceptually a good idea to pursue this, but I think it may be wiser to first focus on the bits that are strictly necessary from my side. The patch that I've posted previously has the disadvantage that it's hard to grasp what belongs to gether. Attached is a trimmed down version of my original patch that only focuses on patching up the os_*_impl()s to use the *at() functions exclusively if possible. Hopefully this change should be fairly easy to understand. Any thoughts? -- Added file: http://bugs.python.org/file44561/patch-issue27701 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28066] [Patch] Fix the ability to cross compile Python when doing a rebuild of importlib.h
Ed Schouten added the comment: It does. I can now cross build Python for CloudABI by copying importlib.h and importlib_external.h from the native build directory to the target build directory. Thanks! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28066] [Patch] Fix the ability to cross compile Python when doing a rebuild of importlib.h
Ed Schouten added the comment: The nice thing is that in our case, the importlib changes are already compatible with the native build. So yes, we can reuse the frozen module from the native build. :-) Ah, yes. Issue 27641 already prevents that it's cross compiled. This patch was written prior to that and simply rebased. Still, one problem remains: our strategy for creating importlib.h and importlib_external.h doesn't take out-of-tree builds into account. Even if we regenerate it, frozen.c won't pick it up because its directory is not part of the compiler search path. Attached is a patch that makes us write the results of _freeze_importlib into $(srcdir)/Python/importlib*.h instead, so that even with an out-of-tree build, we actually update the header files used by frozen.c. -- Added file: http://bugs.python.org/file44545/patch-freeze-importlib ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28066] [Patch] Fix the ability to cross compile Python when doing a rebuild of importlib.h
New submission from Ed Schouten: For CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) we're providing packages containing a precompiled copy of Python. As we had to make some changes to importlib (namely to deal with directory file descriptors), we have to do a rebuild of importlib.h during the cross compilation process, using Programs/_freeze_importlib. We've run into a couple of issues that require us to patch up the build system to make this work: - First of all, Programs/_freeze_importlib is built using the compiler for the target. There is no way to override this. The OpenWRT folks have also run into this issue and have patched up the Makefile to add a $FREEZE_IMPORTLIB that allows you to use a different executable: https://github.com/openwrt/packages/blob/master/lang/python3/patches/013-make-freeze-import-lib-into-an-override-able-var.patch This patch is almost correct; it doesn't prevent _freeze_importlib from being built, which is needed in our case as it doesn't build cleanly on CloudABI. - Second, if an out-of-tree build is performed, we need to make sure that Python/frozen.c imports the right copy of importlib.h. We must add -IPython to the compiler flags to realise. Attached is a patch that contains the modifications that we've made to Makefile.pre.in to make cross compilation work for us. -- components: Interpreter Core files: patch-freeze-importlib messages: 275674 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Fix the ability to cross compile Python when doing a rebuild of importlib.h versions: Python 3.7 Added file: http://bugs.python.org/file44536/patch-freeze-importlib ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28058] [Patch] Don't use st_uid and st_gid on CloudABI
New submission from Ed Schouten: CloudABI is a UNIX-like runtime environment that uses a capability-based security model. As there is no support for traditional UNIX credentials (uid_t, gid_t), its struct stat doesn't provide st_uid and st_gid. Python can already deal with the absence of these fields, as it also needs to treat Windows similarly. Attached is a patch that simply adds CloudABI to the relevant '#if' in posixmodule.c. -- components: Extension Modules files: patch-st_uid-st_gid messages: 275591 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Don't use st_uid and st_gid on CloudABI versions: Python 3.7 Added file: http://bugs.python.org/file44525/patch-st_uid-st_gid ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28058> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27654] [Patch] Use arc4random_buf() on CloudABI
Ed Schouten added the comment: Sure thing! Attached is an updated patch. -- Added file: http://bugs.python.org/file44434/patch-arc4random ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Ed Schouten added the comment: I think that PEP 11 also doesn't rule out changes in this area. For example, consider the paragraph starting with the sentence "This policy does not disqualify supporting other platforms indirectly. [...]" Attached is a patch that accomplishes the same with a constant running time for operations on keys by using an array. Allocation of new keys runs in expected constant time by using a randomised allocation pattern. If we're not big fans of using randomised access, changing this to a linear scan would already be an improvement: keys are only allocated infrequently, but hopefully accessed quite often. -- Added file: http://bugs.python.org/file44303/key-constant-time.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27764] [Patch] Complete bits necessary for making fcntl's file locking optional
New submission from Ed Schouten: Python's fcntl module already provides some support for making support for file locking optional. For example, constants like F_SETFL are only defined if present. Unfortunately, the accompanying functions 'flock()' and 'lockf()' are present unconditionally. CloudABI, a sandboxed runtime environment for UNIX (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), doesn't implement these ways of doing file locking, for the reason that these operations do not fit nicely within its process model. These locks are per-process; not per-descriptor. This means that processes cannot safely be composed or decomposed. Attached is a relatively small patch to make flock() and lockf() optional, only compiling them when the necessary APIs are present. The LOCK_* constants are now also defined optionally. -- components: Extension Modules files: patch-no-flock.txt messages: 272692 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Complete bits necessary for making fcntl's file locking optional versions: Python 3.6 Added file: http://bugs.python.org/file44105/patch-no-flock.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27702] [Patch] Only use SOCK_RAW when defined
New submission from Ed Schouten: POSIX only requires socket types SOCK_STREAM, SOCK_DGRAM and SOCK_SEQPACKET to be present. SOCK_RAW is optional, as it is placed between [RS] tags in the specification: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html It looks like Python's socketmodule.c does try to use it unconditionally. Comply to POSIX by only exposing it optionally, just like we do for some of the other socket types (SOCK_RDM, etc). -- components: Extension Modules files: sock_raw.diff keywords: patch messages: 272117 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Only use SOCK_RAW when defined versions: Python 3.6 Added file: http://bugs.python.org/file44034/sock_raw.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27702> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27701] [posixmodule] [Refactoring patch] Simply call into *at() functions unconditionally when present
New submission from Ed Schouten: CloudABI is a sandboxed UNIX-like environment (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). As it implements a security framework similar to FreeBSD's Capsicum, file system access is only permitted by using POSIX-2008-style directory file descriptors. To explain it simply, the API is as follows: - Take POSIX 2008 - Remove all the non-*at() functions - Remove AT_FDCWD It would be nice if Python could support CloudABI out of the box, but in my opinion this should be done in a way that's as unintrusive as possible. We shouldn't make a mess out of Python, just to support CloudABI. I've been looking at Python's posixmodule and I think there's some low-hanging fruit. We can make changes that significantly reduce the size of our patchset for CloudABI, while also making the existing code easier to understand: - When support for *at() functions was added, they didn't replace the calls to the non-*at() functions. The non-*at() functions are still invoked when dir_fd == AT_FDCWD. This can be changed to invoke the *at() functions unconditionally. The advantage of this approach is that AT_FDCWD then only needs to be used in dir_fd_converter() and a small number of other places. It also means that the code builds on systems that don't prove the non-*at() functions. - The *_DIR_FD_CONVERTER macros aren't used in a small number of places, requiring us to do additional checks against AT_FDCWD in os_*_impl(). In os.link(), os.rename() and os.replace(), we call into dir_fd_converter() unconditionally, only to let the respective implementation functions perform additional checks. If dir_fd_unavailable() would be used instead, the implementations would be cleaner. The attached patch does this refactoring, also making some minor cleanups along the way. -- components: Extension Modules files: posixmodule-refactoring.diff keywords: patch messages: 272114 nosy: EdSchouten priority: normal severity: normal status: open title: [posixmodule] [Refactoring patch] Simply call into *at() functions unconditionally when present versions: Python 3.6 Added file: http://bugs.python.org/file44033/posixmodule-refactoring.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27655] [Patch] Don't require presence of POLLPRI
Ed Schouten added the comment: Believe it our not, dealing with the absence of those system calls is more contained than you'd think. What is pretty nice about Python is that (almost) all of the file system operations are performed through posixmodule.c. Most of the changes in that area are thus made to that source file (and configure.ac). Furthermore, it looks like posixmodule.c can be simplified a lot. What makes it so incredibly complex right now is that it wants to fall back to non-at() operations in case no directory file descriptor is provided, which is not needed. If that would get fixed, we'd kill two birds with one stone: the code would get a lot simpler, while almost automatically gaining support for CloudABI. But let's save this discussion for a separate thread. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27655] [Patch] Don't require presence of POLLPRI
Ed Schouten added the comment: That's a very good question. One of the goals of CloudABI's C library is to leave out definitions for things that are known not to work in the environment. For example, our doesn't contain open(), as with our security model (Capsicum), there is nothing meaningful that this function could do anyway. Though this may seem annoying, this actually saves us a lot of time by allowing us to very easily detect software that will break. The same reasoning applies to POLLPRI here. We could in theory implement it as an event that simply never triggers, but then it would be nothing more than a convoluted way of letting your program get stuck indefinitely. Also worth taking into account here: I understand why the selectmodule provides support for POLLPRI. It simply wants to expose the entire poll() interface into Python code, but I'd argue that we'd have to look at the bigger picture. Support for out-of-band data in Python is incomplete anyway. The socket module also doesn't provide a binding for sockatmark(). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27656] [Patch] Make presence of SCHED_* optional
New submission from Ed Schouten: The SCHED_* constants that are part of POSIX's are all optional: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sched.h.html Python already declares the SCHED_SPORADIC constant as part of the POSIX module optionally, depending on whether it is present in C, but doesn't do this for the other SCHED_* constants. This is problematic for CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), which doesn't support any scheduler interaction at all. Attached is a patch to only define these if present. -- components: Extension Modules files: sched.diff keywords: patch messages: 271697 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make presence of SCHED_* optional versions: Python 3.6 Added file: http://bugs.python.org/file43952/sched.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27655] [Patch] Don't require presence of POLLPRI
New submission from Ed Schouten: RFC 6093 states that applications "SHOULD NOT" make use of TCP's out-of-band data. For this reason, CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) does not provide support for it. This means that its poll() function does provide support for POLLIN and POLLOUT, but not for POLLPRI. Attached is a patch that patches up the selectmodule to not define POLLPRI in case the host environment does not support it. -- components: Extension Modules files: pollpri.diff keywords: patch messages: 271689 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Don't require presence of POLLPRI versions: Python 3.6 Added file: http://bugs.python.org/file43951/pollpri.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27652] Make use of non-standard error number ESHUTDOWN optional
Ed Schouten added the comment: I've filed the contributor form earlier today, but I suspect it still takes some time to get processed. The reason why the Mercurial headers were missing from the patch was because I generated this patch from the Python 3.6.0a3 source tarball. I'll make sure to switch over to the Mercurial sources from now on. Thanks for the quick response! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27654] [Patch] Use arc4random_buf() on CloudABI
New submission from Ed Schouten: While porting Python over to CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we stumbled upon a small issue that caused the build to fail. As CloudABI is a sandboxed runtime environment, there is no support for accessing the global filesystem namespace. This means that dev_urandom_noraise()/dev_urandom_python() are not capable of accessing /dev/urandom. The attached change extends these functions to use CloudABI's arc4random_buf() function, which is also present on a lot of other operating systems (the BSDs, Mac OS X, etc). I'm not enabling the use of arc4random_buf() on those operating systems yet, as that should likely be decided by the people responsible for those ports. Alternatively, if we do think arc4random_buf() should be used on all operating systems that support it, we can extend Autoconf to test for its presence. Be sure to let me know and I'll update the patch accordingly. -- components: Interpreter Core files: patch-arc4random messages: 271680 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Use arc4random_buf() on CloudABI versions: Python 3.6 Added file: http://bugs.python.org/file43950/patch-arc4random ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27653] [Patch] Also disable the use of on CloudABI
New submission from Ed Schouten: While porting Python over to CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we stumbled upon a small issue that caused the build to fail. As CloudABI is a sandboxed environment, there currently isn't any support for modifying low-level network properties, such as TCP socket attributes. For this reason is missing, just like on a couple of other platforms (Symbian, Cygwin, etc). The attached patch extends the current '#ifndef' to also take CloudABI into consideration. -- components: Extension Modules files: patch-no-netinet-tcp_h messages: 271679 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Also disable the use of on CloudABI versions: Python 3.6 Added file: http://bugs.python.org/file43949/patch-no-netinet-tcp_h ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27653> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27652] [Patch] Make use of non-standard error number ESHUTDOWN optional
New submission from Ed Schouten: While porting Python over to CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we noticed that the core Python code maps ESHUTDOWN over to BrokenPipeError. This is fine, except for the fact that ESHUTDOWN is used unconditionally. It's not part of POSIX. Attached is a patch to make its use optional. -- components: Interpreter Core files: patch-no-eshutdown messages: 271678 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make use of non-standard error number ESHUTDOWN optional versions: Python 3.6 Added file: http://bugs.python.org/file43948/patch-no-eshutdown ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
New submission from Ed Schouten: While trying to port Python over to a new platform (CloudABI), I noticed a couple of compiler errors in PyThread_create_key(), PyThread_delete_key(), PyThread_delete_key_value() and PyThread_set_key_value() caused by fact that pthread_key_t is converted to an integer (and vice versa) POSIX doesn't seem to require that pthread_key_t is an integer or any other arithmetic type: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html Old revisions of the standard did require pthread_t to be an arithmetic type, but this requirement was dropped later on. In my opinion we should strongly consider changing the API, so that we can treat the key created by pthread_key_create() or returned by TlsAlloc() as an opaque type. -- components: Interpreter Core messages: 254846 nosy: EdSchouten priority: normal severity: normal status: open title: PyThread assumes pthread_key_t is an integer, which is against POSIX versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
