Am 08.10.19 um 14:04 schrieb Johannes Schindelin:
> So you got what you wished for:
> https://public-inbox.org/git/pull.378.git.gitgitgad...@gmail.com
After having seen the result I do not wish for it anymore. (Not that I
had "wished" for it in the first place...) It does not make the result
any m
Hi Hannes,
On Sun, 6 Oct 2019, Johannes Sixt wrote:
> Am 06.10.19 um 02:02 schrieb Junio C Hamano:
> > Johannes Schindelin writes:
> >
> >>> IMHO, if you don't accompany insert_pos_as_negative_offset() with a
> >>> corresponding extract_pos_and_found_condition() and use it everywhere,
> >>> it i
Am 06.10.19 um 02:02 schrieb Junio C Hamano:
> Johannes Schindelin writes:
>
>>> IMHO, if you don't accompany insert_pos_as_negative_offset() with a
>>> corresponding extract_pos_and_found_condition() and use it everywhere,
>>> it is more obfuscating than necessary.
>>
>> I do disagree here. No o
Johannes Schindelin writes:
>> IMHO, if you don't accompany insert_pos_as_negative_offset() with a
>> corresponding extract_pos_and_found_condition() and use it everywhere,
>> it is more obfuscating than necessary.
>
> I do disagree here. No overflow checking needs to be performed for `-1 -
> `.
Hi Hannes,
On Fri, 4 Oct 2019, Johannes Sixt wrote:
> Am 04.10.19 um 11:55 schrieb Johannes Schindelin:
> > On Fri, 4 Oct 2019, Junio C Hamano wrote:
> >> These three look good and too similar to each other, which makes me
> >> wonder if we want to allow them simply write
> >>
> >>return inse
Am 04.10.19 um 11:55 schrieb Johannes Schindelin:
> On Fri, 4 Oct 2019, Junio C Hamano wrote:
>> These three look good and too similar to each other, which makes me
>> wonder if we want to allow them simply write
>>
>> return insert_pos_as_negative_offset(nr);
>>
>> with something like
>>
>>
Hi Junio,
On Fri, 4 Oct 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > While at it, we take care of reporting overflows (which are unlikely,
> > but hey, defensive programming is good!).
> >
> > We _also_ take pains of casting the unsigned value to signed: o
"Johannes Schindelin via GitGitGadget"
writes:
> While at it, we take care of reporting overflows (which are unlikely,
> but hey, defensive programming is good!).
>
> We _also_ take pains of casting the unsigned value to signed: otherwise,
> the signed operand (i.e. the `-1`) would be cast to uns
From: Johannes Schindelin
MSVC complains about this with `-Wall`, which can be taken as a sign
that this is indeed a real bug. The symptom is:
C4146: unary minus operator applied to unsigned type, result
still unsigned
Let's avoid this warning in the minimal way, e.g. writing `-
9 matches
Mail list logo