On 2021-03-18 at 01:33:54, Ángel wrote:
On 2021-03-17 at 11:05 -0400, Daniel Kahn Gillmor wrote:
On Wed 2021-03-17 10:55:08 -0400, Daniel Kahn Gillmor wrote:
The mismatch between the variable in the sample CRC-24 generation
code
and the definition of the generator in the paragraph above has been
a
source of confusion for over 20 years.
I recorded this proposed minor cleanup as MR 39:
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/39
--dkg
What about using, instead of the 'long' type, which may mean quite
dfferent things, the uint_least32_t type defined in ISO C 7.18 ?
My preference here is uint32_t, since as a practical matter all modern
architectures offer that and implement it reasonably efficiently, and it
is much more commonly used. More recent languages like Rust and Go just
assume everyone has such a type, and in the unlikely event someone uses
a system that doesn't have it, they'll clearly know how to adjust.
However, I'm also fine with uint_least32_t or unsigned long. The
important thing is that we produce something that is (a) correct so that
it produces the right results, (b) conformant so that compilers don't
break it in the name of better optimizations during undefined behavior,
and (c) as simple and easy to understand as possible. Any option which
meets those requirements is satisfactory to me.
--
brian m. carlson (he/him or they/them)
Houston, Texas, US
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp