You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
since the later might lead into UB since singed overflow is not defined and might not work as expected if optimized and the compiler chose to do the substraction and the comparison on an larger type.
example:
loop1: is the working one (with magic offset) (magic offset can be written as ((T)~0)>>1 or ((T)0-1)/2)
loop2: works for signed values
loop3: is allways kindof wrong
the c off all loops is expected to equal the number of loops (300) or 0 (if TN_OFFSET if defined negative)
Details
#include <stdio.h>
#include <stdint.h>
#define TN_OFFSET (50)
typedef uint8_t clock_time_t;
int main(void){
volatile clock_time_t t = 0;
volatile clock_time_t n = 0;
const clock_time_t magic_offset = (((clock_time_t)~0) >> 1);
{
int c = 0;
for (int i = 0 ; i < 300; i ++ ){
//i will overflow into t and n
t = i;
n = i - TN_OFFSET;
if ((clock_time_t)(magic_offset + n - t) < magic_offset){
c++;
}
}
printf("loop 1 c:%d \n", c);
}
{
int c = 0;
for (int i = 0 ; i < 300; i ++ ){
//i will overflow into t and n
t = i;
n = i - TN_OFFSET;
if ((clock_time_t)(n - t) < 0){
c++;
}
}
printf("loop 2 c:%d \n", c);
}
{
int c = 0;
for (int i = 0 ; i < 300; i ++ ){
//i will overflow into t and n
t = i;
n = i - TN_OFFSET;
if ((n - t) < 0){
c++;
}
}
printf("loop 3 c:%d \n", c);
}
printf("%d\n", magic_offset);
return 0;
}
Hi @obgm: since @boaks detected this issue though reading the code, I described it, @boaks developed the fixing PR (hence he solver what he read by writing) and I gave my cent to it (correct overflow handling regardless of singnedness).
I think we can consider this solved.
I never had a test for that other than reading. (I think this would require a Multiday session of DTLS)
Activity
kfessel commentedon Feb 7, 2022
read later comment
is true if (now > node->t) (taking overflow semantic into account)
(assuming (clock_time_t is some kind of unsigned integer -> defined overflow)
kfessel commentedon Feb 7, 2022
I did a bit of testing using https://godbolt.org/z/qKPeoazhr
overflow seems to be applied when the whole calculation is done ->
calculate an offset
add offset to difference then cast to _t and compare to offset
(this works as well if for any reason clock_time_t would be signed)
boaks commentedon Mar 29, 2022
Prints
I'm not sure, why
(((clock_time_t)0 - 1) / 2)should be used?boaks commentedon Mar 29, 2022
OK, it's not that simple as in java ;-).
kfessel commentedon Mar 29, 2022
should be used
instead of
since the later might lead into UB since singed overflow is not defined and might not work as expected if optimized and the compiler chose to do the substraction and the comparison on an larger type.
example:
loop1: is the working one (with magic offset) (magic offset can be written as ((T)~0)>>1 or ((T)0-1)/2)
loop2: works for signed values
loop3: is allways kindof wrong
the c off all loops is expected to equal the number of loops (300) or 0 (if TN_OFFSET if defined negative)
Details
compiler explorer example
dtls.c, netq.c: consider 32bit time overflow.
dtls.c, netq.c: consider 32bit time overflow.
dtls.c, netq.c: consider 32bit time overflow.
dtls.c, netq.c: consider 32bit time overflow.
dtls.c, netq.c: consider 32bit time overflow.
obgm commentedon May 27, 2022
@kfessel did you have a change to check with PR #131 merged?
kfessel commentedon May 27, 2022
Hi @obgm: since @boaks detected this issue though reading the code, I described it, @boaks developed the fixing PR (hence he solver what he read by writing) and I gave my cent to it (correct overflow handling regardless of singnedness).
I think we can consider this solved.
I never had a test for that other than reading. (I think this would require a Multiday session of DTLS)
boaks commentedon May 27, 2022
I think, adding some unit test for the calculation may be an idea. But for now, there is too much other stuff already pending.
obgm commentedon May 27, 2022
@kfessel sorry for the confusion