From: Peter V. <ve...@em...> - 2003-05-06 16:17:03
|
On Tuesday 06 May 2003 17:48, Todd Miller wrote: > Peter Verveer wrote: > >Hi, > > > >In the numarray source code Bool is defined as a typedef to char. Does= the > >Bool array type correspond to the Int8, or the UInt8 type? If I recall > >correctly, the char type may be signed or unsigned. Can I make any > >assumptions about the C type used to implement Bool at all? > > Yes! It's named Bool. :) Obviously, but then I need to include the numarray include file to make s= ure I=20 get the right definition, and I do not always want to do that. See below. > >I guess at the Python level it does not matter what actual C type is u= sed > > to implement bool arrays as it only represents boolean values. Howeve= r, > > at the level of C extensions I would like to deal with Bool arrays by > > calling existing functions written for the appropiate C type. > > The easiest way now is to just declare your variables with type "Bool". > The only thing I can think of which that doesn't cover is printf/scanf= =2E > Are there others? This does not work if you want to call a routine that was not written usi= ng=20 the numarray typedefs. For instance, I like to write my array processing=20 routines such that I can use them in a standalone C program without linki= ng=20 to numarray. These routines know nothing about numarray, but as long as t= he=20 layout and data types of the arrays are correct I can still use them in=20 numarray C routines. Then you need to know of course exactly what the C d= ata=20 types of the numarray routines are. That is easy for most types since the= y=20 are exactly defined by bit-size and sign. But this is currently not true = for=20 the Bool type. > >That would be somewhat > >simpler if Bool is always garantueed to be either a unsigned or a sign= ed > > char type. > > I think perhaps we should just re-define Bool as signed char. Any othe= r > opinions? That would solve the problem. Peter |