Displaying 3 results from an estimated 3 matches for "0xffff_ff00".
2018 Feb 12
2
[PATCH]Add address overflow check
...t; being hit by something else. That or your compiler is really broken.
I don't know how important it is in this case (probably pretty minor) but in general Ruikai's right.
It doesn't matter that pointers are unsigned; that fact that a pointer could have a "large" value like 0xffff_ff00 means that they can wrap if you do length checks the wrong way. The behaviour is completely defined - it just causes the code not to work as intended.
The "bad" way of doing a length check is
char* buf_start, buf_end;
unsigned len_to_check;
if (buf_start + len_to_check > buf_end)...
2018 Feb 12
0
[PATCH]Add address overflow check
...thing else. That or your compiler is really broken.
>
> I don't know how important it is in this case (probably pretty minor) but in general Ruikai's right.
>
> It doesn't matter that pointers are unsigned; that fact that a pointer could have a "large" value like 0xffff_ff00 means that they can wrap if you do length checks the wrong way. The behaviour is completely defined - it just causes the code not to work as intended.
>
> The "bad" way of doing a length check is
>
> char* buf_start, buf_end;
> unsigned len_to_check;
> if (buf_start +...
2018 Feb 09
3
[PATCH]Add address overflow check
Hi,
I came into a crash when using 32-bit `speexdec` and found that there's an
address overflow in function `print_comments()`:
static void print_comments(char *comments, int length)
{
char *c=comments;
int len, i, nb_fields;
char *end;
if (length<8)
{
fprintf (stderr, "Invalid/corrupted comments\n");
return;
}
end = c+length;