cut is accepting a decreasing range

[ale5000-git]

This is correctly rejected: echo 123 | cut -b '3-1'; echo $?
but this is currently allowed: echo 123 | cut -b '3-2'; echo $?

Why is that?
cut included inside the setup of Bash under Windows reject both.

[rmyorston]

It's an upstream bug. The arguments to -b count from 1, but for internal use they're decremented to allow for zero-based array indexing. When the bounds are compared the lower has been decrement while the upper hasn't.

Give me a moment and I'll apply a fix in busybox-w32. If that works out I'll send a patch upstream.

[rmyorston]

OK, try the latest prerelease (PRE-5519 or above).

[ale5000-git]

Sorry to be late, the code seems to works but the error message is completely off:

$ echo 'abc' | cut -b '3-2'
cut: 1<2

If it require additional code to have the numbers in the error message correct maybe just remove them is also fine.
The error in another cut is simply:
cut: invalid decreasing range

[rmyorston]

I've made some further improvements to the detection of invalid ranges.

Try the latest prerelease (PRE-5523 or above).

[ale5000-git]

It seems everything works perfectly, thanks.

[ale5000-git]

@rmyorston

One minor thing.

This:
: | cut -b '2147483648'

say:
cut: number 2147483648 is not in 0..2147483647 range

Since it no longer accept 0 the message should probably be changed.

[rmyorston]

The message about the 0..2147483647 range comes from a library function, not cut itself.

It's probably not worth the effort to do anything about it.

[avih]

The message about the 0..2147483647 range comes from a library function, not cut itself.

It's probably not worth the effort to do anything about it.

There might be an internal len limit of INT_MAX - 1 to account for final \0, but if that's the case, the message should probably be fixed to account for that as well.

[ale5000-git]

There might be an internal len limit of INT_MAX - 1 to account for final \0, but if that's the case, the message should probably be fixed to account for that as well.

Actually no, it is a fixed limit on BusyBox (from my tests).

In the 64-bit cut (GNU coreutils) 8.32 the limit of cut -b is:
64-bit unsigned - 1 (18446744073709551614)
instead in the 64-bit BusyBox (even on Linux) the limit of cut -b is:
32-bit signed (2147483647)

[avih]

Actually no, it is a fixed limit on BusyBox

INT_MAX - 1 is fixed (and int is 32 bit on both linux and windows) .

and your test with 64 gnu cut reinforces the assessment that the limit is whatever_MAX - 1.

But I misread the original message.

The message is cut: number 2147483648 is not in 0..2147483647 range

The message does appear correct, but your complaint is that the range should not start with 0 (to which I have no comment, also no comment on whether the limit is INT_MAX or INT_MAX-1).

[ale5000-git]

My latest comment was about a different issue.
INT_MAX is not fixed because it change between 32/64-bit, instead this limit is 32-bit even in the 64-bit builds.

[avih]

INT_MAX is not fixed because it change between 32/64-bit,

It does not. It's always 32 at least on Linux/Windows/macOS/most-unix.

[ale5000-git]

I'm not sure about all cases but INT_MAX is just a macro, so I think it depends from the compiler (and the libraries included with it) maybe.

[avih]

at least on Linux/Windows/macOS/most-unix.

You can check here https://en.cppreference.com/w/cpp/language/types .

[ale5000-git]

Here it say otherwise: https://www.geeksforgeeks.org/int_max-int_min-cc-applications/
But it isn't pertinent to this ticket, the main issue was only for 0.

[avih]

Here it say otherwise: https://www.geeksforgeeks.org/int_max-int_min-cc-applications/
But it isn't pertinent to this ticket, the main issue was only for 0.

It doesn't.

It says that IF it's 64 then it's not the same as 32.

But I said that on Linux and Windows and macOS it's always 32.

You can prove me wrong by showing me a linux distro where int is 64 bit.

[ale5000-git]

You may be right.
I didn't intend to enter in this discussion and currently I don't have time to test that; maybe I will try it in the future.

[ale5000-git]

While experimenting I have discovered a specific number that can make the "cut" of macOS freeze forever:
: | cut 2> /dev/null -b "4294967296"