[Numpy-discussion] Warnings in current trunk

Charles R Harris charlesr.harris@gmail....
Tue Feb 17 23:21:46 CST 2009

On Tue, Feb 17, 2009 at 8:56 PM, David Cournapeau <
david@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. 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.
It's not something I know much about in any case. I think we should also
have some honest header files, the automatically generated ones bug me.

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. I tried
pretty much the same quick fix and the problem was just pushed elsewhere. I
think the function needs a bit of redesign...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20090217/25483edc/attachment-0001.html 

More information about the Numpy-discussion mailing list