[conspire] Cautionary tale: bad NTP client, bad NTP clock, bad date handling, C ints

[Ivan Sergio Borgonovo]

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