[Numpy-discussion] Warnings in current trunk

[David Cournapeau]

Charles R Harris wrote:
>
>
> On Tue, Feb 17, 2009 at 8:56 PM, David Cournapeau
> <david at ar.media.kyoto-u.ac.jp <mailto:david at ar.media.kyoto-u.ac.jp>>
> wrote:
>
>     Charles R Harris wrote:
>     > I see a lot of warnings like:
>     >
>     > In file included from numpy/core/src/multiarraymodule.c:87:
>     > numpy/core/src/umath_funcs_c99.inc.src:199:1: warning: "isnan"
>     redefined
>     > In file included from /usr/include/python2.5/pyport.h:204,
>     >                  from /usr/include/python2.5/Python.h:57,
>     >                  from numpy/core/src/multiarraymodule.c:18:
>     >
>     > These are probably from r6363.
>     >
>     > Also
>     >
>     > In file included from numpy/core/src/scalartypes.inc.src:10,
>     >                  from numpy/core/src/arrayobject.c:537,
>     >                  from numpy/core/src/multiarraymodule.c:102:
>     > numpy/core/src/numpyos.c: In function 'NumPyOS_ascii_strtod':
>     > numpy/core/src/numpyos.c:431: warning: assignment discards
>     qualifiers
>     > from pointer target type
>     > numpy/core/src/numpyos.c:480: warning: assignment discards
>     qualifiers
>     > from pointer target type
>
>     The second one should be easy to fix, the first one not so much. The
>     problem is simple: for the float format fixes recently merged in the
>     trunk, we need some math functions - those format functions are
>     used in
>     multiarray extension. Up to now, we only needed math function in
>     ufunc,
>     and did so by including .c files. I first did the obvious thing,
>     including the same file as well in multiarray, but it does not work so
>     well, as you can see.
>
>     I think this "including .c" business has got to a point where it is
>     becoming insane :) Not only does it make the code difficult to follow
>     (at least to me), but it also causes various issues on MS platforms,
>     which are difficult to track (VS definitely does not like big
>     files, and
>     often segfaults). Of course, for python API, we don't have a choice
>     because of C limitations (if we care about cross platform that
>     is), but
>     we can make things better.
>
>
> The easy fix is to compile separately and link but that will expose a
> lot of extraneous symbols in the extension module.

Is may be easy in principle, but it is not so practically, because of
various build issues (the separate library has to be built first, but
the current code to generate config.h assumes to be built through an
extension). But I agree, that's the only portable solution, and it has
other advantages as well (being able to reuse our portable math
functions in other extensions, for example). The extraneous symbols are
OK if we decorate them (npy_log, etc...) and I think it is actually
helpful to have name to make the difference between the libc and our
function. In particular, if later we can provide several differently
optimized functions.

> Not that most would notice ;) I believe there are linker specific
> commands that can be used to control that, but we have to support a
> lot of platforms and no doubt life becomes messy.

Yes, it would be messy: I don't know any platform which does not have
this capability (Gnu linker, MS linker and Solaris linker all have
this), but to implement it would be a lot of effort for relatively
little gain.

> I think your quick fix for the second problem is a bit bogus, it
> essentially discards the const qualifier on purpose instead of by
> accident.

Yes, but that's the only solution. FWIW, I loooked a bit at how the
glibc does things, and it is pretty similar. You can't avoid casts
everywhere - and the cast I added are correct I believe.

> I tried pretty much the same quick fix and the problem was just pushed
> elsewhere.

Where ? I compiled with -W -Wall -Wextra, and there was no other warning
(in that part of the code I mean), at least on 32 bits. But before
checking more thoroughly, I want to finish cleaning numpy/core/setup.py

David