On 14-May-2005, Ken Raeburn wrote:
| > I think we should assume in advance that we'll hit trouble with this | > on some platforms. Otherwise it's just another hiccup to push people | > away from trying Guile out.
| | *sigh* I was afraid of that. So when do we start requiring "real" | ANSI C support? :-(
Can you point to a widely used compiler that will actually have trouble with this? If not, then maybe it is not worth worrying about?
No I can't. But I know that we intermittently get unexpected build errors reported on the mailing list for even fairly mainstream OSs such as Solaris and HP-UX, and recently OS X, so I was just advising caution in order to avoid introducing a possible roadhump for people off the GNU/Linux/gcc mainline. Also, in my own experience (which is reasonable) I've never seen "#define foo foo" used before, so I have no personal feel for how well supported it is. (And you have to agree that it is an edge case, surely?)
However ... when advising as above, I hadn't realized that the reported names would be wrong. Now that I realize that, I think it is worth using "#define foo foo" and handling any problems if they arise. (We have future options, if we need them, for using configure tests to test support, and adding a suffix where necessary.)
| Doing this means the compile-time messages will give the wrong symbol | names. They'll be close to the names used by the application, but not | the same. Still, getting messages that are close is probably better | than explaining to people why this strange use of the preprocessor is | actually valid and it's their compiler that's broken. I wonder if it's | really a problem these days, though, a decade and a half after the spec | was published....
Having the messages use the wrong names might cause a lot more confusion than having to explain to people that their compiler is broken.
Yes, agreed now.
Neil
_______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
