POSIX requires that this field has type size_t. This change only causes
breakage on 64-bit big endian platforms. Using symbol versioning to
prevent this breakage is not worth it in my opinion.
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 4050 Build 4093: arc lint + arc unit
Event Timeline
The change breaks libc ABI on all 64bit arches, this is not acceptable.
Think what happens if the structure is embedded into a user object.
On 64-bit architectures, this object already has four spare bytes at its end, right? Before and after this change, it's 16 bytes in size.
For the typical jails, that is not a problem as jails carry their own libc.
In general, this API is of little relevance though: linux and even Solaris have either removed it or deprecated it..
The change for stricter posix conformance may also be fixing bugs. Checking with opengrok, for example here:
http://src.illumos.org/source/xref/freebsd-head/lib/libc/db/hash/ndbm.c#106
we are assigning a size_t into dsize and it may not fit in an int (perhaps such values are more common now with big data?).
Hm, yes. But you cannot depend on the padding being initialized. It would for static objects, but not when the object is allocated dynamically or on stack. And the later is probably even larger objection that my initial thought: old binaries passing valid arguments suddenly appear to provide out of range values.
That's a good point. We could, if we're lazy bastards, just let the dbm_*() functions ignore the top 32 bits of dsize for now. So it is declared as a size_t, but only used as an unsigned int.
I do not see this as a useful behaviour. Prototype should reflect the function behaviour.
With the note about padding, I think that symbol versioning would handle the transition.
Just trying to evaluate the impact ... if it doesn't affect older executables (which are likely to be run in jails) it matters less if it breaks the ABI for an unreleased libc.
Of course if you manage to handle it with symbol versioning. it's much better.
Ah well ... I'll go back to do the unrelated things I usually do well. ;)
Likely or not, since FreeBSD 7 we provide the same-named libc.so.7 library, which serves all binaries from FreeBSD 7.0 up to the release date of the library.
Ah yes ... I had forgotten about those.
Duh .. I had completely forgotten about those! (advantages of using fresh ports when possible).
So let's abandon this change for now. Once FreeBSD 11 has been branched, I'll likely revisit this with a more exhaustive patch that uses symbol versioning to preserve compatibility.