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 is the same length that the OS reported in the first call instead of using the length from the second call and resizing the buffer if necessary. This means the returned value will be truncated or contain trailing garbage if the string changed its length betweeen calls.
I don't know of an actual environment where configuration strings can change at runtime, but it's not forbidden by POSIX as far as I can see (the strings are described as "variables", after all, and sysconf() values such as CHILD_MAX can change at runtime). Implementations can also provide additional confstr() variables not specified by POSIX. The patch confstr-long-result.diff at issue #9579 would fix this (for 3.x), but Victor Stinner has expressed concern that a buggy confstr() could create a near-infinite loop with that patch applied. ---------- components: Extension Modules messages: 114396 nosy: baikie priority: normal severity: normal status: open title: os.confstr() does not handle value changing length between calls type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9647> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
