danielmarjamaki added a comment.
> Typically in such cases bug visitors should be added/improved until it is
> clear from the user-facing report why does the analyzer think so. They'd
> highlight the important events, prevent path pruning, and potentially
> suppress reports if the reason is discovered to not be valid.
Thanks! But in this case I do not think that my code works well.
I have reduced the test case:
#include <stdio.h>
#define LIBCERROR_MESSAGE_INCREMENT_SIZE 64
#define LIBCERROR_MESSAGE_MAXIMUM_SIZE 4096
int get_print_count();
void foo( )
{
size_t message_size = 0;
size_t next_message_size =
LIBCERROR_MESSAGE_INCREMENT_SIZE;
int print_count = 0;
while (1)
{
if( next_message_size >= LIBCERROR_MESSAGE_MAXIMUM_SIZE )
{
next_message_size = LIBCERROR_MESSAGE_MAXIMUM_SIZE;
}
message_size = next_message_size;
print_count = get_print_count();
if( print_count <= -1 )
{
next_message_size += LIBCERROR_MESSAGE_INCREMENT_SIZE;
// <- Assigned value is garbage or undefined
}
else if( ( (size_t) print_count >= message_size ) )
{
next_message_size = (size_t) ( print_count + 1 );
print_count = -1;
}
else
{
int error_string_size = (size_t) print_count + 1; // <-
The result of the '+' expression is undefined
}
if( message_size >= LIBCERROR_MESSAGE_MAXIMUM_SIZE )
{
break;
}
}
}
I guess it's best that I rewrite my logic in a new check.
But well I have the feeling it could take a couple of days before I have
something new..
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D92634/new/
https://reviews.llvm.org/D92634
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
