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

["Xuejun Yang" <jxyang@cs.utah.edu>]

This is exactly my solution offers. When printing out the program, out data types naturally translate into "int8_t", "int16_t", why do you need to look up the platform info?

-Xuejun

> -----Original Message-----
> From: csmith-commits-bounces@flux.utah.edu
> [mailto:csmith-commits-bounces@flux.utah.edu] On Behalf Of John Regehr
> Sent: Wednesday, May 04, 2011 4:31 PM
> To: csmith-commits@flux.utah.edu
> Subject: Re: [csmith-project/csmith] 717b1c: Fixed a bug related to --no-math64
> and --no-longlo...
> 
> The solution is not to look at the host platform.
> 
> Why do I have to keep saying this?
> 
> John
> 
> 
> 
> On 5/4/11 4:28 PM, Xuejun Yang wrote:
> > As I said, the solution is representing integer types with sizes not names.
> Right now we have the following types:
> >
> >   	eChar,
> > 	eInt,
> > 	eShort,
> > 	eLong,
> > 	eLongLong,
> > 	eUChar,
> > 	eUInt,
> > 	eUShort,
> > 	eULong,
> > 	eULongLong,
> >
> > Changing them to int8, int16, int32... could eliminate the ambiguity once and
> forever. It requires a lot of find and replace though.
> >
> > -Xuejun
> >
> >> -----Original Message-----
> >> From: csmith-commits-bounces@flux.utah.edu
> >> [mailto:csmith-commits-bounces@flux.utah.edu] On Behalf Of John Regehr
> >> Sent: Wednesday, May 04, 2011 4:22 PM
> >> To: csmith-commits@flux.utah.edu
> >> Subject: Re: [csmith-project/csmith] 717b1c: Fixed a bug related to
> --no-math64
> >> and --no-longlo...
> >>
> >> The mistake here was looking at the size of an integer on the host
> >> platform.
> >>
> >> We need Csmith's output to depend ONLY on the command line options and
> >> seed, not anything else.
> >>
> >> I want you to make sure this is the case and also explain to me how you
> >> made sure.
> >>
> >> John
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 5/4/11 4:17 PM, Xuejun Yang wrote:
> >>> I made the change that letting "long" to have different sizes on different
> >> systems. Unfortunately I forget to disable generating "long" integers when
> >> no-long-long is enabled.
> >>>
> >>> If we want to remove the ambiguity, we need to internally represent our
> >> integer types with sizes but not names.
> >>>
> >>> -Xuejun
> >>>
> >>>>
> >>>> Please explain in more detail.
> >>>>
> >>>> The question is: What does the size of a "long" have to do with Csmith's
> >>>> decision whether or not to emit code containing the string "int64_t"?
> >>>>
> >>>> John
> >>>>
> >>>>
> >>>>
> >>>> On 5/4/11 4:03 PM, Yang Chen wrote:
> >>>>> On x86_64, long is 64 bits. I only considered long long before I fixed
> >>>>> the bug.
> >>>>>
> >>>>> - Yang
> >>>>>
> >>>>> John Regehr wrote:
> >>>>>> Can you explain this bug?
> >>>>>>
> >>>>>> John
> >>>>>>
> >>>>>>
> >>>>>> On 05/04/2011 02:56 PM, noreply@github.com wrote:
> >>>>>>> Branch: refs/heads/master
> >>>>>>> Home: https://github.com/csmith-project/csmith
> >>>>>>>
> >>>>>>> Commit: 717b1c973636333440d908fd6caa7111b8ccc285
> >>>>>>>
> >>>>
> >>
> https://github.com/csmith-project/csmith/commit/717b1c973636333440d908f
> >>>> d6caa7111b8ccc285
> >>>>>>>
> >>>>>>> Author: Yang Chen<chenyang@build3.cs.utah.edu>
> >>>>>>> Date: 2011-05-04 (Wed, 04 May 2011)
> >>>>>>>
> >>>>>>> Changed paths:
> >>>>>>> M runtime/csmith.h
> >>>>>>> M src/OutputMgr.cpp
> >>>>>>> M src/Probabilities.cpp
> >>>>>>> M src/Type.cpp
> >>>>>>>
> >>>>>>> Log Message:
> >>>>>>> -----------
> >>>>>>> Fixed a bug related to --no-math64 and --no-longlong
> >>>>>>>
> >>>>>
> >>>
> >