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....
