Here are some ISO C conformance patches, and
a minor cleanup I encountered along the way.

Lib/distutils/tests/test_config_cmd.py // comment --> /* comment */.
Lib/distutils/tests/test_build_ext.py,
Objects/weakrefobject.c,
Modules/_pickle.c,
Modules/_testcapimodule.c,
Python/import.c  .  .  .  .  .  .  .   Remove some invalid ',' and ';'s.
Python/Python-ast.c,
Modules/arraymodule.c  .  .  .  .  .   Non-constant array initializer.
Modules/_csv.c   .  .  .  .  .  .  .   Slight cleanup.
Modules/_ctypes/libffi/src/x86/ffi.c   Empty translation unit.

TODO when bored, if anyone cares for more pedantic ISO patches:
- printf(%p, non-void* pointer): The pointer should be cast to void*.
- More // comments -> /**/, but mostly in system-specific code so I
  can't test any patches I make.

If it’s not too much trouble for you, please post diffs as text files rather than binary.  You can also use “svn diff” to produce one file with all differences.

By the way, do these changes actually fix errors or are they just cleanups and pedantic (not a slight) fixes?  If the latter, I think they won’t go into stable branches.  I don’t do C though, so I won’t be the one to judge.  Thanks for the patches!

,AIric Araujo writes:
> By the way, do these changes actually fix errors or are they just
> cleanups and pedantic (not a slight) fixes?

I've used compilers where they'd be compile errors, though I found them
just with gcc -pedantic in an idle moment.

> If the latter, I think they won�t go into stable branches.

Not until someone has better time anyway...

About the .zip, it's 3 files (diff against python 3, 2, and both), I'll
upload them as an ascii file with '#####'s between when bugs.python.org
responds again.

Hallvard, if it going be a rather huge diff, you may make it available at http://bugs.python.org/review, so that it is easy for review.

I commited a part of your patches:

r86353 Remove ";" after function definition, invalid in ISO C
r86354: [array] int => Py_UNICODE (my commit is a little bit different, but it is based on your patch)
r86355: [_pickle] Remove useless comma, invalid in ISO C
r86356: [_csv] Remove useless (duplicate) initialization

I attach the uncommit part of your patches for 3.2.

--

For libffi, the project is maintained outside Python: you should also post your patch to http://sourceware.org/libffi/

Python-ast.c: why do you move req_name and req_type outside PyAST_obj2mod()?

STINNER Victor writes:
> Python-ast.c: why do you move req_name and req_type outside PyAST_obj2mod()?

Because there's no need to initialize the arrays each time PyAST_obj2mod
is called.  C90-friendly code inside PyAST_obj2mod would be

PyAST_obj2mod(PyObject* ast, PyArena* arena, int mode)
{
    mod_ty res;
    static char *const req_name[] = {"Module", "Expression", "Interactive"};
    PyObject *req_type[];
    req_type[0] = (PyObject*)Module_type;
    req_type[1] = (PyObject*)Expression_type;
    req_type[2] = (PyObject*)Interactive_type;
    ...
}

which is what the current code actually executes.

(I moved req_name to keep it next to req_type in the code.)

Hallvard B Furuseth writes:
> (...) which is what the current code actually executes.

Er, I mean, that's what it does with req_type.
The 'static' for req_name is an optimization of the current code.

> I've used compilers where they'd be compile errors, though I found
> them just with gcc -pedantic in an idle moment.

If Victor accepts the patches then they’re useful :)

>> If the latter, I think they won’t go into stable branches.
> Not until someone has better time anyway...

It’s not a question of time but policy: Stable branches (2.7 and 3.1) only get bug fixes, not new features or code cleanups.

> About the .zip, it's 3 files (diff against python 3, 2, and both),
> I'll upload them as an ascii file with '#####'s between

It’s actually easier: “svn diff file1 dir/file2 dir/file3” produces one valid diff.

STINNER Victor writes:
> Python-ast.c: why do you move req_name and req_type outside PyAST_obj2mod()?

Eh, in case I've managed to be sufficiently unclear: The reason I
modified it at all was because the initialization is not valid in C90,
only in C99.

> Stable branches (2.7 and 3.1) only get bug fixes, not new features or
> code cleanups.

Éric, making code compliant *is* a bug fix (admittedly of minor importance here, since all modern compilers accept the non-compliant code anyway).

New changeset 74fa7b4b934f by Éric Araujo in branch 'default':
Port r86353 to packaging (#10359: “;” after function definition is invalid in ISO C)
http://hg.python.org/cpython/rev/74fa7b4b934f

According to the latest patch updated by Victor, there are only 3 files left:
 * Lib/distutils/tests/test_config_cmd.py
 * Python/Python-ast.c
 * Modules/_ctypes/libffi/src/x86/ffi.c

The first is in a test and it's probably safe to fix (Éric, do you want to take care of that?) and the last should be reported upstream.
About the one in Python/Python-ast.c, either we fix it or if the proposed patch is not acceptable, we can close this issue as soon as the first file is fixed.

I will commit this fix and push this week-end or Monday.

New changeset fe0972e102cd by Éric Araujo in branch '3.2':
Make C code in one distutils test comply with ISO C (#10359).
http://hg.python.org/cpython/rev/fe0972e102cd

New changeset 9ded1f21f0fd by Éric Araujo in branch 'default':
Make C code in one packaging test comply with ISO C (#10359).
http://hg.python.org/cpython/rev/9ded1f21f0fd

New changeset 134b68cae802 by Éric Araujo in branch '2.7':
Make C code in one distutils test comply with ISO C (#10359).
http://hg.python.org/cpython/rev/134b68cae802

Do the changes to Python/Python-ast.c and Modules/_ctypes/libffi/src/x86/ffi.c still apply?  (libffi is an external project, but our copy is already edited so we might as well do one more change).

It looks like someone has already done the Python-ast cleanup and I don't understand the point of the distutils test one or the libffi one (ffi has been updated but it's trivial and would still apply).

I'm not inclined to apply the patch to ffi unless someone can demonstrate that it is an actual problem.  given that nobody has applied it to *upstream* libffi (since we just pulled in v3.0.13 earlier this week) I doubt it matters to anyone.

everything here looks complete.

> I don't understand the point of the distutils test one

Making the test not fail wrongly with some compilers.  This was committed.