[Pyrex] newby guidance

[John J Lee]

On Thu, 26 Jun 2003, Greg Ewing wrote:

> John J Lee <jjl at pobox.com>:
>
> > I *think* you can use Pyrex extension types to wrap structs without
> > explicitly declaring the struct members, but in my experiment I ran into
> > trouble zero-initialising whole structs as you would in C with the {}
> > aggregate-initialisation syntax.
>
> That's probably more to do with the fact that Pyrex currently doesn't
> *have* an aggregate-initialisation syntax!

Sure.  Since there are other bits of C syntax Pyrex doesn't have (*
operator) where it's still possible to get C behaviour, it seemed worth a
try, in my ignorance of Pyrex, to see if I could get the behaviour I
wanted.  My reason for posting it was just to explain what I was trying to
achieve.


> >    def __new__(self, *args, **kwargs):
> >        # XXX casting to TidyBuffer here causes C compile error -- is this a
> >        #   bug (shouldn't Pyrex spot the error, not leave it to the C
> >        #   compiler)?
> >##         self.buf = 0
>
> That would never have worked, even in C, and even with a cast.

Why not?  The equivalent C I had in mind was:

TidyBuffer buf = {0};

I presume you mean that the code in __new__ is not in fact initialising
self.buf at all, but attempting an assignment.  I make no complaint about
that -- I was simply explaining what I was trying to do, illustrating my
intent with my initial wild guess about how that might be expressed in
Pyrex.  My intent was to get away with minimal Pyrex declarations, to try
to insulate myself from API changes (the API in question is very shifty
ATM).  But given your reminder below about null pointers and portability,
perhaps I was wrong to try here...

(re the cast, my XXX comment was only referring to the fact that Pyrex
didn't *spot* the error, and wasn't questioning that it was an error).


[...]
> What you could perhaps have done instead is
>
>          memset(&self.buf, 0, sizeof(TidyBuffer))
>
> although that assumes that a null pointer has a bit pattern of 0 on
> your platform, which is not guaranteed, so for strict portability you
> have to initialise things individually anyway.

True.


[...]
> It's pretty much at your own risk. It's not possible for Pyrex to
> check this any better, since it can't be sure of the sizes of things
> as seen by the C compiler.

OK.

Thanks


John