On Tue, Feb 17, 2009 at 10:22 PM, David Cournapeau < [email protected]> wrote:
> Charles R Harris wrote: > > > > > > On Tue, Feb 17, 2009 at 8:56 PM, David Cournapeau > > <[email protected] <mailto:[email protected]>> > > 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
_______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
