Hi Mark, On Sun, Feb 28, 2016 at 10:56 PM, Mark H Weaver <[email protected]> wrote: > Hi David, > > "Thompson, David" <[email protected]> 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
