Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

Martin v. Loewis martin at v.loewis.de
Wed Jul 7 15:47:59 EDT 2010


> Also observe that this macro is very badly written (even illegal) C.
> Consider what this would do:
> 
>     PyMem_MALLOC(n++)
> 
> According to Linus Thorvalds using macros like this is not even legal
> C:
> 
> http://www.linuxfocus.org/common/src/January2004_linus.html

[Please don't use "legal" wrt. programs - it's not "illegal" to violate
the language's rules; you don't go to jail when doing so. Linus said
"not allowed"]

You are misinterpreting that statement. Linus said that the isdigit
macro was non-conforming, *and meant that specifically for isdigit()*.
That's because the C standard says that isdigit is a function. Under
the as-if rule, you may implement it as a macro as long as nobody can
tell the difference. However, in the presented implementation, there
is a notable difference.

However, the C standard is silent wrt. to PyMem_MALLOC, and it certainly
allows the definition of macros which use the macro arguments more than
once.

> This would be ok, and safe as long as we use the GIL:

The macro is ok as it stands (minus the issues with multiple heaps).
The Python convention is that you clearly recognize PyMem_MALLOC as
a macro, so you should know not to pass parameters with side effects.

> register Py_ssize_t __pymem_malloc_tmp;
> #define PyMem_MALLOC(n)\
>      (__pymem_malloc_tmp = n, (((__pymem_malloc_tmp) < 0 ||
> (__pymem_malloc_tmp) > PY_SSIZE_T_MAX) ? NULL \
>                                  : malloc((__pymem_malloc_tmp) ?
> (__pymem_malloc_tmp) : 1)))

That would partially defeat the purpose, namely it would require the
compiler to put the size into a variable in memory, and possibly prevent
optimizations from taking place that rely on constant propagation
(depending on how smart the compiler is).

Regards,
Martin



More information about the Python-list mailing list