-
Notifications
You must be signed in to change notification settings - Fork 479
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
Use more appropriate types for base, precision and width #116
Comments
@mickjc750 : This issue report is inspired by your commit b907595 , where you've done something similar. Which of the types do you believe is more appropriate? |
For base, just a simple uint8_t, as there's no arithmetic performed on base
which would require masking it down to 8bits on a 32bit cpu.
For precision and width, uint_fast8_t would provide a slightly smaller (and
faster) executable than uint8_t , as there are places where precision is
decremented.
In the ntoa(), I'd recommend using literal values %2 %8 %10 %16 rather than
%base, as it saves performing a division. It's a minor size increase for a
big performance increase.
…On Sun, Aug 1, 2021 at 6:03 AM Eyal Rozenberg ***@***.***> wrote:
@mickjc750 <https://github.com/mickjc750> : This issue report is inspired
by your commit b907595
<b907595>
, where you've done something similar. Which of the types do you believe is
more appropriate?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#116 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJ2OLLVCCELVM7VD5DVY2TT2RJIBANCNFSM5BKKNNDA>
.
--
--
Michael Clift - Design Engineer.
Clift Innovations Pty Ltd
Suit 10/13 Walkers Road
Nunawading, VIC 3131
ABN 24 286188328
Tel: +61 3 9877 3109
Fax: +61 3 9999 1406
Mob: 0417 613 680
Email: ***@***.***
Web: www.clift.com.au
*****************************************************************************
PRIVATE AND CONFIDENTIAL
This e-mail and any files transmitted with it are intended solely for the
use of the addressee(s) and may contain information that is confidential or
privileged. If you receive this e-mail and you are not the addressee(s),
please disregard the contents of the e-mail, delete the e-mail and notify
the author immediately.
*****************************************************************************
|
@mickjc750 : You've packaged several issues into one... anyway, are we sure width always fits in a uint8_t ? Also, please try to avoid commenting by replying to the email and quoting everything. If you reply, please quote nothing. Otherwise we get a huge quoted-part of your comment which doesn't add any new information. |
Not 100% sure. It really comes down to opinion as to what a reasonable
width limit is.
Printf is generating text, 255 sounds like a reasonable limit for the
width of a number. Or the width of a field with a %s aligned in it.
|
… constants for numeric base variables; no functionality change.
… constants for numeric base variables; no functionality change.
… constants for numeric base variables; no functionality change.
The only base values the library support are: 2, 8, 10, 16. And yet - we pass it around in larger types, and not even the same type everywhere.
So, why should we not just use a single small type for the base? Say,
uint_least8_t
oruint_fast8_t
?The text was updated successfully, but these errors were encountered: