Jonas Hahnfeld via "Developers list for Guile, the GNU extensibility library" <guile-devel@gnu.org> writes:
> This should be the case, I always make sure that all intermediate > states compile. If I missed something, please let me know where you > see a failure. Sorry, that was just a mireading on my part. > Shorter, more maintainable code is IMHO always a win. Not insisting on anything, and not critical -- just wasn't immediately obvious that was the only reason, and I've seen the numbers.c code be fairly particular in the past. But after looking up scm_to_mpz's code too, I can of course see that it's "not much difference". > There are plenty SCM_INTERNAL internal functions in libguile. In this > particular case, scm_from_inum is static so it will never be visible > outside of its translation unit. Sure. I was commenting on a possible naming convention, not visibility. As mentioned, I wondered if we have a policy of avoiding scm_* for functions that areen't part of the public api, reserving that as a signal. Not sure, was just asking. >> - If the code is packing two 32-bit integers into a(n assumed at >> least) 64-bit integer, then the C compiler's probably not going to >> complain about unintentional uses of that packed value as a single >> integer. If there are any concerns that might cause us to miss >> something important, I wondered if there would be any point, if it's >> feasible, to define it as a non-integral type, even if just >> temporarily, to force the compiler to expose any such situations. > > I'm not sure where exactly this applies... I wasn't either -- hence wondering about trying to compile with a non-integral type if it were easy enough to be sure. May not be a problem at all. > If I'm honest, it would help more to get reviews from people actually > looking at the code... Well, for what it's worth, I was hesitant too, but people asked me to post my (as I told them) cursory comments. I won't plan to pursue it further. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
