Page MenuHomeFreeBSD

Change dsize to size_t.
AbandonedPublic

Authored by ed on May 31 2016, 2:39 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Oct 13, 10:49 AM
Unknown Object (File)
Mon, Oct 13, 9:11 AM
Unknown Object (File)
Tue, Oct 7, 12:03 PM
Unknown Object (File)
Mon, Sep 22, 4:40 PM
Unknown Object (File)
Wed, Sep 17, 5:11 PM
Unknown Object (File)
Sep 9 2025, 9:44 PM
Unknown Object (File)
Aug 18 2025, 1:27 AM
Unknown Object (File)
Aug 13 2025, 4:24 AM
Subscribers

Details

Reviewers
kib
cem
pfg
Group Reviewers
manpages
Summary

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.

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

ed retitled this revision from to Change dsize to size_t..
ed updated this object.
ed edited the test plan for this revision. (Show Details)
ed added reviewers: pfg, cem.

Don't forget to update the manpage as well.

cem edited edge metadata.
This revision is now accepted and ready to land.May 31 2016, 3:53 PM
pfg edited edge metadata.
kib requested changes to this revision.May 31 2016, 5:16 PM
kib added a reviewer: kib.
kib added a subscriber: kib.

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.

This revision now requires changes to proceed.May 31 2016, 5:16 PM
In D6660#140539, @kib wrote:

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.

In D6660#140539, @kib wrote:

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.

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?).

In D6660#140547, @pfg wrote:
In D6660#140539, @kib wrote:

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.

For the typical jails, that is not a problem as jails carry their own libc.

How this is relevant at all ?

In D6660#140544, @ed wrote:
In D6660#140539, @kib wrote:

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.

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.

In D6660#140561, @kib wrote:

Hm, yes. But you cannot depend on the padding being initialized.

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.

In D6660#140562, @ed wrote:

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.

In D6660#140560, @kib wrote:
In D6660#140547, @pfg wrote:
In D6660#140539, @kib wrote:

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.

For the typical jails, that is not a problem as jails carry their own libc.

How this is relevant at all ?

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. ;)

In D6660#140635, @pfg wrote:
In D6660#140560, @kib wrote:
In D6660#140547, @pfg wrote:
In D6660#140539, @kib wrote:

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.

For the typical jails, that is not a problem as jails carry their own libc.

How this is relevant at all ?

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.

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.

In D6660#140636, @kib wrote:
In D6660#140635, @pfg wrote:
In D6660#140560, @kib wrote:
In D6660#140547, @pfg wrote:
In D6660#140539, @kib wrote:

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.

For the typical jails, that is not a problem as jails carry their own libc.

How this is relevant at all ?

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.

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.

In D6660#140636, @kib wrote:
In D6660#140635, @pfg wrote:
In D6660#140560, @kib wrote:
In D6660#140547, @pfg wrote:
In D6660#140539, @kib wrote:

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.

For the typical jails, that is not a problem as jails carry their own libc.

How this is relevant at all ?

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.

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.

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.