[issue2443] uninitialized access to va_list
New submission from Rolland Dudemaine <[EMAIL PROTECTED]>:
In many files, the following code is present (with slight variations,
but the important part is there) :
static PyObject *
objargs_mktuple(va_list va)
{
int i, n = 0;
va_list countva;
PyObject *result, *tmp;
#ifdef VA_LIST_IS_ARRAY
memcpy(countva, va, sizeof(va_list));
#else
#ifdef __va_copy
__va_copy(countva, va);
#else
countva = va;
#endif
#endif
...
memcpy() is accessing va_list before it is initialized.
Before the first access to a va_list type variable, and after the last
access to that variable, calls to va_start() and va_end() must be made
to initialize and free the variable.
Such behaviour should be corrected in the following files :
- Objects/abstract.c, line 1901
- Objects/stringobject.c, line 162
- getargs.c, line 66
- getargs.c, line 1188
- modsupport.c, line 479
--
components: Build
messages: 64234
nosy: rolland
severity: normal
status: open
title: uninitialized access to va_list
type: compile error
versions: Python 2.5, Python 2.6, Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2443>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2443] uninitialized access to va_list
Rolland Dudemaine <[EMAIL PROTECTED]> added the comment:
This is what I meant. The initialization should be done by calling
va_start(count_va); as you described.
In the files and lines I reported though, this is not called.
I'll file a patch for it soon.
--Rolland Dudemaine
Alexander Belopolsky wrote:
> Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
>
> This is not a bug. All the reported functions expect va_list argument
> to be initialized before being called. AFAICT, they are consistently
> used in this way. For example,
>
> PyObject *
> PyObject_CallFunctionObjArgs(PyObject *callable, ...)
> {
> PyObject *args, *tmp;
> va_list vargs;
>
> if (callable == NULL)
> return null_error();
>
> /* count the args */
> va_start(vargs, callable);
> args = objargs_mktuple(vargs);
> va_end(vargs);
> if (args == NULL)
> return NULL;
> tmp = PyObject_Call(callable, args, NULL);
> Py_DECREF(args);
>
> return tmp;
> }
>
> This may need to be clarified in the docs. For example, PyString_FromFormatV
> does not mention that vargs needs to be
> initialized: <http://docs.python.org/dev/c-
> api/string.html#PyString_FromFormatV>. On the other hand, this may be
> obvious to most C programmers.
>
> I suggest to close this issue as invalid.
>
> --
> nosy: +belopolsky
>
> __
> Tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue2443>
> __
>
--
title: Define Py_VA_COPY macro as a cross-platform replacement for gcc
__va_copy -> uninitialized access to va_list
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2443>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2443] uninitialized access to va_list
Rolland Dudemaine <[EMAIL PROTECTED]> added the comment: Actually, this thing is more complex to solve than I thought. Specifically, as described in http://www.opengroup.org/onlinepubs/007908775/xsh/stdarg.h.html stdarg requires that variable argument functions have at least one fixed argument. This is implied by the declaration of "void va_start(va_list ap, argN);". As explained in the original ticket description, and also described before in the above link, va_start() must be called before any call to va_arg(), and this includes any access to the argument list using __va_copy namely. The problem is that at least objargs_mktuple(), line 2649 of Objects/abstract.c does not have a first fixed argument. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2443> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2497] stdbool support
New submission from Rolland Dudemaine <[EMAIL PROTECTED]>: For better portability, it is good to support stdbool.h when it exists. This prevents a potential issue when compiling asdl.c. Patch attached. -- components: Build files: python_stdbool_20080327.diff keywords: patch messages: 64594 nosy: rolland severity: normal status: open title: stdbool support versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9875/python_stdbool_20080327.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2497> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2497] stdbool support
Changes by Rolland Dudemaine <[EMAIL PROTECTED]>: -- type: -> compile error __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2497> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2497] stdbool support
Rolland Dudemaine <[EMAIL PROTECTED]> added the comment:
Some compilers define false and true as macros.
When doing this, the definition in asdl.h (included from asdl.c) which
is originally :
typedef enum {false, true} bool;
therefore becomes :
typedef enum {0, 1} bool;
which is non-sensical.
Using stdbool.h when it is available will ensure bool is defined as a
type following the correct definition, which may or may not be an enum
depending on the compiler.
Even when using gcc, stdbool.h is here to define bool in C language, so
why not use it ?
--Rolland
Martin v. Löwis wrote:
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
> Why does it improve portability to use stdbool.h when it exists?
>
> What is the potential issue with asdl.c that gets fixed with this patch?
>
> --
> nosy: +loewis
>
> __
> Tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue2497>
> __
>
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2497>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2497] stdbool support
Rolland Dudemaine <[EMAIL PROTECTED]> added the comment: In this precise case, this is for an RTOS called INTEGRITY, which does define true and false as macros. The compiler is the vendor compiler (Green Hills), but the definition conflicting with Python's definition is comiung from the system header. Note, the issue still remains outside this context. >> Using stdbool.h when it is available will ensure bool is defined as a >> type following the correct definition, which may or may not be an enum >> depending on the compiler. >> > > But would that help in any way with respect to above compilers? > If they don't follow the C standard, why should they provide stdbool.h? > That's not the point. If stdbool is not available, C99 still defines false and true as macros. If stdbool is available, then most compilers will define false and true as macros. This includes Green Hills' compiler, but more importantly gcc as well. Look at http://gcc.gnu.org/viewcvs/trunk/gcc/ginclude/stdbool.h?revision=130805&view=markup for the current definition of stdbool.h in gcc. Look at http://www.opengroup.org/onlinepubs/009695399/basedefs/stdbool.h.html for a definition of how false, true and _Bool should be defined. In both cases, if stdbool was included by any system header in the future, that would conflict with your current definition. >> Even when using gcc, stdbool.h is here to define bool in C language, so >> why not use it ? >> > > Because we cannot *rely* on stdbool.h being present. Therefore, > inclusion of stdbool.h must be conditional, with a fallback definition > if stdbool.h is absent, and it thus complicates the source code of > Python, with no gain whatsoever. > This is the main reason why I added the conditional in the code, so that for compilers that do not have a definition everything will work fine, and for those who have, then it's doing the right and expected thing. But actually, you're right, the line should be completely eliminated, and replaced with the following : typedef unsigned char _Bool; #define bool _Bool #define true 1 #define false 0 Btw, there are already a number of fallback definitions in Python.h and such. This one is another portability issue, just adding to the others. stdbool.h is a standard facility created to help portability, so again, why not use it ? I can post an updated patch if you want. Do you agree with these changes then? --Rolland > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue2497> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2497> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
