[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [csmith-dev] version 7d6fae9: x = x = .;

Function return is a implicit sequence point in C99 (while in C++ it is explicit). Therefore in the case of x = f(x = 2), I believe there are actually two sequence points to make it defined


x == 2

--------  sequence point 1


-------  sequence point 2

x = return value of f


I was actually thinking of the same question: how does the sequence point, a cryptic feature of C/C++, be useful to other languages, from a random program generator’s point of view. Currently the sequence point rules are hardcoded in Csmith. I believe we have to separate out that part, and the effect analysis associated with it, to make Csmith extendable to other languages.





From: Pascal Cuoq [mailto:pascal.cuoq@gmail.com]
Sent: Monday, July 25, 2011 4:00 AM
To: Xuejun Yang
Cc: csmith-dev@flux.utah.edu
Subject: Re: [csmith-dev] version 7d6fae9: x = x = .;


On Sun, Jul 24, 2011 at 11:32 PM, Xuejun Yang <jxyang@cs.utah.edu> wrote:

I believe this problem is fixed in commit cc2104.


I am sorry that I can't confirm that yet, but the reason why I can't

is one you will like: previously, my test script would fill

its working directory of problematic programs in a few seconds,

now it fills its working directory of programs that I believe to

be non-problematic. That is, it finds precision bugs in Frama-C.


Just to be clear, we all agree that the following line is ok, right?


x = f(x=2);


Because Csmith generates them and the development version

of Frama-C warns (I believe wrongly) on them.


A meta-remark for the philosophers: are we all spending a

lot of time for not much here? One of the discussions at

the SCAM conference that I like for its discussions was

whether we shouldn't all be working on Java rather than

previous generation, difficult languages that will be obsolete

before we produce satisfactory analyses for them.

I do not fully agree with that point of view: first, Java has

its own, different, difficulties. Second, many static analysis

techniques are more mature than the statement implies,

and can be made to work now in some contexts, so

it's a good idea to work on whatever languages are used now.


Still, the existing C code whose correctness matters

does not do "x = f (x=2);". Perhaps that part of the

C language should be considered like the obsolete,

difficult language unworthy of working on.


Anyway, everyone has to have a hobby. This one is

as good as many.


Congratulations on the quick fix, we'll try to match

it with a precise analyzer as soon as we can.