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

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

What about pointers? Do you want to distinguish the size of pointer on different platforms?

-Xuejun

> 
> 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.
> 
> Generating regular C int types means we are getting rid of safe math functions.
> Are we ready for that?
> 
> -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:40 PM
> > To: csmith-commits@flux.utah.edu
> > Subject: Re: [csmith-project/csmith] 717b1c: Fixed a bug related to
> --no-math64
> > and --no-longlo...
> >
> > Yes, moving to fixed-width integers would solve the problem we are
> > talking about.
> >
> > But first, it is unnecessary.  The current framework is perfectly fine
> > as long as you don't look at the size of integer types.  Xuejun I will
> > keep saying this until I feel like you have understood what I am saying.
> >   Am I explaining it poorly somehow?
> >
> > Second, going to fixed-width types is counter-productive if we want to
> > start generating regular C integer types.  As I said, I think this would
> > be preferable anyway.
> >
> > John
> >
> >
> >
> >
> >
> > On 5/4/11 4:34 PM, Xuejun Yang wrote:
> > > 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
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> > >