Re: Breaking change with "git log -n" since 2.43

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 21, 2024, at 16:07, Maarten Ackermans wrote:
> I would suggest displaying a warning in case of invalid input (such as
> this out of range error), and to fall back to output all as if the
> "-n" flag was unspecified. If more strict handling is still desired,
> it could instead be a deprecation warning with a grace period, giving
> applications some time to update their git usage.

>From 71a1e9482:

  “ As a natural consequence, an argument that does not begin with a
    digit (e.g., "q") silently becomes zero, too.

It sounds like the non-breaking behavior for non-number input like `q`
is to silently become `0`.[1] But then that too-large number input would
also become `0`, which doesn’t help for that JavaScript
application/library. Unless `strtol_i` is able to differentiate between
different errors by returning different negative numbers?

† 1: Or else you risk breaking usages where they rely on bad input
    becoming `0`
-- 
Kristoffer Haugsbakk





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux