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

[Alf P. Steinbach /Usenet]

* Martin v. Loewis, on 07.07.2010 21:10:
>> Python 3.1.1, file [pymem.h]:
>>
>> PyAPI_FUNC(void *) PyMem_Malloc(size_t);
>>
>> #define PyMem_MALLOC(n)        (((n)<  0 || (n)>  PY_SSIZE_T_MAX) ? NULL \
>>                  : malloc((n) ? (n) : 1))
>>
>> The problem with the latter that it seems that it's intended for safety
>> but does the opposite...
>
> Why do you say that? It certainly *does* achieve safety, wrt. to certain
> errors, specifically:
> - passing sizes that are out-of-range
> - supporting malloc(0) on all systems

It uses malloc instead of PyMem_Malloc. malloc may well be different and use a 
different heap in an extension DLL than in the Python interpreter and other 
extensions. That's one thing that the docs (rightly) warn you about.


>> Perhaps (if it isn't intentional) this is a bug of the oversight type,
>> that nobody remembered to update the macro?
>
> Update in what way?

I was guessing that at one time there was no PyMem_Malloc. And that it was 
introduced to fix Windows-specific problems, but inadvertently without updating 
the macro. It's just a guess as to reasons why the macro uses malloc directly.


>> 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. For a minimal extension this increased the
>> size from 8 KiB to 49 KiB. And generally with MS tools the size is
>> acceptably small.
>
> If you think that's fine for your extension module (which may well be
> the case), go ahead.

I have no comment on that except pointing it out as a somewhat stupid, somewhat 
evil social inclusion/exclusion argument, talking to the audience. Argh. You're 
wasting my time. But anyway, 49 KiB is small by today's standards. For example, 
you get 20 of those in a single MiB, and about 20.000 in a single GiB.


> But then, you could also just link with a different
> DLL version of the CRT instead.

When I wrote "link the runtime lib statically" that was an alternative to the 
usual link-as-DLL.

It wouldn't make sense to link the runtime lib statically as an alternative to 
linking it statically.

As for linking to a different /version/ of the CRT, if you really mean that, I 
think that's difficult. It's not necessarily impossible, after all there's 
STLPort. But I think that it must at the very least be rather difficult to do 
with Microsoft's tools, for otherwise people would have employed that solution 
before, and so I wouldn't trust the result, and wouldn't waste the time trying.


Cheers,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>