[Numpy-discussion] Warnings in current trunk

Charles R Harris charlesr.harris@gmail....
Wed Feb 18 00:14:45 CST 2009


On Tue, Feb 17, 2009 at 10:22 PM, David Cournapeau <
david@ar.media.kyoto-u.ac.jp> wrote:

> Charles R Harris wrote:
> >
> >
> > On Tue, Feb 17, 2009 at 8:56 PM, David Cournapeau
> > <david@ar.media.kyoto-u.ac.jp <mailto: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.
>
> 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.
>

I was thinking of just linking together the separately compiled object
modules. But we would normal headers to include going that route. I never
liked the automatically generated headers, it kind of obviates the whole
idea of defining the interface separately from the function code.


>
> > 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
>

I just used changed the declaration to const char *p and there was a problem
with the call to PyOS_ascii_strtod. That actually seems to be a problem with
function signature (also in strtod), so you are probably right that an
explicit cast is the only way to do it.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20090217/45a61ee2/attachment.html 


More information about the Numpy-discussion mailing list