[fetter-devel] unnamed bit fields

[Rayiner Hashem]

(I've CC'ed Andras to this message)
It kind of depends on what Andras was doing. Bitfields are part of the 
wait.h API.
As far as being unnecessary or unused, it also depends on what PCRE imports 
and uses from wait.h. It's probable that to use PCRE, he doesn't need 
bitfield
support per-se, just for Verrazano to transform structs with bitfields into 
a format
that gives an equivalent memory layout. If that's the case, then the fix 
should be
quick in coming (its basically a bug fix). If Andras needs bitfield support, 
then I can
write a lowering pass, or Luis can implement bitfields. Either one is fine 
with me,
especially since I'll apparently need the lowering pass anyway to target 
other FFIs.

Sincerely,
Rayiner Hashem

On 9/13/05, Luis Oliveira <luismbo at gmail.com> wrote:
> 
> On 13/set/2005, at 06:06, Kenny Tilton wrote:
> > Didn't this start with a problem report from your first customer? Or
> > were they just making an observation? If the former, that gives you a
> > measure of how serious the problem is -- it came up in normal usage,
> > not some arcane stress test. So that makes it higher priority. Also,
> > it is one of your first customers, and you only get once chance to
> > make a first impression.
> 
> Indeed, you have a point there.
> 
> However, I don't see any much support for bitfields in other FFI's
> (only Allegro supports that AFAICT from a quick skim through the
> various docs). I suspect the details of bitfields vary a lot between
> compilers/abis.
> 
> This particular customer didn't actually need bitfields, though.
> Verrazano was generating unnecessary/unused struct typedefs, right?
> 
> --
> Luís Oliveira
> http://student.dei.uc.pt/~lmoliv/
> Equipa Portuguesa do Translation Project
> http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/fetter-devel/attachments/20050913/7c81c876/attachment.html>