Changes by David Watson bai...@users.sourceforge.net:
--
nosy: +baikie
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16263
___
___
Python-bugs
Changes by David Watson bai...@users.sourceforge.net:
--
nosy: +baikie
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20174
___
___
Python-bugs
Changes by David Watson bai...@users.sourceforge.net:
--
nosy: +baikie
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24725
___
___
Python-bugs
David Watson added the comment:
I've updated the ASCII/surrogateescape patches in line with
various changes to Python since I posted them.
return-ascii-surrogateescape-2015-06-25.diff incorporates the
ascii-surrogateescape and uname-surrogateescape patches, and
accept-ascii-surrogateescape-2015
David Watson added the comment:
Attaching patches for 3.5.
--
Added file:
http://bugs.python.org/file39309/enable-unterminated-3.5-2015-05-06.diff
Added file: http://bugs.python.org/file39310/fix-overrun-3.5-2015-05-06.diff
___
Python tracker rep
David Watson added the comment:
I've rebased the patches onto all the currently released
branches, but since there are now so many variations required,
I've bundled the pass-unterminated and test patches into a single
set (enable-unterminated-*), and the return-unterminated and
addrlen
Changes by David Watson bai...@users.sourceforge.net:
--
nosy: +baikie
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22397
___
___
Python-bugs
David Watson added the comment:
Sending multiple control messages at once isn't Linux-specific - the tests in
question passed on FreeBSD.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20669
David Watson added the comment:
In this test (and nearby ones), the receiver provides too little space to
receive the file descriptors that are sent, so that the control message has to
be truncated if it is to be received at all. The warning may indicate that the
cmsghdr struct received
David Watson added the comment:
Here are the alternative patches to allow more than two calls to
confstr(). One patch set just keeps reallocating the buffer
until it's big enough, while the other makes a limited number of
attempts (in this case 20) before raising RuntimeError
David Watson added the comment:
On Fri 5 Dec 2014, STINNER Victor wrote:
I added an assertion. Can we close this issue?
Well, if no one complains about the interpreter dying with
SIGABRT, that will suggest that the worries about OS bugs
creating infinite loops were unfounded :)
If you do want
David Watson added the comment:
On Mon 28 Apr 2014, Jim Jewett wrote:
pinging David Watson: What is the status? If I understand correctly, (and I
may well not), you have already opened other issues for parts of this, and
(only) the final patch is ready for patch (and hopefully) commit
David Watson added the comment:
On Sun 23 Mar 2014, David Watson wrote:
There actually isn't a test for the original locking issue, as
the tests all use the mailbox API, which doesn't provide a way to
turn off dot-locking. ...
On second thought, the underlying error doesn't actually have
David Watson added the comment:
On Tue 18 Mar 2014, A.M. Kuchling wrote:
I suggest we apply the fix for #1, and for #2 just discard and
update the ToC when we lock the mailbox, ignoring other
possible routes to corruption (so no detecting the problem and
raising an ExternalClash exception
New submission from David Watson:
In test_socket, the decorator on SendmsgStreamTests.testSendmsgDontWait still
checks for the old sys.platform value of linux2, with the result that the
test is always skipped, when in fact the test is for a Linux facility. Patch
attached for 3.3 and above
David Watson added the comment:
I opened the issue #20718 to track the FD pass failures.
But the failures in the current issue *all* involve FD passing :)
The Message too long errors are in tests where the ancillary data (in this
case file descriptors) is truncated, rather than the normal
David Watson added the comment:
On Fri 13 Dec 2013, Brett Cannon wrote:
Two things. First, I'm sorry David but my mind is not working fully enough at
the moment to see how msg_controllen is compared to cmsg_len_end without
relying on external value coming in through the parameters
New submission from David Watson bai...@users.sourceforge.net:
The function _multiprocessing.recvfd() calls recvmsg() and
expects to receive a file descriptor in an SCM_RIGHTS control
message, but doesn't check that such a control message is
actually present. So if the sender sends data without
Changes by David Watson bai...@users.sourceforge.net:
Added file: http://bugs.python.org/file23215/recvfd-skip-reduction-fix.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13022
David Watson bai...@users.sourceforge.net added the comment:
On Tue 20 Sep 2011, Charles-François Natali wrote:
I committed the patch to catch the ImportError in test_multiprocessing.
This should go in all branches, I think - see issue #13022
David Watson bai...@users.sourceforge.net added the comment:
On Sun 18 Sep 2011, Charles-François Natali wrote:
I had a look at this patch, and the FD passing looked OK, except
that calculating the buffer size with CMSG_SPACE() may allow more
than one file descriptor to be received
David Watson bai...@users.sourceforge.net added the comment:
I had a look at this patch, and the FD passing looked OK, except
that calculating the buffer size with CMSG_SPACE() may allow more
than one file descriptor to be received, with the extra one going
unnoticed - it should use CMSG_LEN
David Watson bai...@users.sourceforge.net added the comment:
For reference, the warnings are partially explained here:
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-825
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Warning-Options.html#index
Changes by David Watson bai...@users.sourceforge.net:
Added file: http://bugs.python.org/file23187/socket-aliasing-union-3.2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8623
Changes by David Watson bai...@users.sourceforge.net:
Added file: http://bugs.python.org/file23188/socket-aliasing-union-3.3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8623
Changes by David Watson bai...@users.sourceforge.net:
--
nosy: +baikie
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13001
___
___
Python-bugs
Changes by David Watson bai...@users.sourceforge.net:
--
nosy: +baikie
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12958
___
___
Python-bugs
David Watson bai...@users.sourceforge.net added the comment:
On Wed 24 Aug 2011, Charles-François Natali wrote:
I included this test deliberately, because msg_controllen may be
of signed type [...] POSIX allows socklen_t to be signed
http://pubs.opengroup.org/onlinepubs/007908799/xns
David Watson bai...@users.sourceforge.net added the comment:
On Thu 25 Aug 2011, Antoine Pitrou wrote:
Adding an explanation message to the NotImplementedError would be more
helpful. Otherwise, good catch.
OK, I've copied the messages from the ValueErrors the other
methods raise
New submission from David Watson bai...@users.sourceforge.net:
Changeset fd10d042b41d removed the wrappers on ssl.SSLSocket for
the new socket.send/recvmsg() methods (since I forgot to check
for the existence of the underlying methods - see issue #6560),
but this leaves SSLSocket with send
David Watson bai...@users.sourceforge.net added the comment:
On Tue 23 Aug 2011, Nick Coghlan wrote:
As you can see, I just pushed a change that removed the new
methods from SSLSocket objects. If anyone wants to step up with
a valid use case (not already covered by wrap_socket),
preferably
New submission from David Watson bai...@users.sourceforge.net:
Changeset 4736e172fa61 for issue #12810 removed the test
msg-msg_controllen 0 from socketmodule.c, where
msg_controllen happened to be unsigned on the reporter's system.
I included this test deliberately, because msg_controllen
David Watson bai...@users.sourceforge.net added the comment:
On Sun 12 Jun 2011, Charles-François Natali wrote:
The patches look good to me, except that instead of passing
(addrlen buflen) ? buflen : addrlen
as addrlen argument every time makesockaddr is called, I'd
prefer if this min
David Watson bai...@users.sourceforge.net added the comment:
On Mon 23 May 2011, Gergely Kálmán wrote:
It's been a while I had a look at that code. As far as I remember though
the code is fairly decent not
taking the missing unit tests into account. There are a few todos, and
also a pretty
David Watson bai...@users.sourceforge.net added the comment:
FWIW, you can do the same on a Linux box, i.e. setup the host name
and domain to some completely bogus values. And as David pointed out,
without also updating the /etc/hosts on the Linux, you always get the
resolver error
David Watson bai...@users.sourceforge.net added the comment:
On other platforms, I guess we'll just have to do some trial
and error to see what works and what not. E.g. on Linux it is
possible to set the hostname to a non-ASCII value, but then
the resolver returns an error, so it's not very
David Watson bai...@users.sourceforge.net added the comment:
I was looking at the MSDN pages linked to above, and these two
pages seemed to suggest that Unicode characters appearing in DNS
names represented UTF-8 sequences, and that Windows allowed such
non-ASCII byte sequences in the DNS
David Watson bai...@users.sourceforge.net added the comment:
Also, if GetComputerNameEx() only offers a choice of DNS names or
NetBIOS names, and both are byte-oriented underneath (that was my
reading of the Computer Names page), then presumably there
shouldn't be a problem with mapping
David Watson bai...@users.sourceforge.net added the comment:
In fact, I would think that non-ASCII bytes in a hostname most
probably indicated that a name resolution mechanism other than
the DNS was in use, and that the byte string should be passed
unaltered just as a typical C program
David Watson bai...@users.sourceforge.net added the comment:
The result from gethostname likely comes out of machine-local
configuration. It may have non-ASCII in it, which is then likely
encoded in the local encoding. When looking it up in DNS, IDNA
should be applied.
I would have thought
David Watson bai...@users.sourceforge.net added the comment:
As a further note: I think socket.gethostname() is a special case, since this
is just about a local setting (i.e. not related to DNS).
But the hostname *is* commonly intended to be looked up in the
DNS or whatever name resolution
David Watson bai...@users.sourceforge.net added the comment:
platform.system() fails with UnicodeEncodeError on systems that have their
computer name set to a name containing non-ascii characters. The
implementation of platform.system() uses at some point socket.gethostname() (
see http
David Watson bai...@users.sourceforge.net added the comment:
If I understood correctly, you don't want the value to be truncated if the
variable grows between the two calls to confstr(). Which behaviour would you
expect? A Python exception?
A return size larger than the buffer is *supposed
David Watson bai...@users.sourceforge.net added the comment:
With all the effort that went into the patch, I recommend to get it right: if
there is space for the \0, include it. If the string size is exactly 108, and
it's linux, write it unterminated. Else fail.
As for testing: we should
David Watson bai...@users.sourceforge.net added the comment:
I meant to say that FreeBSD provides the SUN_LEN macro, but it
turns out that Linux does as well, and its version behaves the
same as FreeBSD's. The FreeBSD man pages state that the
terminating null is not part of the address:
http
David Watson bai...@users.sourceforge.net added the comment:
Updated the patches for Python 3.2 - these are now simpler as
they do not support bytearray arguments, as these are no longer
used for filenames (the existing code does not support bytearrays
either).
I've put the docs and tests
Changes by David Watson bai...@users.sourceforge.net:
Added file:
http://bugs.python.org/file18851/af_unix-pep383-3.2-with-linux-unterminated.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8373
Changes by David Watson bai...@users.sourceforge.net:
Added file:
http://bugs.python.org/file18852/af_unix-pep383-3.2-without-linux-unterminated.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8373
David Watson bai...@users.sourceforge.net added the comment:
I've updated the PEP 383 patches at issue #8373 with separate
versions for if the linux-pass-unterminated patch is applied or
not.
If it's not essential to have unit tests for the overrun issue,
I'd suggest applying just the return
David Watson bai...@users.sourceforge.net added the comment:
One of the tests got broken by the removal of sys.setfilesystemencoding().
Replaced it.
--
Added file:
http://bugs.python.org/file18853/af_unix-pep383-docs-tests-3.2-2.diff
___
Python
David Watson bai...@users.sourceforge.net added the comment:
baikie, coming back to your original message: what precisely makes you
believe that sun_path does not need to be null-terminated on Linux?
That's the way I demonstrated the bug - the only way to bind to a
108-byte path is to pass
David Watson bai...@users.sourceforge.net added the comment:
baikie: why did the test pass for you?
The test passes (I assume) if linux-pass-unterminated.diff is applied. The
latter patch is only meant to exhibit the issue, though, not to be checked in.
No, I meant for linux-pass
New submission from David Watson bai...@users.sourceforge.net:
This test requires network access as it tries to resolve a domain name at
python.org. Patch attached.
--
components: Tests
files: idna-test-resource.diff
keywords: patch
messages: 115593
nosy: baikie
priority: normal
David Watson bai...@users.sourceforge.net added the comment:
OK, I still think this issue should be addressed, but here is a patch for the
part we agree on: that decoding should not return any Unicode characters except
ASCII.
--
Added file: http://bugs.python.org/file18674/decode
David Watson bai...@users.sourceforge.net added the comment:
The rest of the issue could also be straightforwardly addressed by adding bytes
versions of the name lookup APIs. Attaching a patch which does that (applies
on top of decode-strict-ascii.diff).
--
Added file: http
Changes by David Watson bai...@users.sourceforge.net:
Removed file: http://bugs.python.org/file18675/hostname-bytes-apis.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9377
David Watson bai...@users.sourceforge.net added the comment:
Oops, forgot to refresh the last change into that patch. This should fix it.
--
Added file: http://bugs.python.org/file18676/hostname-bytes-apis.diff
___
Python tracker rep
David Watson bai...@users.sourceforge.net added the comment:
I don't see how a name resolution API returning non-ASCII bytes
would indicate an error.
It's in violation of RFC 952 (slightly relaxed by RFC 1123).
That's bad if it's on the public Internet, but it's not an
error. The OS
David Watson bai...@users.sourceforge.net added the comment:
Is this still an issue on later versions of Python and/or FreeBSD?
Yes, there is still an issue. There is no longer a deadlock on
FreeBSD because the module been changed to use only lockf() and
dot-locking (on all platforms
David Watson bai...@users.sourceforge.net added the comment:
The surrogateescape mechanism is a very hackish approach, and
violates the principle that errors should never pass silently.
I don't see how a name resolution API returning non-ASCII bytes
would indicate an error. If the host table
David Watson bai...@users.sourceforge.net added the comment:
It's about environments, not applications
Still, my question remains. Is it a theoretical problem (i.e. one
of your imagination), or a real one (i.e. one you observed in real
life, without explicitly triggering it)? If real
David Watson bai...@users.sourceforge.net added the comment:
Come to think of it, I'm not sure if the patch is correct for
Windows, as PyUnicode_DecodeFSDefault() appears to do strict MBCS
decoding by default (similarly with PyUnicode_FSConverter() for
encoding). Can Windows return service
David Watson bai...@users.sourceforge.net added the comment:
Thanks for the patch. Committed as r84261.
I'm not sure what the point is of supporting IDNA in getnameinfo, so I have
removed that from the patch. If you think it's needed, please elaborate.
I don't see the point of it either
David Watson bai...@users.sourceforge.net added the comment:
Is this patch in response to an actual problem, or a theoretical problem?
If actual problem: what was the specific application, and what was the
specific host name?
It's about environments, not applications - the local network may
New submission from David Watson bai...@users.sourceforge.net:
The protocol and service/port number databases are typically
implemented as text files on Unix and can contain non-ASCII names
in any encoding (presumably for local services), but the socket
module tries to decode them as strict UTF
David Watson bai...@users.sourceforge.net added the comment:
I noticed that try-surrogateescape-first.diff missed out one of
the string references that needed to be changed to point to the
bytes object, and also used PyBytes_AS_STRING() in an unlocked
section. This version fixes these things
David Watson bai...@users.sourceforge.net added the comment:
Updated the socket module patch to include gethostbyaddr() - it
happens to accept hostnames and is used this way in the standard
library.
--
Added file: http://bugs.python.org/file18610/socket-idna.diff
New submission from David Watson bai...@users.sourceforge.net:
The statvfs() function still converts its argument with the s
format; the attached patch (for 3.2) fixes it to use
PyUnicode_FSConverter().
--
components: Extension Modules
files: statvfs-pep383-3.2.diff
keywords: patch
New submission from David Watson bai...@users.sourceforge.net:
The pathconf() function still converts its argument with the s
format; the attached pathconf-pep383-3.2.diff fixes it to use
PyUnicode_FSConverter() (in 3.2). Also attaching
pathconf-cleanup.diff to clean up the indentation, which
Changes by David Watson bai...@users.sourceforge.net:
Added file: http://bugs.python.org/file18580/pathconf-cleanup.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9645
New submission from David Watson bai...@users.sourceforge.net:
This came up in relation to issue #9579; there is some discussion
of it there. Basically, if os.confstr() has to call confstr()
twice because the buffer wasn't big enough the first time, the
existing code assumes the string
David Watson bai...@users.sourceforge.net added the comment:
I've opened a separate issue for the changing-length problem
(issue #9647; it affects 2.x as well). Here is a patch that
fixes the 255-byte issue only, and has similar results to the 2.x
code if the value changes length between calls
David Watson bai...@users.sourceforge.net added the comment:
I wrote this patch to make confstr() return bytes (with code
similar to 2.x), and document the change in Porting to Python
3.2 and elsewhere, but it then occurred to me that you might
have been talking about making a separate bytes API
New submission from David Watson bai...@users.sourceforge.net:
These functions each return the path to a terminal, so they should use
PyUnicode_DecodeFSDefault(). Patch attached.
--
components: Extension Modules
files: ttyname-ctermid-pep383.diff
keywords: patch
messages: 113920
nosy
New submission from David Watson bai...@users.sourceforge.net:
The pwd module decodes usernames using PyUnicode_DecodeFSDefault(), so
initgroups() should use PyUnicode_FSConverter() for the username. Patch
attached.
--
components: Extension Modules
files: initgroups-pep383.diff
New submission from David Watson bai...@users.sourceforge.net:
The pwd module decodes usernames with PyUnicode_DecodeFSDefault(), and the
LOGNAME environment variable (suggested as an alternative to getlogin()) is
decoded the same way. Attaching a patch to use PyUnicode_DecodeFSDefault
David Watson bai...@users.sourceforge.net added the comment:
CS_PATH is hardcoded to /bin:/usr/bin in the GNU libc for UNIX. Do you know
another key for which the value can be controled by the user (or the system
administrator)?
No, not a specific example, but CS_PATH could conceivably
David Watson bai...@users.sourceforge.net added the comment:
I just fear that the loop is endless. Imagine the worst case: confstr()
returns a counter (n, n+1, n+2, ...). In 64 bits, it can be long.
The returned length is supposed to be determined by the length of
the variable
David Watson bai...@users.sourceforge.net added the comment:
The CS_PATH variable is a colon-separated list of directories (the value for
the PATH environment variable that finds all standard utilities), so the file
system encoding is certainly correct there.
I don't see any reference
David Watson bai...@users.sourceforge.net added the comment:
I don't see why confstr() values shouldn't change. sysconf() values can change
between calls, IIRC. Implementations can also define their own confstr
variables - they don't have to stick to the POSIX stuff.
And using a loop means
New submission from David Watson bai...@users.sourceforge.net:
It may be hard to find a configuration string this long, but you
can see the problem if you apply the attached
confstr-reduce-bufsize.diff to reduce the size of the local array
buffer that posix_confstr() uses. With it applied
Changes by David Watson bai...@users.sourceforge.net:
Added file: http://bugs.python.org/file18487/confstr-long-result.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9579
New submission from David Watson bai...@users.sourceforge.net:
The attached patch applies on top of the patch from issue #9579 to
make it use PyUnicode_DecodeFSDefaultAndSize(). (You could use
it in the existing code, but until that issue is fixed, there is
sometimes nothing to decode
David Watson bai...@users.sourceforge.net added the comment:
I'm not quite sure what you mean, but the man page for FreeBSD 5.3 specifies
EPERM for an unprivileged user and EINVAL for an attempt to create something
other than a device node. POSIX requires creating a FIFO to work for any user
David Watson bai...@users.sourceforge.net added the comment:
OK, these patches work on FreeBSD 5.3 (root and non-root) if you want to check
the errno. I don't know what other systems might return though. I did also
find that the 2.x tests were failing on cleanup because the test class used
Changes by David Watson bai...@users.sourceforge.net:
Added file: http://bugs.python.org/file18490/add-errno-check-2.x.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9569
Changes by David Watson bai...@users.sourceforge.net:
Added file: http://bugs.python.org/file18491/add-errno-check-3.x.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9569
New submission from David Watson bai...@users.sourceforge.net:
Attaching simple tests for these functions, which aren't currently tested.
--
components: Extension Modules
files: test-mknod-mkfifo-3.x.diff
keywords: patch
messages: 113609
nosy: baikie
priority: normal
severity: normal
Changes by David Watson bai...@users.sourceforge.net:
Added file: http://bugs.python.org/file18479/test-mknod-mkfifo-2.x.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9569
New submission from David Watson bai...@users.sourceforge.net:
These functions still use the s format for their arguments; the attached
patch fixes them to use PyUnicode_FSConverter() in 3.2. Some simple tests for
these functions (not for PEP 383 behaviour) are at issue #9569
David Watson bai...@users.sourceforge.net added the comment:
OK, here are new versions of the original patches.
I've tweaked the docs to make clear that ASCII-compatible
encodings actually *are* ASCII, and point to an explanation as
soon as they're mentioned.
You're right
Changes by David Watson bai...@users.sourceforge.net:
Added file: http://bugs.python.org/file18273/try-surrogateescape-first-2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9377
David Watson bai...@users.sourceforge.net added the comment:
Leaving IDNA ASCII-compatible encodings in ASCII form is just preserving the
existing behaviour (not doing IDNA decoding). See
http://tools.ietf.org/html/rfc3490
and the docs for codecs - encodings.idna (xn--lzg in the example
David Watson bai...@users.sourceforge.net added the comment:
You're having a bad day at the office :) Just use patch -p1.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4926
New submission from David Watson bai...@users.sourceforge.net:
The functions in the socket module which return host/domain
names, such as gethostbyaddr() and getnameinfo(), are wrappers
around byte-oriented interfaces but return Unicode strings in
3.x, and have not been updated to deal
Changes by David Watson bai...@users.sourceforge.net:
Added file: http://bugs.python.org/file18196/try-surrogateescape-first.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9377
David Watson bai...@users.sourceforge.net added the comment:
Unit tests were in the patch! However, none of the patches
applied any more, so I've updated them and also improved the
tests a bit. Again, I haven't tried them on Windows.
Unsetting a nonexistent variable isn't supposed
Changes by David Watson bai...@users.sourceforge.net:
Added file: http://bugs.python.org/file18186/putenv-empty-2.x.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4926
Changes by David Watson bai...@users.sourceforge.net:
Added file: http://bugs.python.org/file18187/putenv-equals-3.x.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4926
Changes by David Watson bai...@users.sourceforge.net:
Added file: http://bugs.python.org/file18188/putenv-empty-3.x.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4926
1 - 100 of 139 matches
Mail list logo
