Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
in [Python]
|
Prev: Python GUI for C program [was: ]
Next: Download Microsoft C/C++ compiler for use with Python 2.6/2.7ASAP
From: sturlamolden on 7 Jul 2010 15:32 On 7 Jul, 21:12, sturlamolden <sturlamol...(a)yahoo.no> wrote: > > #define PyMem_MALLOC(n) (((n) < 0 || (n) > PY_SSIZE_T_MAX) ? NULL \ > > : malloc((n) ? (n) : 1)) > > I was afraid of that :( 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 This would be ok, and safe as long as we use the GIL: 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))) An inline function is a better solution, but not ANSI C standard: inline void *PyMem_MALLOC(Py_ssize_t n) { return (((n) < 0 || (n) > PY_SSIZE_T_MAX) ? NULL : malloc((n) ? (n) : 1)); }
From: Alf P. Steinbach /Usenet on 7 Jul 2010 15:41 * sturlamolden, on 07.07.2010 21:12: > On 7 Jul, 06:54, "Alf P. Steinbach /Usenet"<alf.p.steinbach > +use...(a)gmail.com> wrote: > >> PyAPI_FUNC(void *) PyMem_Malloc(size_t); >> >> #define PyMem_MALLOC(n) (((n)< 0 || (n)> PY_SSIZE_T_MAX) ? NULL \ >> : malloc((n) ? (n) : 1)) > > I was afraid of that :( > > > >> Except for the problems with file descriptors I think a practical interim >> solution for extensions implemented in C could be to just link the runtime lib >> statically. > > You still have two CRTs linked into the same process. So? Cheers, - Alf -- blog at <url: http://alfps.wordpress.com>
From: sturlamolden on 7 Jul 2010 15:46 On 7 Jul, 21:41, "Alf P. Steinbach /Usenet" <alf.p.steinbach +use...(a)gmail.com> wrote: > > You still have two CRTs linked into the same process. > > So? CRT resources cannot be shared across CRT borders. That is the problem. Multiple CRTs are not a problem if CRT resources are never shared.
From: sturlamolden on 7 Jul 2010 15:51 On 7 Jul, 21:47, "Martin v. Loewis" <mar...(a)v.loewis.de> wrote: > 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). Also after reading carefully what Linus said, it would still be incorrect if n is a complex expression. So, an inline function is the "correct" one here.
From: Alf P. Steinbach /Usenet on 7 Jul 2010 16:04
* sturlamolden, on 07.07.2010 21:46: > On 7 Jul, 21:41, "Alf P. Steinbach /Usenet"<alf.p.steinbach > +use...(a)gmail.com> wrote: > >>> You still have two CRTs linked into the same process. >> >> So? > > CRT resources cannot be shared across CRT borders. That is the > problem. Multiple CRTs are not a problem if CRT resources are never > shared. Yeah, but then we're down to file descriptors, C library locales and such as the remaining problems. Cheers, - Alf -- blog at <url: http://alfps.wordpress.com> |