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