Am 11.03.2017 um 00:33 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> @ depends on r @
>> expression E;
>> @@
>> - *&
>>E
>
> I guess my source of the confusion is that the tool that understands
> the semantics of the C language still needs to be told about that.
René Scharfe writes:
> @ depends on r @
> expression E;
> @@
> - *&
> E
I guess my source of the confusion is that the tool that understands
the semantics of the C language still needs to be told about that.
I was hoping that something that understands C only nee
Am 10.03.2017 um 21:13 schrieb Junio C Hamano:
René Scharfe writes:
I think this misses the other two cases: (*dst, src) and (*dst, *src).
... and that's why I left them out. You can't get dst vs. *dst wrong
with structs (at least not without the compiler complaining); only
safe transformat
On Fri, Mar 10, 2017 at 12:13:11PM -0800, Junio C Hamano wrote:
> René Scharfe writes:
>
> >> I think this misses the other two cases: (*dst, src) and (*dst, *src).
> >
> > ... and that's why I left them out. You can't get dst vs. *dst wrong
> > with structs (at least not without the compiler c
René Scharfe writes:
>> I think this misses the other two cases: (*dst, src) and (*dst, *src).
>
> ... and that's why I left them out. You can't get dst vs. *dst wrong
> with structs (at least not without the compiler complaining); only
> safe transformations are included in this round.
I haven
Am 10.03.2017 um 18:57 schrieb Jeff King:
On Fri, Mar 10, 2017 at 05:20:13PM +0100, René Scharfe wrote:
I think this misses the other two cases: (*dst, src) and (*dst, *src).
... and that's why I left them out. You can't get dst vs. *dst wrong with
structs (at least not without the compiler
On Fri, Mar 10, 2017 at 05:20:13PM +0100, René Scharfe wrote:
> > I think this misses the other two cases: (*dst, src) and (*dst, *src).
>
> ... and that's why I left them out. You can't get dst vs. *dst wrong with
> structs (at least not without the compiler complaining); only safe
> transforma
Am 10.03.2017 um 09:18 schrieb Jeff King:
On Fri, Mar 10, 2017 at 01:14:16AM +0100, René Scharfe wrote:
2. Ones which just copy a single object, like:
memcpy(&dst, &src, sizeof(dst));
Perhaps we should be using struct assignment like:
dst = src;
here. It's safer an
On Fri, Mar 10, 2017 at 01:14:16AM +0100, René Scharfe wrote:
> > 2. Ones which just copy a single object, like:
> >
> >memcpy(&dst, &src, sizeof(dst));
> >
> > Perhaps we should be using struct assignment like:
> >
> >dst = src;
> >
> > here. It's safer and it shou
On Fri, Mar 10, 2017 at 01:14:45AM +0100, René Scharfe wrote:
> > 3. There were a number of alloc-and-copy instances. The copy part is
> > the same as (2) above, but you have to repeat the size, which is
> > potentially error-prone. I wonder if we would want something like:
> >
> >
Am 05.03.2017 um 12:36 schrieb Jeff King:
> I grepped for 'memcpy.*sizeof' and found one other case that's not a
> bug, but is questionable.
>
> Of the "good" cases, I think most of them could be converted into
> something more obviously-correct, which would make auditing easier. The
> three main
Am 05.03.2017 um 12:36 schrieb Jeff King:
I grepped for 'memcpy.*sizeof' and found one other case that's not a
bug, but is questionable.
Of the "good" cases, I think most of them could be converted into
something more obviously-correct, which would make auditing easier. The
three main cases I sa
On 05/03/17 17:38, Lars Schneider wrote:
>> On 02 Mar 2017, at 16:17, Ramsay Jones wrote:
>> On 02/03/17 11:24, Johannes Schindelin wrote:
>>> On Thu, 2 Mar 2017, Lars Schneider wrote:
>>>
>> [snip]
One thing that still bugs me: In the Linux32 environment prove adds the
CPU times to ev
> On 02 Mar 2017, at 16:17, Ramsay Jones wrote:
>
>
>
> On 02/03/17 11:24, Johannes Schindelin wrote:
>> Hi Lars,
>>
>> On Thu, 2 Mar 2017, Lars Schneider wrote:
>>
> [snip]
>>> One thing that still bugs me: In the Linux32 environment prove adds the
>>> CPU times to every test run: ( 0.02 us
On Sun, Mar 05, 2017 at 06:36:19AM -0500, Jeff King wrote:
> I grepped for 'memcpy.*sizeof' and found one other case that's not a
> bug, but is questionable.
And here's the fix for that case. It can be applied separately from the
other patch if need be.
-- >8 --
Subject: [PATCH] ewah: fix eword_
On Sat, Mar 04, 2017 at 09:08:40PM +0100, Vegard Nossum wrote:
> > At a glance, looks like range_set_copy() is using
> > sizeof(struct range_set) == 12, but
> > range_set_init/range_set_grow/ALLOC_GROW/REALLOC_ARRAY is using
> > sizeof(rs->range) == 8.
>
> Attached patch seems to fix it -- basica
On 04/03/2017 20:49, Vegard Nossum wrote:
On 04/03/2017 19:08, Vegard Nossum wrote:
On 04/03/2017 18:23, Lars Schneider wrote:
Did Travis find our first 32bit bug? I briefly looked into it
and the following new topic on pu seems to cause the issue:
http://public-inbox.org/git/20170302172902.16
On 04/03/2017 19:08, Vegard Nossum wrote:
On 04/03/2017 18:23, Lars Schneider wrote:
Did Travis find our first 32bit bug? I briefly looked into it
and the following new topic on pu seems to cause the issue:
http://public-inbox.org/git/20170302172902.16850-1-allan.x.xav...@oracle.com/
https://g
On 04/03/2017 18:23, Lars Schneider wrote:
Did Travis find our first 32bit bug? I briefly looked into it
and the following new topic on pu seems to cause the issue:
http://public-inbox.org/git/20170302172902.16850-1-allan.x.xav...@oracle.com/
https://github.com/git/git/commit/aaae0bf787f09ba102f
> On 04 Mar 2017, at 05:11, Junio C Hamano wrote:
>
> On Fri, Mar 3, 2017 at 4:03 PM, Junio C Hamano wrote:
>>
>> I only recently started looking at Travis logs, so I cannot tell if
>> it is just a usual flake (e.g. some builds a few days ago seems to
>> have failed due to not being able to ch
On Fri, Mar 3, 2017 at 4:03 PM, Junio C Hamano wrote:
>
> I only recently started looking at Travis logs, so I cannot tell if
> it is just a usual flake (e.g. some builds a few days ago seems to
> have failed due to not being able to check out the tree being
> tested, which I do not think is our f
Junio C Hamano writes:
> I see he did v2 which you Acked in a different thread. Will replace
> what's been on 'pu' and running with Travis the past few days with
> it. Let's wait for one or more Travis cycles and then merge it to
> 'next'.
https://travis-ci.org/git/git/jobs/207517043 is an out
Johannes Schindelin writes:
> On Thu, 2 Mar 2017, Junio C Hamano wrote:
>
>> Another question is which v3 people mean in the discussion, when you
>> and Dscho work on improvements at the same time and each post the
>> "next" version marked as "v3", and they comment on one of them?
>
> But then, L
Hi Junio,
On Thu, 2 Mar 2017, Junio C Hamano wrote:
> Another question is which v3 people mean in the discussion, when you
> and Dscho work on improvements at the same time and each post the
> "next" version marked as "v3", and they comment on one of them?
But then, Lars & I communicate in a mor
Lars Schneider writes:
>> On 02 Mar 2017, at 12:24, Johannes Schindelin
>> wrote:
>>
>> Hi Lars,
>>
>> On Thu, 2 Mar 2017, Lars Schneider wrote:
>>
>>> The patch looks good to me in general but I want to propose the following
>>> changes:
>>
>> I know you are using your script to generate t
On Thu, Mar 2, 2017 at 3:22 PM, Johannes Schindelin
wrote:
>
>> >> +set -e
>> >
>> > Is this really necessary? I really like to avoid `set -e`, in
>> > particular when we do pretty much everything in && chains anyway.
>>
>> Agreed, not really necessary here as we just invoke one command. Out of
>
On 02/03/17 11:24, Johannes Schindelin wrote:
> Hi Lars,
>
> On Thu, 2 Mar 2017, Lars Schneider wrote:
>
[snip]
>> One thing that still bugs me: In the Linux32 environment prove adds the
>> CPU times to every test run: ( 0.02 usr 0.00 sys + 0.00 cusr 0.00
>> csys ... Has anyone an idea why
Hi Lars,
On Thu, 2 Mar 2017, Lars Schneider wrote:
> > On 02 Mar 2017, at 12:24, Johannes Schindelin
> > wrote:
> >
> > On Thu, 2 Mar 2017, Lars Schneider wrote:
> >
> >> The patch looks good to me in general but I want to propose the
> >> following changes:
> >
> > I know you are using you
> On 02 Mar 2017, at 12:24, Johannes Schindelin
> wrote:
>
> Hi Lars,
>
> On Thu, 2 Mar 2017, Lars Schneider wrote:
>
>> The patch looks good to me in general but I want to propose the following
>> changes:
>
> I know you are using your script to generate this mail, but I would have
> liked
Hi Lars,
On Thu, 2 Mar 2017, Lars Schneider wrote:
> The patch looks good to me in general but I want to propose the following
> changes:
I know you are using your script to generate this mail, but I would have
liked to see v2 in the subject ;-)
> (1) Move all the docker magic into a dedicated
From: Johannes Schindelin
When Git v2.9.1 was released, it had a bug that showed only on Windows
and on 32-bit systems: our assumption that `unsigned long` can hold
64-bit values turned out to be wrong.
This could have been caught earlier if we had a Continuous Testing
set up that includes a bui
31 matches
Mail list logo
