Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ken Raeburn <raeburn@raeburn.org>]

Picking up this thread again...

I've run some basic tests, and it looks like setting  
SCM_DEBUG_TYPING_STRICTNESS to 0 (which causes SCM to be defined as an  
integer type) also fails, though not quite as messily as setting it to  
2.

On Sep 16, 2009, at 15:20, Andy Wingo wrote:
> I don't see it as such a big problem to play "fast and loose" with
> types, honestly... one day we'll have native compilation, and it's all
> just words there.

(Sorry, as a former compiler guy, I find my "portability" buttons  
being pushed here....)

Words with what representation?  Take a look at SCM2PTR and  
PTR2SCM ... for the old Cray systems.  As the comment above the  
definition indicates, the machine has an unusual pointer  
representation.  Still compliant with the C spec, as far as I know;  
just not what you'd expect from most machines.

We've got code using SCM2PTR and PTR2SCM in some places.  We've got  
code simply casting values in other places.  Unless the uses are  
carefully matched up to do the corresponding conversions in both  
directions, we're practically guaranteeing that the code will never be  
portable to the old Cray.  Even without that, I'm skeptical whether a  
Cray port of BDW-GC would be able to process our SCM objects there,  
since apparently our SCM objects are represented rather differently  
from native pointers.

We also cast function pointer types in places.  Pointers are not  
required to all have the same representation, nor to be passed or  
returned in function calls the same way.  There are also ABIs where  
pointers are passed around one way, and integers another way.  Take  
the address of a function with one kind of argument, and call it  
through a pointer to a function type with a different argument, and  
the calling sequence may not match how the function attempts to access  
its arguments.

Among modern general-purpose computers, the behavior's going to be  
pretty consistent -- to some people, "modern general-purpose computer"  
means x86 only, *maybe* one or possibly two other architectures,  
definitely a flat address space and uniform pointer representations  
the size of some standard integer type -- but try porting to older  
systems or some embedded processors, and some of the assumptions start  
to fail.  Do we even have a good idea what the assumptions we're  
making, beyond the basic requirements for a compliant C  
implementation, are?

I know it's tempting to ignore older systems and only worry about  
modern ones, but what of the people who might want to use Guile in  
other packages?  If we limit Guile's portability, we're also forcing  
that limitation on any such other packages.  One of my nagging  
concerns, which I have avoided investigating thus far, is whether  
Guile (and the BDW-GC library) will support all the platforms that  
Emacs does.  Do they support s390, sh3, or vax systems?  How about AIX  
4.2?  All of those are listed in the configure script for Emacs.  If  
someone revives the VMS port of Emacs, will they be able to port Guile  
and libgc (and libunistring and ...)?

The advantage of the STRICTNESS=2 code is that it forces additional  
discipline; simple casts can't paper over all the conversions.  It may  
seem like an annoyance to treat "SCM" and "void *" and "int" as  
requiring explicit conversions, but if someday someone tries porting  
to a platform like the old Cray, C code written with the assumption  
that "it's all just words (and we know what the representations look  
like)" may cause them no end of headaches.  Such an assumption *is*  
valid when we start looking at code generation for specific  
architectures.  But despite any cracks about C being a "high level  
assembly language", it *is* more abstract and such assumptions don't  
hold true for C in the general case.

If all we were discussing was whether the "guile" program should be  
available on older platforms, that would be one thing.  But we're  
talking about the extension library we want to promote for widespread  
use, in GNU programs and presumably elsewhere.  Should we really tell  
people, "you have to choose between portability to these old or  
uncommon platforms, and being able to use this extension library"?   
Especially if they're already supporting old platforms and not yet  
supporting Guile?

In my not-so-humble opinion, the onus should be on us to keep the  
Guile library as portable as possible (and push implementors of the  
libraries that libguile depends on in the same direction), and leave  
it to the application writers to decide what they want to do in terms  
of supporting old or unusual platforms, rather than having us impose  
limitations on them.

</soapbox>

I still don't have any specific proposal to make STRICTNESS!=1 work  
throughout our code, but I do expect it would be somewhat intrusive in  
places.  (For example, some macros that do "interesting" things with  
the values they're passed, I'd probably want to change to inline  
functions, at least when BUILDING_LIBGUILE under gcc, so we can do  
type checking of the supplied values, and then add conversion calls or  
casts or whatever as necessary.  The static initialization macros  
would almost certainly need changes.)  So unless I've swayed some of  
the maintainers, I'm not going to spend much more time on it.

In fact, if the general opinion is "screw the unusual platforms, let's  
hard-code the default STRICTNESS=1 case and get rid of the rest so  
people like Ken stop trying to play with it", I'm also willing to do  
the coding for that, too.  But as I've indicated, I do think it's the  
wrong direction....

Ken