Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Silent narrowing conversion(s) from size_t to printf_size_t may bite us #87

Closed
eyalroz opened this issue Jan 22, 2022 · 3 comments
Closed
Assignees
Labels
bug Something isn't working resolved-on-develop A changeset fixing this issue has been commiutted to the development branch

Comments

@eyalroz
Copy link
Owner

eyalroz commented Jan 22, 2022

printf()-family functions have the questionable design choice of returning int as the number of characters printed, despite buffer lengths possibly being larger than INT_MAX.

In our implementation, this is compounded by us using an int-sized printf_size_t type for offsets and lengths within the buffer, corresponding to the final return type - while taking in a size_t for functions such as snprintf(). At the moment, we simply cast from the latter into the former type at various locations, never checking for overflow. This could theoretically result in us getting lengths of 0, or other short lengths, which will mess up our behavior.

We need to cast as early as possible, and discard the size_t inputs.

@eyalroz eyalroz added the bug Something isn't working label Jan 22, 2022
@eyalroz eyalroz self-assigned this Jan 22, 2022
eyalroz added a commit that referenced this issue Jan 22, 2022
…e_t` as soon as possible, taking care not to exceed the maximum representable value of `printf_size_t`. Also, no longer using `-1` magic numbers for the "maximum possible size/length".
eyalroz added a commit that referenced this issue Jan 22, 2022
…e_t` as soon as possible, taking care not to exceed the maximum representable value of `printf_size_t`. From that point onwards (or rather inwards) - only `printf_size_t` is used for lengths and positions/indices. Also, no longer using `-1` magic numbers for the "maximum possible size/length".
@eyalroz eyalroz added the resolved-on-develop A changeset fixing this issue has been commiutted to the development branch label Jan 22, 2022
eyalroz added a commit that referenced this issue Jan 24, 2022
…e_t` as soon as possible, taking care not to exceed the maximum representable value of `printf_size_t`. From that point onwards (or rather inwards) - only `printf_size_t` is used for lengths and positions/indices. Also, no longer using `-1` magic numbers for the "maximum possible size/length".
@phillipjohnston
Copy link

There are still some implicit casts on the development branch - I will create a PR for those.

@eyalroz
Copy link
Owner Author

eyalroz commented Jan 25, 2022

So, your PR #97 had one such cast - have you noticed others?

Also, in my defense, that cast was not that implicit - it was in an assignment; and it's where I want the cast to happen. But the PR is merged.

@phillipjohnston
Copy link

That was the only one, and I just used the warning term, not asking you to defend yourself :)

@eyalroz eyalroz closed this as completed Jan 25, 2022
eyalroz added a commit that referenced this issue Jan 26, 2022
…e_t` as soon as possible, taking care not to exceed the maximum representable value of `printf_size_t`. From that point onwards (or rather inwards) - only `printf_size_t` is used for lengths and positions/indices. Also, no longer using `-1` magic numbers for the "maximum possible size/length".
eyalroz added a commit that referenced this issue Jan 26, 2022
…e_t` as soon as possible, taking care not to exceed the maximum representable value of `printf_size_t`. From that point onwards (or rather inwards) - only `printf_size_t` is used for lengths and positions/indices. Also, no longer using `-1` magic numbers for the "maximum possible size/length".
eyalroz added a commit that referenced this issue Jan 31, 2022
…e_t` as soon as possible, taking care not to exceed the maximum representable value of `printf_size_t`. From that point onwards (or rather inwards) - only `printf_size_t` is used for lengths and positions/indices. Also, no longer using `-1` magic numbers for the "maximum possible size/length".
eyalroz added a commit that referenced this issue Jan 31, 2022
…e_t` as soon as possible, taking care not to exceed the maximum representable value of `printf_size_t`. From that point onwards (or rather inwards) - only `printf_size_t` is used for lengths and positions/indices. Also, no longer using `-1` magic numbers for the "maximum possible size/length".
eyalroz added a commit that referenced this issue Jan 31, 2022
…e_t` as soon as possible, taking care not to exceed the maximum representable value of `printf_size_t`. From that point onwards (or rather inwards) - only `printf_size_t` is used for lengths and positions/indices. Also, no longer using `-1` magic numbers for the "maximum possible size/length".
eyalroz added a commit that referenced this issue Feb 11, 2022
…e_t` as soon as possible, taking care not to exceed the maximum representable value of `printf_size_t`. From that point onwards (or rather inwards) - only `printf_size_t` is used for lengths and positions/indices. Also, no longer using `-1` magic numbers for the "maximum possible size/length".
eyalroz added a commit that referenced this issue Feb 21, 2022
…e_t` as soon as possible, taking care not to exceed the maximum representable value of `printf_size_t`. From that point onwards (or rather inwards) - only `printf_size_t` is used for lengths and positions/indices. Also, no longer using `-1` magic numbers for the "maximum possible size/length".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working resolved-on-develop A changeset fixing this issue has been commiutted to the development branch
Projects
None yet
Development

No branches or pull requests

2 participants