[tor-bugs] #22410 [Core Tor/Tor]: ensure that uint8_t is unsigned char

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat May 27 10:50:52 UTC 2017


#22410: ensure that uint8_t is unsigned char
--------------------------+------------------------------------
 Reporter:  catalyst      |          Owner:  catalyst
     Type:  defect        |         Status:  needs_review
 Priority:  Medium        |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:  #6877         |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by cypherpunks):

 Replying to [comment:3 catalyst]:
 > The "best" alternative is unsigned char, but that's an unwieldy 13
 characters vs 7 characters for uint8_t or 6 for u_char.  POSIX guarantees
 that uint8_t exists but not that it's identical to unsigned char.  The
 best abbreviation for unsigned char is probably u_char, but no standard
 guarantees that it exists (though it usually does on BSD-derived
 platforms).
 Comparing the length of the keywords is a bad way of choosing data types.
 > If uint8_t is an extended integer type rather than unsigned char (which
 is admittedly unlikely), it won't have the privileged aliasing properties
 of unsigned char so code that casts pointers to other types to pointers to
 uint8_t might violate the strict aliasing rules and produce undefined
 behavior.
 I agree with the possibility of violating strict aliasing. However, i
 assume (yes, i know i should never) these pointers are dereferenced at
 some point which is always undefined behavior when the old and new type
 differs so the point is moot.
 > If you think it's better to use u_char and define it ourselves on
 platforms where it doesn't exist, I think that's a reasonable alternative
 too.  (I think uint8_t is marginally better on the portability front
 because I think we effectively require POSIX already.)
 I don't care about the data type names (any renaming can easily be done
 using `typedef` if preferred). IMO it's more important that the data type
 matches the type of data it holds and the code handling these data types
 is built around these data types in order to keep casting to a minimum
 (preferably none).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22410#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list