Change dsize to size_t.

[ed]

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.

[ed]

Don't forget to update the manpage as well.

[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.

[ed]

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.

[pfg]

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

[kib]

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 ?

[kib]

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.

[ed]

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.

[kib]

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.

[pfg]

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

[kib]

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.

[pfg]

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

[ed]

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.