Re: [csmith-dev] feature request: generate memory unsafe code

[Pascal Cuoq <pascal.cuoq@gmail.com>]

On Sat, Jun 18, 2011 at 6:47 PM, Xuejun Yang <jxyang@cs.utah.edu> wrote:
> Pointer unsafe behaviors are allowed in Csmith (git commit 7e3325).

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: with the above instrumentation,
a NULL access only happens after a function call. That seriously limits
the generality of generated programs.

Anyway, there is always the possibility of comparing several
tools, for which instrumentation is not necessary.

> I am adding array OOB soon.

For OOB, one potential issue for comparing tools
is that a tool would be justified in warning
at the computation of the invalid pointer
(except if it's only one past) whereas other tools
may only warn when/if the invalid pointer is
dereferenced. When comparing tools of these
two categories,this means warnings in different
places when the pointer is dereferenced,
and warning against no warning if it isn't.

Similarly, one tool may allow out-of-bound
accesses to members of struct/unions and elements of
arrays as long as the memory access, computed with
the target platform size/alignment parameters, fall inside
a larger object that contains the first one. I mean that
it may allow:

int t[10][10];
struct { int a; int b; } s;

main(){
t[0][12] == t[1][2];
(&s.a)[1] == s.b;
return 0;
}

A tool such as Valgrind, working on object code, would
probably only be able to offer this behavior anyway.

Pascal