[Numpy-discussion] Warnings in current trunk

Charles R Harris charlesr.harris@gmail....
Wed Feb 18 00:21:35 CST 2009


On Tue, Feb 17, 2009 at 11:14 PM, Charles R Harris <
charlesr.harris@gmail.com> wrote:

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

Oh, and this should be avoided:

        if (endptr != NULL) *endptr = (char*)p;

Folks have different views about whether the single statement should be in
brackets but no one recommends putting it on the same line as the if. It's
too easy to overlook and habit draws the eye to the following line.

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


More information about the Numpy-discussion mailing list