RE: [RFC iproute2] tos: interpret ToS in natural numeral system
flat view
From: David Laight <hidden>
Date: 2022-02-16 22:44:27
From: Guillaume Nault
Sent: 16 February 2022 22:24 On Wed, Feb 16, 2022 at 11:42:05AM -0800, Jakub Kicinski wrote:quoted
Silently forcing a base numeral system is very painful for users. ip currently interprets tos 10 as 0x10. Imagine user's bash script does: .. tos $((TOS * 2)) .. or any numerical operation on the ToS. This patch breaks existing scripts if they expect 10 to be 0x10.I agree that we shouldn't have forced base 16 in the first place. But after so many years I find it a bit dangerous to change that.
Aren't the TOS values made up of several multi-bit fields and very likely to be documented in hex? I'm not sure $((TOS * 2)) (or even + 2) makes any sense at all. What it more horrid that that base 0 treats numbers that start with a 0 as octal - has anyone really used octal since the 1970s (except for file permissions). I have written command line parsers that treat 0tnnn as decimal while defaulting to hex. That does make it easier to use shell arithmetic for field (like addresses) that you would never normally specify in decimal.
quoted hunk ↗ jump to hunk
What about just printing a warning when the value isn't prefixed with '0x'? Something like (completely untested):@@ -535,6 +535,12 @@ int rtnl_dsfield_a2n(__u32 *id, const char *arg) if (!end || end == arg || *end || res > 255) return -1; *id = res; + + if (strncmp("0x", arg, 2)) + fprintf(stderr, + "Warning: dsfield and tos parameters are interpreted as hexadecimal values\n" + "Use 'dsfield 0x%02x' to avoid this message\n", res);
Ugg. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)