Re: Attempting to unbox struct fields

["Thompson, David" <dthompson2@worcester.edu>]

Hi Mark,

On Sun, Feb 28, 2016 at 10:56 PM, Mark H Weaver <mhw@netris.org> wrote:
> Hi David,
>
> "Thompson, David" <dthompson2@worcester.edu> writes:
>> Here's a patch I came up with to enable (and fix where necessary) the
>> support for signed integer and double struct fields.
>
> Great, thanks for working on it!  This is not a proper review, just a
> couple of questions and comments.

I'm not very knowledgeable in the finer points of writing portable C
code or the Guile C API, so this feedback is very valuable.  Thanks!

>> Am I on the right track here?
>
> The first thing I noticed is that the patch assumes that doubles are the
> same size as pointers.  Obviously this is not the case on 32-bit
> systems.  What's the plan for those systems?

Yeah, I just hacked this together on my x86_64 system and paid no mind
to portability.  I was hoping that you or Andy or Ludovic would have
an idea for how to address portability issues. :)

> The patch also currently assumes that longs and pointers are the same
> size, and this turns out to be false on LLP64 systems such as 64-bit
> Windows.  See <https://debbugs.gnu.org/22406>.  However, it should be
> straightforward to fix this issue.
>
>> +           if ((prot != 'r' && prot != 'w') || inits_idx == n_inits)
>> +             *mem = 0.0;
>
> Note that 'mem' is of type scm_t_bits*, so the 0.0 will be converted to
> the integer 0 and then stored as an integer, which I guess is not what
> you meant.  Note that in practice this works on IEEE 754 systems, where
> 0.0 is represented as all zero bits, but the code is somewhat misleading
> and less portable than it could be.

D'oh!  I forgot to cast here.  Thanks for the explanation.  It
explains why I didn't notice the issue when testing.

My current plan is to keep pressing onward and produce a
proof-of-concept, hacky patch set that allows unboxed struct fields on
x86_64.  Then, with some help and guidance, I can sort out the
portability issues, code style issues, unit tests, and documentation
after confirmation that the prototype is on the right track.

Thanks,

- Dave