libsqlite: vxprintf: va_arg() integral types with their signedness specified #179
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ecified else a 64bit sqlite will sign-extend values with the 31bit set, which breaks idmap and presumably SMF in the cases where a property exists in this state.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
else a 64bit sqlite will sign-extend values with the 31bit set, which breaks idmap and presumably SMF in the cases where a property exists in this state, and does who knows what to smb.
@jclulow @citrus-it this is the idmap bug I've been chasing all week, idmap forms queries using
sqlite_mprintfand using the%uformat to format uids and gids. This turns out -- because of the bug here -- to sign-extend them if they have the 31bit set, which ephemeral IDs always do. This then causes them to fail in the future and for ephemeral IDs for a given SID to be constantly recreated.Anyway, the more important thing is that this seems to me like it means 64bit sqlite2 is just not a thing we can rely on, so both arm64-gate and illumos-gate actually need a sqlite3. arm64-gate in general, illumos-gate for any hope of 2038. What's the best way to communicate that? File a bug? get the 2038 IPD updated?
Also, should I fix this as here in the short term while I look at integrating sqlite3 per Bill's changes.