Re: [Python-Dev] [Python-checkins] cpython (3.2): Fixes issue #8052: The posix subprocess module's close_fds behavior was
On Sat, Jan 21, 2012 at 4:21 PM, Benjamin Peterson benja...@python.org wrote:
2012/1/21 gregory.p.smith python-check...@python.org:
...
+/* Convert ASCII to a positive int, no libc call. no overflow. -1 on error.
*/
Is no libc call important?
Yes. strtol() is not on the async signal safe C library function list.
+static int _pos_int_from_ascii(char *name)
To be consistent with the rest of posixmodule.c, static int should
be on a different line from the signature. This also applies to all
other function declarations added by this.
Python C style as a whole, yes. This file already has a mix of same
line vs two line declarations, I added these following the style of
the functions immediately surrounding them. Want a style fixup on the
whole file?
+{
+ int num = 0;
+ while (*name = '0' *name = '9') {
+ num = num * 10 + (*name - '0');
+ ++name;
+ }
+ if (*name)
+ return -1; /* Non digit found, not a number. */
+ return num;
+}
+
+
+/* Returns 1 if there is a problem with fd_sequence, 0 otherwise. */
+static int _sanity_check_python_fd_sequence(PyObject *fd_sequence)
+{
+ Py_ssize_t seq_idx, seq_len = PySequence_Length(fd_sequence);
PySequence_Length can fail.
It has already been checked not to by the only entry point into the
code in this file.
+ long prev_fd = -1;
+ for (seq_idx = 0; seq_idx seq_len; ++seq_idx) {
+ PyObject* py_fd = PySequence_Fast_GET_ITEM(fd_sequence, seq_idx);
+ long iter_fd = PyLong_AsLong(py_fd);
+ if (iter_fd 0 || iter_fd prev_fd || iter_fd INT_MAX) {
+ /* Negative, overflow, not a Long, unsorted, too big for a fd.
*/
+ return 1;
+ }
+ }
+ return 0;
+}
+
+
+/* Is fd found in the sorted Python Sequence? */
+static int _is_fd_in_sorted_fd_sequence(int fd, PyObject *fd_sequence)
+{
+ /* Binary search. */
+ Py_ssize_t search_min = 0;
+ Py_ssize_t search_max = PySequence_Length(fd_sequence) - 1;
+ if (search_max 0)
+ return 0;
+ do {
+ long middle = (search_min + search_max) / 2;
+ long middle_fd = PyLong_AsLong(
+ PySequence_Fast_GET_ITEM(fd_sequence, middle));
No check for error?
_sanity_check_python_fd_sequence() already checked the entire list to
guarantee that there would not be any such error.
+ if (fd == middle_fd)
+ return 1;
+ if (fd middle_fd)
+ search_min = middle + 1;
+ else
+ search_max = middle - 1;
+ } while (search_min = search_max);
+ return 0;
+}
In general this is an extension module that is best viewed as a whole
including its existing comments rather than as a diff.
It contains code that will look odd in a diff because much of it
executes in a path where not much is allowed (post fork, pre exec) and
no useful way of responding to an error is possible so it attempts to
pre-check for any possible errors up front so that later code that is
unable to handle errors cannot possibly fail.
-gps
___
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/archive%40mail-archive.com
Re: [Python-Dev] Counting collisions for the win
This seed is chosen randomly at runtime, but cannot change once chosen. The hash is used to compare objects: if hash(obj1) != hash(obj2), objects are considered different. So two strings must have the same hash if their value is the same. Salt could also be an appropriate term here, but since salt is generally changed on a per-use basis (a single process may use many different salts), seed is more correct, since this value is only chosen once per process. We may use a different salt per dictionary. Victor ___ 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/archive%40mail-archive.com
Re: [Python-Dev] python build failed on mac
On 21 Jan 2012, at 20:24, Vijay Majagaonkar wrote: On 2012-01-21, at 1:57 PM, Hynek Schlawack wrote: Am Freitag, 20. Januar 2012 um 23:40 schrieb Vijay Majagaonkar: I am trying to build python 3 on mac and build failing with following error can somebody help me with this It is a known bug that Apple's latest gcc-llvm (that comes with Xcode 4.1 by default as gcc) miscompiles Python: http://bugs.python.org/issue13241 make clean CC=clang ./configure make -s Thanks for the help, but above command need to run in different way ./configure CC=clang make I'm not sure why you think it needs to be that way, but it's fine by me as both ways work fine. I am not sure, that was just try and worked for me, with first option suggested by you was throwing same compile error then I tried with this that worked :) The problems compiling Python 3 on the Mac with XCode 4.1 have been reported and discussed here: http://bugs.python.org/issue13241 This invocation worked for me: ./configure CC=gcc-4.2 --prefix=/dev/null --with-pydebug All the best, Michael Foord this allowed me to build the code but when ran test I got following error message [363/364/3] test_io python.exe(11411) malloc: *** mmap(size=9223372036854775808) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug python.exe(11411,0x7fff7a8ba960) malloc: *** mmap(size=9223372036854775808) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug python.exe(11411,0x7fff7a8ba960) malloc: *** mmap(size=9223372036854775808) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug I am using Mac OS-X 10.7.2 and insatlled Xcode 4.2.1 Please ensure there aren't any gcc-created objects left by running make distclean first. I have tried this option too but still result is same, I have attached test result if that will helps mac_test.logand I will like to work on this if you give me some guideline to look into this issue Thanks for the help ;)___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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/archive%40mail-archive.com
Re: [Python-Dev] python build failed on mac
Wiadomość napisana przez Michael Foord w dniu 22 sty 2012, o godz. 14:14: ./configure CC=gcc-4.2 --prefix=/dev/null --with-pydebug Why the phony prefix? -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. Pomyśl o środowisku naturalnym zanim wydrukujesz tę wiadomość! Please consider the environment before printing out this e-mail. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] python build failed on mac
On 22 Jan 2012, at 17:43, Łukasz Langa wrote: Wiadomość napisana przez Michael Foord w dniu 22 sty 2012, o godz. 14:14: ./configure CC=gcc-4.2 --prefix=/dev/null --with-pydebug Why the phony prefix? Heh, it's what I've always done - I think copied from other developers. The dev guide suggests it: http://docs.python.org/devguide/setup.html#unix There is normally no need to install your built copy of Python! The interpreter will realize where it is being run from and thus use the files found in the working copy. If you are worried you might accidentally install your working copy build, you can add --prefix=/dev/null to the configuration step. Not that this is particularly a worry for me... All the best, Michael -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. Pomyśl o środowisku naturalnym zanim wydrukujesz tę wiadomość! Please consider the environment before printing out this e-mail. -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Counting collisions for the win
On Sun, Jan 22, 2012 at 11:11, Victor Stinner victor.stin...@haypocalc.com wrote: This seed is chosen randomly at runtime, but cannot change once chosen. The hash is used to compare objects: if hash(obj1) != hash(obj2), objects are considered different. So two strings must have the same hash if their value is the same. Salt could also be an appropriate term here, but since salt is generally changed on a per-use basis (a single process may use many different salts), seed is more correct, since this value is only chosen once per process. We may use a different salt per dictionary. Can we do that? I was thinking of ways to not raise errors when we get over a collision count, but instead somehow change the way the dictionary behaves when we get over the collision count, but I couldn't come up with something. Somehow adding a salt would be one possibility. But I don't see how it's doable except for the string-keys only case mentioned before. But I might just be lacking imagination. :-) //Lennart ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Counting collisions for the win
I think this thread is approaching the recursion limit. Be careful not to blow the stack :) Regards Antoine. On Sun, 22 Jan 2012 20:53:41 +0100 Lennart Regebro rege...@gmail.com wrote: On Sun, Jan 22, 2012 at 11:11, Victor Stinner victor.stin...@haypocalc.com wrote: This seed is chosen randomly at runtime, but cannot change once chosen. The hash is used to compare objects: if hash(obj1) != hash(obj2), objects are considered different. So two strings must have the same hash if their value is the same. Salt could also be an appropriate term here, but since salt is generally changed on a per-use basis (a single process may use many different salts), seed is more correct, since this value is only chosen once per process. We may use a different salt per dictionary. Can we do that? I was thinking of ways to not raise errors when we get over a collision count, but instead somehow change the way the dictionary behaves when we get over the collision count, but I couldn't come up with something. Somehow adding a salt would be one possibility. But I don't see how it's doable except for the string-keys only case mentioned before. But I might just be lacking imagination. :-) //Lennart ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Counting collisions for the win
We may use a different salt per dictionary. If we're willing to re-hash everything on a per-dictionary basis. That doesn't seem reasonable given our existing usage. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Counting collisions for the win
On Mon, Jan 23, 2012 at 06:02, Paul McMillan p...@mcmillan.ws wrote: We may use a different salt per dictionary. If we're willing to re-hash everything on a per-dictionary basis. That doesn't seem reasonable given our existing usage. Well, if we get crazy amounts of collisions, re-hashing with a new salt to get rid of those collisions seems quite reasonable to me... //Lennart ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Counting collisions for the win
Lennart Regebro writes: On Mon, Jan 23, 2012 at 06:02, Paul McMillan p...@mcmillan.ws wrote: We may use a different salt per dictionary. If we're willing to re-hash everything on a per-dictionary basis. That doesn't seem reasonable given our existing usage. Well, if we get crazy amounts of collisions, re-hashing with a new salt to get rid of those collisions seems quite reasonable to me... But doesn't the whole idea of a hash table fall flat on its face if you need to worry about crazy amounts of collisions (outside of deliberate attacks)? ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Counting collisions for the win
On 23 January 2012 16:49, Lennart Regebro rege...@gmail.com wrote: On Mon, Jan 23, 2012 at 06:02, Paul McMillan p...@mcmillan.ws wrote: We may use a different salt per dictionary. If we're willing to re-hash everything on a per-dictionary basis. That doesn't seem reasonable given our existing usage. Well, if we get crazy amounts of collisions, re-hashing with a new salt to get rid of those collisions seems quite reasonable to me... Actually, this looks like it has the seed of a solution in it. I haven't scrutinised the following beyond it sounds like it could work - it could well contain nasty flaws. Assumption: We only get an excessive number of collisions during an attack (directly or indirectly). Assumption: Introducing a salt into hashes will change those hashes sufficiently to mitigate the attack (all discussion of randomising hashes makes this assumption). 1. Keep the current hashing (for all dictionaries) i.e. just using hash(key). 2. Count collisions. 3. If any key hits X collisions change that dictionary to use a random salt for hashes (at least for str and unicode keys). This salt would be remembered for the dictionary. Consequence: The dictionary would need to be rebuilt when an attack was detected. Consequence: Hash caching would no longer occur for this dictionary, making most operations more expensive. Consequence: Anything relying on the iteration order of a dictionary which has suffered excessive conflicts would fail. 4. (Optional) in 3.3, provide a way to get a dictionary with random salt (i.e. not wait for attack). Tim Delaney ___ 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/archive%40mail-archive.com
