homepage

The attached patch fixes compiler warnings for the pythoncore project when building on 64-bit Windows.
Fixes for built-in modules are not included, however.

- <AdditionalOptions>/USECL:MS_OPTERON /GS- %(AdditionalOptions)</AdditionalOptions>
+ <BufferSecurityCheck>false</BufferSecurityCheck>
Please don't change too much things in the same patch. The issue #15792 is a better place for such change.

This issue duplicates the isuse #9566, but your patch is interesting. I created other more specific issues like #18295 and #18294.
- return lb - ll->ll_label;
+ return Py_SAFE_DOWNCAST(lb - ll->ll_label, Py_intptr_t, int);
I don't think that such change is correct, IMO the right fix is to change the result type to Py_intptr_t.

Yeah, sorry. This made it in by mistake. It was in the tree just to
eliminate warning noise.
On Mon, Jul 8, 2013 at 1:20 PM, STINNER Victor <report@bugs.python.org> wrote:
>
> STINNER Victor added the comment:
>
> - <AdditionalOptions>/USECL:MS_OPTERON /GS- %(AdditionalOptions)</AdditionalOptions>
> + <BufferSecurityCheck>false</BufferSecurityCheck>
>
> Please don't change too much things in the same patch. The issue #15792 is a better place for such change.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue18407>
> _______________________________________

The change in grammar.c:addlabel() is correct. The return value is an
index into the ll->ll_label array, thus an int. The code could be
rewritten to avoid the pointer addition by saving the value of
ll->ll_nlabels before it is incremented and return that instead,
On Mon, Jul 8, 2013 at 1:23 PM, STINNER Victor <report@bugs.python.org> wrote:
>
> STINNER Victor added the comment:
>
> This issue duplicates the isuse #9566, but your patch is interesting. I created other more specific issues like #18295 and #18294.
>
> - return lb - ll->ll_label;
> + return Py_SAFE_DOWNCAST(lb - ll->ll_label, Py_intptr_t, int);
>
> I don't think that such change is correct, IMO the right fix is to change the result type to Py_intptr_t.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue18407>
> _______________________________________

Ugh, sorry for the bad quoting (silly GMail).

Added new patch that removes the duplicate changes from issue #15792 and comments the lone explicit cast.
These changes fix 116 of the 216 warnings (54%!) for Win64. Together with issue #15792 brings the remaining count to 72.
I am unsure if splitting the changes further makes much sense as guidance I have received on IRC and as others have noted in various bug reports about "spamming" the tracker with issues per file.
With that and MvL's comment in issue #18295, I do not think that it is advisable to separate out changes for that issue.

Can we have the stage set to patch review please.

Would someone like to review the patch please, being aware that there are other open issues relating to compiler warnings on Windows.

Does the patch still apply cleanly?

New changeset c48ff73dd60bec5dcbe64bedeff91e6db26d98bc by Victor Stinner in branch 'master':
bpo-18407: win32_urandom() uses PY_DWORD_MAX (GH-10656)
https://github.com/python/cpython/commit/c48ff73dd60bec5dcbe64bedeff91e6db26d98bc

New changeset 4d73ae776140a583fdfe8f016d88cc767791e481 by Victor Stinner in branch 'master':
bpo-18407: ast.c uses Py_ssize_t for asdl_seq_LEN() iterator (GH-10655)
https://github.com/python/cpython/commit/4d73ae776140a583fdfe8f016d88cc767791e481

Almost all compiler warnings on 64-bit Windows have been fixed: bpo-9566 tracked most of them.
I extract the CryptGenRandom() fix from issue18407-2.diff. I rewrote the ast.c fix differently (use larger type, don't downcast).
The patch may still contains relevant changes on Python/dtoa.c and Python/getargs.c, but again, the most critical bugs and warnings have already been fixed. So I suggest to abandon issue18407-2.diff which has been written 5 years ago.
Thanks Jeremy Kloth for the report and for the patch! I think that it's now time to close the issue. See bpo-9566 for the few remaining issues.