Hi, On 18/10/2019 17:19, Theo de Raadt wrote: >> 3. Track down all the places that this might be used, and make sure they >> are also changed to handle a u_int32_t. > > Gigantic ABI breakage. > > Hope you have fun upgrading bsd, ifconfig, and other tools through that > change.
Yeah, I didn't say this would be fun. >> The only place that I can think of that really might break is SNMP >> clients, > > If you change the offset of all the fields in if_data, and all the macros > that access inside it, you'll break a lot more than the snmp tools. I'm assuming that within OpenBSD base and ports everything can be fixed. I mean SNMP clients like monitoring appliances, because these numbers (maybe, I didn't check) appear on the wire. > Some problems created by IANA cannot be solved. In the coming decade I > expect they'll come to realize they've allocated all the numbers in the > protocols and services files, and start allocating out-of-range numbers > there also. They get into this situation reasons: they hand out numbers > for things which don't actually need unique numbers, then don't delete > ancient irrelevant things. > > Should fix? Very debatable. I can also just say everything is fine and make up another "private" assignment. If people don't feel the work is worth doing, then I won't do it. We have 31 numbers we didn't assign to something yet in if_types.h, which is probably enough for some years yet. Thanks, Iain.