From: Mike H. <mi...@pl...> - 2005-10-12 17:57:34
|
On Wed, 2005-10-12 at 11:41 -0500, Ethan Blanton wrote: > See, it's stuff like this that makes me itchy. The whole point of > writing programs in a higher level language is that you don't have to > care about function calling conventions, etc. I'm not necessarily > concerned that one day Linux 2.6.x with glibc 2.3.5 is all of the > sudden going to change calling conventions; what I'm more concerned > about is that some platform is going to misdetect AMD64 versus x86, > and go plooey ... and then it will be non-obvious why everything is > completely broken and there are invalid opcode errors and ... etc. > (Don't tell me that AMD64 wouldn't give an invalid opcode because blah > blah blah, it was an example that people are familiar with.) Sure, that is a theoretical risk. But relaytool is only actually used if it's installed (by Tim, for instance) - otherwise a configure check simply defines the whole thing away. So if you don't actually have "relaytool" in your path it makes no difference. > ABIs change. That's fine if the supporting code changes, too, but > this is why I maintain that such hacks belong in libc itself, or in > ld. The C ABI does not change, however (at least not on x86). We'd be in trouble if it did! > I would certainly prefer that, myself. The big trouble is making sure > it works on *BSD, and MacOS X, and IRIX, and Solaris, and etc. etc. I will try and write a patch for that soon. Though as you note, it may not work on OSX, but then it isn't needed there either. thanks -mike |