Date: Wed, 30 Jul 2014 11:53:11 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: regoff_t is broken On Wed, Jul 30, 2014 at 05:09:06PM +0200, Jens Gustedt wrote: > Hi, > perhaps I have missed a discussion on that. > > commit 8327ae0cb23b799bc55a45e0d4bd95f5a2b1cdf1 > > breaks ABI compatibility with glibc for regexp on x86_64 architectures > by privileging i386. This commit didn't change anything with regard to the issue you're experiencingx. The x86_64 definition was mismatching with glibc's definition both before and after the commit. > To summarize the situation, > > - POSIX wants ptrdiff_t or ssize_t for this Strictly speaking, POSIX just wants a signed type that is wide enough to store the positive range of ptrdiff_t and ssize_t. It need not be the same as either of these. > - glibc has int, which happens to be a compliant type on i386, but > not on x86_64. Right. > - previously musl had long which works on x86_64 and breaks ABI with > glibc on i386. It actually only affected the C++ ABI, unless you want to consider different types with same size, representation, and argument passing convention an ABI issue. It was changed for compatibility with the C++ ABI from glibc (but obviously only on 32-bit archs, since on 64-bit glibc has a broken definition). > - now musl has _Addr which is POSIXLY ok on i386 but breaks glibc ABI > on x86_64. > > I wonder if there are no other ways around this. There's no way around it without a wrapper library or compatibility layer in the loader. glibc's type is just wrong. I have an open bug report on it requesting that they fix the type and bump the version on regexec, but it hasn't gotten any attention: https://sourceware.org/bugzilla/show_bug.cgi?id=12900 marked duplicate of: https://sourceware.org/bugzilla/show_bug.cgi?id=5945 > Also, I think there should be big flash lights somewhere that make > linking musl against a program that was compiled with glibc regex > impossible or so. Where would you suggest putting this warning? Eventually status/level of glibc binary compatibility should be in the manual, but I haven't gotten that far in the manual. The wiki is an easy place to put it for now but it might not get noticed by users. Of course wherever we advertise limited level of glibc ABI compatibility, we could and probably should have a link to such caveats, wherever they're documented. > Unfortunately that broke my code in a way that was really hard to > trace. The musl type being wider than the glibc type, I got a > corrupted my stack somewhere near the start of my application. Did > cost me a day or so to find out where that came from. Support for using glibc-linked binaries with musl is incomplete, but I agree this should be better-documented somewhere. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.