[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 <jxyang@cs.utah.edu> 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
> dereference.\n");
>> 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.