[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [csmith-dev] feature request: generate memory unsafe code
On Sun, Jun 19, 2011 at 8:25 AM, Xuejun Yang <email@example.com> wrote:
[Pascal Cuoq wrote:]
>> This is great. I have one question: does Csmith know,
>> when emitting a possible NULL/dangling access,
>> that it is emitting one, or only that it may be emitting one?
>> In the former case, it could provide some sort of oracle,
>> for instance:
>> p = NULL;
>> a = 3;
>> printf("When this line is reached, it is followed by a NULL
>> b = *p;
>> There are ramifications to this issue [...]
> Yes, Csmith knows when there is a potential null/dangling pointer
> dereference. But I hesitated to print a runtime message like you suggested
> because the message may interfere with differential testing of compilers.
> Instead I could print a comment in the random program right above the
> violating statement, what do you think?
I think macros are helpful, in this context.
#define MAY_BE_NULL(ptr) (puts("possible NULL dereference"), (ptr))
#define MAY_BE_NULL(ptr) (ptr)
p = NULL;
a = 3;
b = *MAY_BE_NULL(p);
That is, whenever we have a variable v_999 that is a possibly-null
pointer, Csmith should print it as "MAY_BE_NULL(v_999)" in rvalue
The above paragraph may want some adjustment if Csmith can actually
distinguish "possibly-null" pointers from "definitely-null" pointers.
Dereferencing a pointer that is only *possibly* null is not
necessarily a bug.