Re: possible cstruct bug?

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

[cc cl-mirage: this references bug: 
https://github.com/mirage/ocaml-cstruct/issues/3 ]

On 11 Mar 2013, at 21:09, Arjun Guha <arjun@xxxxxxxxxxxxxx> wrote:
> 
> I finally had a change to look at this, and I think I see what's needed.
> 
> IMO, for a 32-bit enum, cstruct should also generate the functions 
> int32_to_foo and foo_to_int32. (Similarly for 64-bit enums).
> 
> Let me know if you agree and I'll do ahead.
> 
> It is a straightforward fix. I think the cleanest solution is to create three 
> copies of the output_enum function, each specialized for each field-width. It 
> is theoretically possible to still have just one output_enum func, but the 
> dependency between function names, types, and the arguments to output_enum 
> would be really messy.

Thanks for looking at this; I think that having a specialised field width 
function is easiest.  It's a little annoying on 64-bit architectures though, 
since an unboxed native integer is sufficient to encode a 32-bit integer 
without any boxing (which is why we didn't notice this bug before).

However, it's probably not worth all the configure script trouble to make this 
change, so generating specialised int{32/64}_to_foo functions is best.

cheers,
Anil

> 
> On 20 Feb 2013, at 14:32, Arjun Guha <arjun@xxxxxxxxxxxxxx> wrote:
> 
> > Anil,
> >
> > Where do you take bug reports on cstruct and other libraries? It looks like 
> > you've disabled issues in mirage/ocaml-cstruct.
> >
> > Anyway, I've installed cstruct from HEAD. With the following definition, I 
> > get an error saying "Integer literal exceeds the range of representable 
> > integers of type int32":
> >
> > cenum ofp_port_no {
> >   OFPP_ANY        = 0xffffffff
> > } as int32_t
> >
> > I think that ought to work. I can't postfix an "l" or "L" either. I'd be 
> > happy (actually, would enjoy) fixing if you can confirm.
> >
> > Arjun
> 
>