[[ Resending from an account I'm actually subscribed with. ]]
Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 as discussed in __scm.h
causes SCM to be defined as a union type (though the comments say a
struct type), which enhances the type checking by making random
conversions and casts to and from pointer and integer types not work
without going through the correct conversion macros/functions.
Problem is, we're doing a lot of those.
It also means constant values for static initializers ("{ { BITS } }")
have a different form from run-time expressions generating certain
values ("scm_pack (BITS)" calls an inline function), and comparisons
can't be done with "==" and "!=". (In fact, tags.h already says "SCM
values can not be compared by using the operator ==", right above the
definition of scm_is_eq.)
Guess what we're also doing? :-)
And I haven't even tried compiling Ludovic's bdw-gc-static-alloc
branch yet, just master.
I can clean some of this up trivially -- SCM_PACK/SCM_UNPACK as
needed, change == to scm_is_eq. The initializers make it slightly
less trivial, and I can imagine different courses of action.
#1: We continue to not support static initialization. Move most of
the initializations in the library to the per-file init functions, and
for stuff like the ra_iproc tables in array-map.c we may want *one*
internal initializer macro (SCM_I_UNSPECIFIED_INIT or
SCM_I_UNDEFINED_INIT? maybe even something zero-valued) for filling in
slots in static structures without getting compiler warnings about
missing initializers.
#1a: Extend #1 later with whatever internal macros are needed to
provide the right initialization syntax for constructs used in bdw-gc-
static-alloc based on the STRICTNESS setting.
#1b: Try to supplement #1 with changes to SCM_PACK or SCM_MAKIFLAG to
make it not considered a compile-time constant even with STRICTNESS<2
and thus SCM_UNSPECIFIED, SCM_BOOL_F, etc are never suitable for
static initialization, catching this problem earlier in the future. I
believe a use of a comma expression will suffice, but finding a form
that doesn't generate compiler warnings and doesn't generate run-time
code could be tricky. (Though, it becomes easier if we require only no
performance impact when optimizing and with ... what, inline function
support? gcc?)
#1c: Try to supplement #1 by defaulting to STRICTNESS=2 on platforms
where the union is passed and returned the same way as the pointer or
integer in function calls, and where there isn't a significant
performance impact. Probably selected via cpp macros in __scm.h, since
an autoconf feature test would be difficult at best, and still
specific to the compiler used for building libguile and not the one
used to build the application. This helps us avoid the "==" and
random casting part of the problem better in the future. Mac OS X
(10.5, Intel) seems to use the same calling convention both ways in
one simple test, though I haven't tried performance testing.
#2: Drop STRICTNESS=2 support and really support static initialization
with the current macros.
#3: Keep STRICTNESS=2 support, and support static initialization, even
for application code, with a bunch of new macros.
Thoughts? My preference is for #1 now, and #1a/b/c when convenient or
needed.
Ken
