<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
I understand that. I often am "like that".<BR>
But we are our own consumers. The code has probably been unused a long time, but I didn't check.<BR>
We can put it in when we need it.<BR>
<A href="http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it">http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it</A><BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> Date: Thu, 4 Mar 2010 14:45:12 -0600<BR>> From: rodney_bates@lcwb.coop<BR>> To: m3commit@elegosoft.com<BR>> Subject: Re: [M3commit] CVS Update: cm3<BR>> <BR>> <BR>> <BR>> Jay K wrote:<BR>> > Maybe remove it instead? Unused suggests untested, not working.<BR>> <BR>> I am with Tony on this one. Well-designed code has always had places where<BR>> it will handle a more general input space than current use-cases demand.<BR>> <BR>> Always removing everything from what is handled reflects the view that a<BR>> program is a one-time thing that never changes. Putting in some things<BR>> that follow a consistent general pattern reflects the view that a program<BR>> is an evolving thing. Excepting a very few programs that are either trivial<BR>> or very little-used, the latter assumption is always the correct one.<BR>> <BR>> Of course, you can't put everything imaginable in. But things that are part<BR>> of a general pattern are good candidates. Nobody could _ever_ design very<BR>> useful code, if not following this principal.<BR>> <BR>> I once, in my very first job, had to rework a big test driver written in<BR>> such a way that it handled exactly the set of test cases that had been<BR>> originally specified and not a thing more. Nobody could add any new cases<BR>> as things evolved. The internal structure bore no resemblance to the<BR>> pattern of the inputs. I could only throw it all out except for some<BR>> low-level routines and start over.<BR>> <BR>> > <BR>> > ------------------------------------------------------------------------<BR>> > From: hosking@cs.purdue.edu<BR>> > Date: Wed, 3 Mar 2010 22:29:04 -0500<BR>> > To: jay.krell@cornell.edu<BR>> > CC: m3commit@elegosoft.com<BR>> > Subject: Re: [M3commit] CVS Update: cm3<BR>> > <BR>> > It turns out not actually to be used by m3front. But it is defined by <BR>> > m3middle, so let's support it and not get bitten in the arse if/when <BR>> > m3front ever uses it.<BR>> > <BR>> > On 3 Mar 2010, at 18:45, Jay K wrote:<BR>> > <BR>> > I don't see where it is used.<BR>> > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *><BR>> > (in m3back).<BR>> > The parameters are being passed to memset in the wrong order.<BR>> > Compare it to m3cg_zero.<BR>> > I was actually looking to see if parameters are left to right or<BR>> > right to left, I looked at these two examples and decided they can't<BR>> > both be correct.<BR>> > <BR>> > - Jay<BR>> > <BR>> > ------------------------------------------------------------------------<BR>> > From: hosking@cs.purdue.edu <mailto:hosking@cs.purdue.edu><BR>> > Date: Wed, 3 Mar 2010 11:02:36 -0500<BR>> > To: hosking@cs.purdue.edu <mailto:hosking@cs.purdue.edu><BR>> > CC: m3commit@elegosoft.com <mailto:m3commit@elegosoft.com><BR>> > Subject: Re: [M3commit] CVS Update: cm3<BR>> > <BR>> > Please say how this is broken.<BR>> > <BR>> > On 3 Mar 2010, at 10:57, Tony Hosking wrote:<BR>> > <BR>> > Huh? I see it in the front-end!<BR>> > <BR>> > <BR>> > On 3 Mar 2010, at 10:21, Jay Krell wrote:<BR>> > <BR>> > CVSROOT: /usr/cvs<BR>> > Changes by: jkrell@birch. 10/03/03 10:21:42<BR>> > <BR>> > Modified files:<BR>> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c <BR>> > <BR>> > Log message:<BR>> > zero_n is incorrect and never used, put gcc_assert(0) in it<BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR> </body>
</html>