Osmocom Libraries » libosmocore

pespin wrote:

Similary, supporting octal would allow us to easily specify file permissions bitmaks in the VTY.

do we actually do that anywhere? I would guess most people who're not unix sysadmins or C programmers wouldn't know that 01234 is != 1234 and hence I would really avoid that notation. And 0/O is just so close in terms of "hamming distance of the character".... so I fear more danger than benefit.

I see 2 main options to support those:
1- Specify range parameters as decimal ranges (ex: <0-200>) but allowing passing any format of integer (dec, hex, oct) by specifying the format prefix. That's what the libosmocore patch above adds support for.
For instance:

• cmd definition: "lac <0-6534324>"
• cmd write: "lac 0x30"

For the input, I think that is the best

2- Specify accepted range formats explicitly. This means each param needs to be more detailed but also allows accepting specific formats on specific parameters. For instance, one would allow only decimal and hex in lac cmd: "lac (<0-6534324>|<0x0-0x4352>), or only accept hex: "lac <0x0-0x4352>"

• if a decimal range is specified, allow decimal or hex input (I'd avoid octal)
• if a hexadecimal range is specified in the command, allow only hexadecimal input

laforge wrote in #note-2:

pespin wrote:

Similary, supporting octal would allow us to easily specify file permissions bitmaks in the VTY.

do we actually do that anywhere? I would guess most people who're not unix sysadmins or C programmers wouldn't know that 01234 is != 1234 and hence I would really avoid that notation. And 0/O is just so close in terms of "hamming distance of the character".... so I fear more danger than benefit.

https://gitea.osmocom.org/osmocom/osmo-pcap/src/branch/master/src/osmo_server_vty.c#L138
https://gitea.osmocom.org/osmocom/osmo-pcap/src/branch/master/src/osmo_server_vty.c#L91

it could also be both:

• if a decimal range is specified, allow decimal or hex input
• if a hexadecimal range is specified in the command, allow only hexadecimal input

That's a bit confusing at first but I see your point. I'm fine with either this solution (let's call it "3") or any of the 2 I presented before.

(I'd avoid octal)

Bear in mind allowing octal makes it actually easier implementation, because (see presented libosmocore patch before) one can simply pass 0 to the base to stroul and let it parse properly whatever base it is thrown at it.

On Mon, Jul 25, 2022 at 05:22:31PM +0000, pespin wrote:

Bear in mind allowing octal makes it actually easier implementation, because (see presented libosmocore patch before) one can simply pass 0 to the base to stroul and let it parse properly whatever base it is thrown at it.

I'd rather invest a few more dozens of minutes of R&D time rather than sending our users
into a trap.

• If a decimal range is specified in the vty command (eg <0-300>), then input arg can be either decimal or hex, and both are accepted.
• If a hexadecimal range is specified in the vty command (always prefixed by "0x"|"0X" to avoid confusions, eg <0x0-0x500>), then input arg must also be hexadecimal.

However, this may cause lots of unexpected errors. Because even if the checking is fine, then now a lot of existing VTY commands may receive a hexadecimal input string, while this was not possible before. Lots of them are probably not using strotul() with base=0, or even worse, using atoi(), which only accepts decimal base and has no way to return an error.
So that would end up in lots of unexpected behaviors if hexadecimal values are typed for existing commands.

Hence, I think the best is to only accept decimal arg values if decimal ranges are specified. If one wishes to support both types of ranges in a specific command, then the arg can be specified as "(<0-255>|<0x00-0xff>)" and then use stroul(base=0).

We may want to support the same in CTRL interface:

CTRL_CMD_DEFINE_RANGE(bts_lac, "location-area-code", struct gsm_bts, location_area_code, 0, 65535);