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

Re: [csmith-project/csmith] 717b1c: Fixed a bug related to --no-math64 and --no-longlo...



Here's what I propose:

Very-short term solution (like, now): fixed mapping from "Csmith internal integer types" to fixed-width types.

Medium-term: Csmith internal types map directly to C integer types. Let me know when this wants to be done and I'll rewrite the safe math code.

John





On 05/04/2011 06:06 PM, John Regehr wrote:
No. You guys are not listening. THE HOST PLATFORM DOES NOT MATTER. We
are generating programs that might run anywhere.

Am I speaking unclearly? I can try to say this a different way but I
would prefer that you simple read what I am writing and try to
understand what I am telling you.

The x86_64 variable has to be killed, it represents a design error.
Every piece of code like the one below has to be killed.

John




On 05/04/2011 05:57 PM, Yang Chen wrote:
It's not about printf(), but the print-routine in the generator. In more
detail, here is the relevant code:

void OutputType(ostream &out)
{
type = TLong;

if (type == TLong) {
if (x86_64)
out << "int64_t";
else
out << "int32_t";
}
}

- Yang

John Regehr wrote:
Problems with printf() are easy to avoid by casting all types to long
long and using the %lld format string.

John


On 05/04/2011 05:35 PM, Yang Chen wrote:
John Regehr wrote:
There are places the random generator must decide whether a long is 4
bytes or 8 bytes. If you want to make it 4 bytes for all platforms, I
have no issue with that.

I don't understand why we need to know the size of a long at program
generation time.

John

If I am correct, once we get rid of outputing fixed-width integers, we
don't need to be aware of that. In our current framework, the only
place
to consider sizeof(long) is where the generator determines to print
"int64_t" for long on x86-64, or print "int32_t" for long on x86 (I
could be wrong, Xuejun could correct me).

- Yang