Hi, Sorry for the spam, but I'm going through some backlog that I didn't have the resources to deal with. Has this issue been addressed?
Andy On Sun 14 Sep 2008 14:06, "Neil Jerram" <neiljer...@googlemail.com> writes: > 2008/9/12 Andy Wingo <wi...@pobox.com>: >> On Thu 11 Sep 2008 23:06, "Neil Jerram" <neiljer...@googlemail.com> writes: >> >>> Are you sure? Surely that would require a call somewhere to >>> scm_alloc_struct() with n_extra = 0, and I can't see any of those. >> >> I'm sure -- goops.c:1541 in master. Doesn't go through scm_alloc_struct >> at all. > > Thanks, I see now. > >>> Also, is Mikael right with his error #1? I'm thinking not, because I >>> believe that instances are structs too, so surely it's OK to call >>> SCM_STRUCT_DATA (x)[...] on them? >> >> I can't recall the mail at the moment. Please reply if you want me to >> dig through this -- I'm happy to do so. But instances are structs, yes. >> Calling SCM_STRUCT_DATA (x)[] does work. You have to know how many >> fields there are, though -- you get that from the vtable. > > Agreed. So I think the right fix here is along the lines of your > second suggestion: > >> #define SCM_NUMBER_OF_FIELDS(x) (SCM_STRUCT_VTABLE (x)[scm_si_nfields]) > > I propose specifically that we: > > - remove the SCM_NUMBER_OF_SLOTS macro - because it's never been > right, so there can't be external code relying on it > > - change scm_sys_fast_slot_ref and scm_sys_fast_slot_set_x to say > > i = scm_to_unsigned_integer (index, 0, SCM_SLOT (SCM_CLASS_OF (obj), > scm_si_nfields) - 1); > > OK? (There are way too many goops/struct macros already, so let's not > introduce another one!) > > One last concern, though: I didn't understand what you meant by "would > probably have a different purpose". (In: > >> assumption. The other would be to use a different definition of >> SCM_NUMBER_OF SLOTS, which would probably have a different purpose: > > ) > > Regards, > Neil -- http://wingolog.org/
