Changes by David Watson :
--
nosy: +baikie
___
Python tracker
<http://bugs.python.org/issue16263>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by David Watson :
--
nosy: +baikie
___
Python tracker
<http://bugs.python.org/issue24725>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by David Watson :
--
nosy: +baikie
___
Python tracker
<http://bugs.python.org/issue20174>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
<h
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 a
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
Changes by David Watson :
--
nosy: +baikie
___
Python tracker
<http://bugs.python.org/issue22397>
___
___
Python-bugs-list mailing list
Unsubscribe:
David Watson added the comment:
Sending multiple control messages at once isn't Linux-specific - the tests in
question passed on FreeBSD.
--
___
Python tracker
<http://bugs.python.org/is
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 Runtime
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
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 hopefull
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 do
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 E
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 tru
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
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 par
David Watson added the comment:
Looking again at cmsg_min_space(), I see that it already returns
false when msg_controllen is less than cmsg_len_end, so you could
do a (signed) comparison against that, rather than 0. Patch
attached.
--
Added file: http://bugs.python.org/file32992
David Watson 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.
--
___
Python tracker
&l
Changes by David Watson :
Added file: http://bugs.python.org/file23215/recvfd-skip-reduction-fix.diff
___
Python tracker
<http://bugs.python.org/issue13022>
___
___
Pytho
New submission from David Watson :
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 an
accompanying
David Watson 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, with t
Changes by David Watson :
--
nosy: +baikie
___
Python tracker
<http://bugs.python.org/issue13001>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by David Watson :
Added file: http://bugs.python.org/file23188/socket-aliasing-union-3.3.diff
___
Python tracker
<http://bugs.python.org/issue8623>
___
___
Pytho
Changes by David Watson :
Added file: http://bugs.python.org/file23187/socket-aliasing-union-3.2.diff
___
Python tracker
<http://bugs.python.org/issue8623>
___
___
Pytho
David Watson 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-Wstrict_002daliasing-337
I get
David Watson 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() instead (the existing C
Changes by David Watson :
--
nosy: +baikie
___
Python tracker
<http://bugs.python.org/issue12958>
___
___
Python-bugs-list mailing list
Unsubscribe:
David Watson 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.
--
Added
David Watson 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/xn
New submission from David Watson :
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 m
David Watson 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 with a patch
New submission from David Watson :
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/recvmsg() methods inherited
David Watson 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
David Watson 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 bad bu
David Watson 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 with hostname -f
David Watson 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
David Watson 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
David Watson 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 by default:
http
David Watson 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 pro
David Watson 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 that
David Watson 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 mechanisms are used l
David Watson 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://www.pastea
David Watson 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* to ind
David Watson 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://www.freebsd.org/cgi/ma
David Watson 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 th
David Watson 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 tracker
<h
David Watson 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-untermina
Changes by David Watson :
Added file:
http://bugs.python.org/file18852/af_unix-pep383-3.2-without-linux-unterminated.diff
___
Python tracker
<http://bugs.python.org/issue8
Changes by David Watson :
Added file:
http://bugs.python.org/file18851/af_unix-pep383-3.2-with-linux-unterminated.diff
___
Python tracker
<http://bugs.python.org/issue8
David Watson 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 in one patch, and made sep
David Watson 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 it without null
David Watson 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-untermin
New submission from David Watson :
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
severity: normal
status: open
David Watson 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
<http://bugs.python.org/issue9
Changes by David Watson :
Removed file: http://bugs.python.org/file18675/hostname-bytes-apis.diff
___
Python tracker
<http://bugs.python.org/issue9377>
___
___
Python-bug
David Watson 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://bugs.python.org/file18675/hostname
David Watson 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-strict-ascii.diff
David Watson 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
David Watson 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 contains a non
David Watson 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), but the issue is now about
David Watson 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 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 ma
David Watson 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 eithe
David Watson 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 names that won't d
David Watson 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
___
Python
David Watson 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 by taking the generally
safer
New submission from David Watson :
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-8. In particular
David Watson 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 like
os.enviro
David Watson 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 (except that it
could
New submission from David Watson :
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 is the same length that t
Changes by David Watson :
Added file: http://bugs.python.org/file18580/pathconf-cleanup.diff
___
Python tracker
<http://bugs.python.org/issue9645>
___
___
Python-bug
New submission from David Watson :
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
otherwise make
New submission from David Watson :
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
messages: 114392
no
David Watson 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, not the length of t
David Watson 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
New submission from David Watson :
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() in
getlogin
New submission from David Watson :
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
keywords: patch
messages: 113921
New submission from David Watson :
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: baikie
priority: normal
David Watson 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 the conf
David Watson 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 to an encoding in
Changes by David Watson :
Added file: http://bugs.python.org/file18491/add-errno-check-3.x.diff
___
Python tracker
<http://bugs.python.org/issue9569>
___
___
Python-bug
Changes by David Watson :
Added file: http://bugs.python.org/file18490/add-errno-check-2.x.diff
___
Python tracker
<http://bugs.python.org/issue9569>
___
___
Python-bug
David Watson 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
os.unlink rather
David Watson 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,
and just says that E
David Watson added the comment:
The returned string should also be decoded with the file system
encoding and surrogateescape error handler, as per PEP 383 -
there's a patch at issue #9580 to do this.
--
___
Python tracker
<http://bugs.py
New submission from David Watson :
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!)
--
components: Extension
Changes by David Watson :
Added file: http://bugs.python.org/file18487/confstr-long-result.diff
___
Python tracker
<http://bugs.python.org/issue9579>
___
___
Python-bug
New submission from David Watson :
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:
>>> import os
>&g
New submission from David Watson :
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.
--
components: Extensi
Changes by David Watson :
Added file: http://bugs.python.org/file18479/test-mknod-mkfifo-2.x.diff
___
Python tracker
<http://bugs.python.org/issue9569>
___
___
Python-bug
New submission from David Watson :
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
status: open
title: Add
Changes by David Watson :
Added file: http://bugs.python.org/file18273/try-surrogateescape-first-2.diff
___
Python tracker
<http://bugs.python.org/issue9377>
___
___
Pytho
David Watson 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 that PyUnicode_AsEncoded
David Watson 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 i
Changes by David Watson :
Added file: http://bugs.python.org/file18196/try-surrogateescape-first.diff
___
Python tracker
<http://bugs.python.org/issue9377>
___
___
Pytho
New submission from David Watson :
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 with undecodable byte
sequences in
David Watson added the comment:
You're having a bad day at the office :) Just use "patch -p1".
--
___
Python tracker
<http://bugs.python.org/issue4926>
___
_
Changes by David Watson :
Added file: http://bugs.python.org/file18190/visibility-3.x.diff
___
Python tracker
<http://bugs.python.org/issue4926>
___
___
Python-bugs-list m
Changes by David Watson :
Added file: http://bugs.python.org/file18189/visibility-2.x.diff
___
Python tracker
<http://bugs.python.org/issue4926>
___
___
Python-bugs-list m
1 - 100 of 141 matches
Mail list logo
