On Mon, Jun 25, 2007 at 08:03:26PM -0400, John Belmonte wrote: > Lua does not use long double. I think LUAI_USER_ALIGNMENT_T affects > memory allocated for userdata (i.e. alignment of pointer returned by > lua_newuserdata). If userdata is going to be a struct which includes a > long double, updating the macro may be significant.
sure > We know this bug is a false positive and can be closed. The question > raised is what happens when some Linux distributions start "fixing" that > macro-- does it affect binary compatibility of the Lua core library or > compiled Lua code? Hopefully not, but we'd have to check with the code > or Lua authors to confirm. sure, I will prepare a mail for the mailing list as soon as the following point is clear to me. > Regarding your #2, a complex test of architecture and glibc version is > not necessary. It's enough to always put long double in the struct if > the compiler supports the type. Since gcc does, and the Lua "linux" > target uses gcc, I propose that it be enabled for that target. But I > want it to happen upstream so there is consistency between distros. Right, but what still needs to be dig is *if* the architectures for which libc 2.5 increases the size of long doubles do need long double alignement. I did an exam about architectures and assembly many years ago, but IIRC it really depends if these archs have a one shot instruction that fetches 128 bit at once or not in combination with their bus. If a long double fetch is compiled into two 64 bit fetches, you really need to be aligned only on doubles. If you are allowed to fetch 128 bit at once and the bus needs them to be aligned, LUAI_USER_ALIGNMENT_T needs some tweaking. So, I was hoping in a reply by the bugreporter saying if these arch need 128 bit alignement or not. Cheers. -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
