incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Karman <>
Subject Re: [Lucy] Passing strings from Host to Lucy
Date Tue, 01 Sep 2009 19:29:19 GMT
Marvin Humphrey wrote on 09/01/2009 10:58 AM:

> Right now, this data structure bears the whimsical name "ZombieCharBuf", as in
> "A CharBuf which cannot be Destroyed."  ZombieCharBufs are either created on
> the stack or as compile-time static or global variables; they are never
> malloc'd.  Calling Destroy() on them is illegal and triggers an exception,
> hence the name.  However, "ZombieCharBuf" is not meant to be a final name;
> consider it an intentionally irritating reminder that there are issues with
> the CharBuf hierarchy regarding readonly strings and compatibility with
> multiple Unicode encodings that remain to be resolved.  :)  

I'd seen that name in the code just this last weekend (yes, I do read it 
when looking for good ideas...) and wondered what that was. Now All Is 

> The one thing that bothers me about this scheme is that it forces us to publish
> the struct definition of ZombieCharBuf.  Ordinarily, class struct definitions
> will be opaque -- but the compiler needs to know at least sizeof(ZombieCharBuf)
> in order to allocate the proper amount of stack memory.

What alternatives are there to publishing the struct? Isn't that pretty 
typical, to make some public .h file available with those kind of defs 
in it? Or are you worried that if the struct changes internally, that 
existing code might have abused it and will croak or worse on Lucy 
upgrade? In that latter case, I think following the Perl course of "what 
is documented is what is guaranteed" seems fair. Something like:

  ZombieCharBuf *zcb = malloc(sizeof(ZombieCharBuf));

is about all any host language can expect to work.

On the issue of names, why not LucyCharBuf?

Peter Karman  .  .

View raw message