Re: Now that SCM type is a union...

[Ken Raeburn]

On Aug 14, 2011, at 16:10, Andy Wingo wrote:
>> * We should expect some Guile applications to be in C++.  What
>> versions of the C++ spec should Guile support?
> 
> Dunno.  What do other languages have to do with Guile's C interface?
> Specifically what does C++ have to do with this?  (Serious question.)

Most languages, nothing; they can't directly use the C headers, even if there's 
another way to tell, for example, the GNU Ada compiler what the Guile ABI looks 
like.  C++ is another matter -- at least, the languages are sufficiently 
compatible that people will try.  And we've already got the 'extern "C"' bits 
in libguile.h to help support it.

The C++ compiler will treat the calls to extern "C" functions specially, using 
different name-mangling techniques (and I think different function-calling 
interfaces are even possible, but I'm not sure).  But the header still needs to 
be parsed as C++, and that's not always a strict superset of the latest and 
greatest C spec.


> 
>> * Shouldn't there be testing to catch this?  (C89 mode, C99 mode,
>> different C++ specs, enabling various compiler warnings -- for
>> whatever compiler is in use -- and make them fatal, any interesting
>> ways one might want to use libguile in an application that might
>> stress compatibility issues.)  I mean automated testing, not just
>> Cedric. :-)
> 
> Perhaps :)  Interested volunteers are welcome to set this up :)

I've done it before for other projects... you just need to add to the test 
suite a few files to be compiled with certain compilers and compiler options -- 
perhaps repeatedly with different options -- and make sure they compile.  If 
you want to get really fancy, link and run some trivial programs, but generally 
compiling with lots of warning options is good enough, at least for C.  For 
GCC, for example, I'd start with "gcc -Wall -Wextra -Werror -pedantic" and "g++ 
-Wall -Wextra -Werror -pedantic", and add more interesting options from there, 
then multiply that by the various "-std" options available; the Solaris 
compiler has a different syntax for warning options, but it too can be told to 
enable various warnings and make them errors.

I'll see about setting up something simple...

> 
>>> I will take a look at this issue soonish, but your help (and Cedric's)
>>> in debugging it is most appreciated :)  I would love to keep the union
>>> as the "normal" SCM definition, but that might not be possible.
>> 
>> Regardless of the validity, there are popular compilers out there now
>> which do not support this, when used in modes people may need or want
>> to use.  The installed headers need to adhere to higher standards in
>> terms of portability problems and warnings than the library source,
>> where we can dictate some of the compiler options.
> 
> Agreed.  And AFAIK there are some ABI differences for returning unions
> versus returning uintptr_t, so unfortunately it can't be a question of
> ifdefs in Guile's C interface, it seems.  I'll work on this, but if you
> have any suggestions as to the proper fix, they are most welcome.

I don't see anything really clean... separate macros (same value, different 
syntax) for static initialization vs use in run-time evaluated expressions 
might be one way to keep the union type.  For non-GNU C89, the latter could 
expand to the return value of a function call, which sucks for performance but 
keeps the API and ABI intact.  For GCC in pedantic C89 mode, the __extension__ 
keyword will tell it to shut up about intentionally-used GNU extensions.  There 
are other places where the union value won't be useable -- for example, case 
labels in switch statements need integer values.

If you want one macro for static initialization and for normal expressions, I 
think it's got to be an arithmetic or pointer type....