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
|
