On Tue, 2011-09-27 at 11:36 +0200, Kean Johnston wrote: > On 9/27/2011 9:08 AM, Steve Frécinaux wrote: > > Won't you break ABI if you're changing the layout of the struct on > > linux/unixes? As I understand this is not an issue on Windows since > > everyone ships the libraries with the binary, but it is on Linux.
I was just about to write a reply mentioning this -- glad someone else brought it up. :) I disagree that we don't have an ABI to maintain on Windows. I think people on Windows are somewhat likely to download precompiled binary versions of our DLLs for use with developing their software (since the build process is so complicated). We can easily introduce extremely difficult-to-debug situations for people who assumed that the DLL was binary-compatible with the old one. > Nope. On linux there IS no ABI to break - everything is #define'd to its > libc name - so there is no real g_stat(). Any existing code out there will > just be calling stat(). If we make this change however we will be > introducing an ABI that will need to be maintained which is why its > important everyone agrees the data types are wide enough. While I mostly agree with this, it's only true in the case that both the code calling g_stat() and the code inspecting its result are always in the same codebase. If there is any API that takes a 'GStatBuf *' then that ABI will change as a result of recompiling against the new GLib (ie: recompiling a library with no code changes will change the ABI of the library). I'm not sure there are any cases of this, but it's something to be aware of. A more practical concern, however, is the fact that GStatBuf was only introduced somewhat recently: http://git.gnome.org/browse/glib/commit/?id=1229281d95802c4c190284c7d331f67194a2553e This means that there is an awful lot of valid existing code (including within GLib itself) that looks like this: { struct stat buf; g_stat (filename, &buf); } which (if I understand your proposal correctly) would be badly broken. Cheers _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list