[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] [merge-tracking] Code clarity fix

From: Daniel Rall <dlr_at_collab.net>
Date: 2006-09-02 00:53:23 CEST

On Thu, 31 Aug 2006, Kamesh Jayachandran wrote:

> Daniel Berlin wrote:
> >>>
> >>I am not sure about the speed.
> >>I thought copying 8 bytes at one shot should be faster than dereferncing
> >>4 integer items and assigning them.
> >
> >Again, the compiler will turn one into the other depending on a number
> >of factors, including register pressure, etc.
> >
> >>If I understand this segment of code it just takes the 'forward merge
> >>ranges', which this '*(*output) = *in1; ' should be more meaningful with
> >>the associated commit message.
> >
> >At least to me, it's less meaningful to do structure copies in a lot
> >of cases.
> >Others may disagree.
> >
> Barring the (confusing???)structure copy stuff, the code segment
> essentially assigns 'in1' or 'in2' to output.
> Initially seeing a function having 6 else if blocks doing some checks
> with 'in1' and 'in2's members and extracting the same and assigning to
> some other structure, I felt bit difficult to differentiate this
> particular 'else if' blocks with others on the first glance. After all
> mental imaging of 'in1' and 'in2', I found that 'foo... this is just
> avoiding revert the range'

In this case, I find the structure copy style very slightly more

> Anyways..........
> What is our stance on 'revert range' combining.

IIRC, we don't support it, which explains the (undefined) behavior you
describe below.

> Currently 'combine_ranges' for in1(5,9) in2(10, 6) sets *output to
> (5,9), is it correct? I feel we should return FALSE without changing the
> '*output' like we do for (5, 9) and (17, 26).

  • application/pgp-signature attachment: stored
Received on Sat Sep 2 00:52:09 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.