Re: Cautionary tale: bad NTP client, bad NTP clock, bad date handling, C ints
Ivan Sergio Borgonovo <[email protected]>
| Newsgroups | gmane.org.user-groups.linux.cabal |
|---|---|
| Organization | http://www.WebThatWorks.it |
| Message-ID | <[email protected]> |
On 3/27/24 2:01 AM, Rick Moen wrote: > The 2038 problem happens because when the first bit of a 32-bit value is > 1 and you use it as a signed integer, it’s interpreted as a negative > number in 2’s complement representation. But C has no protection from > treating the same value as signed in some contexts and unsigned in > others. If you start with a signed 32-bit integer with the value -1, it > is represented in memory as 0xFFFFFFFF. If you then use it as an > unsigned integer, it becomes the value 4,294,967,296. Oh to clarify... C has protection as shown in previous email against mixing signed and non signed types... it doesn't have protection against arithmetic overflow. Some interpreted language just support "arbitrary precision", they just extend the type. This not only has a cost, but generally doesn't make your code safer. Most of the times it is not intended you overflow, and eg. if you're carrying on a long computation and an overflow will waste all your previous computation, you'd probably better optimizing for the right type. "arbitrary precision" should be a conscious choice/situation for a specific set of problems (when you're really dealing with numbers with a lot of digits and you want them ALL eg. crypto [*]) or left for prototyping. Other like Rust will cause an exception in debug mode but behave like C in release mode. [*] you do math very differently and most of the times it's not a mater of arbitrary length but rather length that don't fit in the CPU registers. So again you optimize accordingly to the specific problem. -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net _______________________________________________ conspire mailing list [email protected] http://linuxmafia.com/mailman/listinfo/conspire