[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Now that SCM type is a union...
Re: Now that SCM type is a union...
Sun, 14 Aug 2011 22:04:19 -0400
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....