From mboxrd@z Thu Jan  1 00:00:00 1970
From: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Date: Fri, 13 Sep 2013 22:41:31 +0530
Subject: [U-Boot] [PATCH v3 2/3] dfu: ram support
In-Reply-To: <20130913170545.GB7452@afzal-ThinkPad-R50e>
References: <cover.1379055111.git.afzal.mohd.ma@gmail.com>
	<5eb509735b5bd634043bbb8f56d088073773b7b8.1379055112.git.afzal.mohd.ma@gmail.com>
	<201309131551.22535.marex@denx.de>
	<20130913153736.GG6479@book.gsilab.sittig.org>
	<20130913170545.GB7452@afzal-ThinkPad-R50e>
Message-ID: <20130913171130.GC7452@afzal-ThinkPad-R50e>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

+ Gerhard

On Fri, Sep 13, 2013 at 10:35:45PM +0530, Afzal Mohammed wrote:
> Hi Gerhard, Marek,
> 
> On Fri, Sep 13, 2013 at 05:37:36PM +0200, Gerhard Sittig wrote:
> > On Fri, Sep 13, 2013 at 15:51 +0200, Marek Vasut wrote:
> 
> > > > +	dfu->data.ram.size = simple_strtoul(++s, &s, 16);
> > > 
> > > This ++s, &s is quite crazy ;-)
> 
> > Actually it's not just a neat trick, but instead it's not
> > guaranteed to work.  It's an inviation for problems that you
> > don't need.
> > 
> > The order in which arguments for the call get evaluated isn't
> > specified, so behaviour is uncertain here.  Read: the
> > construction happens to work by coincidence for individual
> > setups, but isn't correct and need not work elsewhere, and may
> > break in arbitrary ways at any occasion, and then is hard to
> > track down since things may "seem to work" often enough or the
> > bug won't show up when you are diagnosing the problem.
> > 
> > The code needs to get fixed before getting picked up.  Doing the
> > increment in a separate instruction is cheap and simple, the
> > terse form is wrong.
> 
> Yes wrong me, I realize that result is compiler dependent and not
> guaranteed to work always, v4 posted taking care of the above.
> 
> Regards
> Afzal