Prefer ptrdiff_t over ssize_t#1448
Merged
copybara-service[bot] merged 1 commit intomasterfrom May 2, 2025
unknown repository
Merged
Prefer ptrdiff_t over ssize_t#1448copybara-service[bot] merged 1 commit intomasterfrom unknown repository
copybara-service[bot] merged 1 commit intomasterfrom
unknown repository
Conversation
`ssize_t` is a POSIX-defined type, not a C or C++ standard. `ssize_t` is not as useful of a type as it initially seems, as it only actually guarantees a range of [-1, `SSIZE_MAX`], where `SSIZE_MAX` is at least `_POSIX_SSIZE_MAX` (32767). `ptrdiff_t` is defined to be the type that results from taking the difference of two pointers. It is not guaranteed for it to be possible for all pointer differences to be represented as a `ptrdiff_t`; however, despite not theoretically having a much more stringent definition, it typically either meets or exceeds the utility of `ssize_t` on top of being a part of the C standard, thereby being usable outside of POSIX platforms. See, for example, this thread on the emacs-devel list: https://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00019.html Therefore, I suggest adopting `ptrdiff_t` instead. For any of the obvious platforms, it should be exactly the same as `ssize_t` but more portable. Neither `ssize_t` nor `ptrdiff_t` are guaranteed to have a superset of the range of `size_t`, so code that uses `ssize_t` OR `ptrdiff_t` to store `size_t` values should tread carefully; this is not safe and not guaranteed to work (e.g. loops that iterate backwards should probably be adjusted.) One usage of `ssize_t` is replaced with `int64_t` instead since it is more appropriate in that circumstance.
jnthntatum
approved these changes
May 2, 2025
ghost
deleted the
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
This resolves a portability issue for Windows/MSVC.
ssize_tis a POSIX-defined type, not a C or C++ standard.ssize_tis not as useful of a type as it initially seems, as it only actually guarantees a range of [-1,SSIZE_MAX], whereSSIZE_MAXis at least_POSIX_SSIZE_MAX(32767).ptrdiff_tis defined to be the type that results from taking the difference of two pointers. It is not guaranteed for it to be possible for all pointer differences to be represented as aptrdiff_t; however, despite not theoretically having a much more stringent definition, it typically either meets or exceeds the utility ofssize_ton top of being a part of the C standard, thereby being usable outside of POSIX platforms. See, for example, this thread on the emacs-devel list:https://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00019.html
Therefore, I suggest adopting
ptrdiff_tinstead. For any of the obvious platforms, it should be exactly the same asssize_tbut more portable.Neither
ssize_tnorptrdiff_tare guaranteed to have a superset of the range ofsize_t, so code that usesssize_tORptrdiff_tto storesize_tvalues should tread carefully; this is not safe and not guaranteed to work (e.g. loops that iterate backwards should probably be adjusted.)One usage of
ssize_tis replaced withint64_tinstead since it is more appropriate in that circumstance.Related issue: #768