shared, core: do not always accept numbers in string lookups

The behaviour of the common name##_from_string conversion is surprising.
It accepts not only the strings from name##_table but also any number
that falls within the range of the table. The order of items in most of
our tables is an internal affair. It should not be visible to the user.

I know of a case where the surprising numeric conversion leads to a crash.

We will allow the direct numeric conversion only for the tables where the
mapping of strings to numeric values has an external meaning. This holds
for the following lookup tables:
 - netlink_family, ioprio_class, ip_tos, sched_policy - their numeric
   values are stable as they are defined by the Linux kernel interface.
 - log_level, log_facility_unshifted - the well-known syslog interface.

We allow the user to use numeric values whose string names systemd does
not know. For instance, the user may want to test a new kernel featuring
a scheduling policy that did not exist when his systemd version was
released. A slightly unpleasant effect of this is that the
name##_to_string conversion cannot return pointers to constant strings
anymore. The strings have to be allocated on demand and freed by the
caller.

0 files changed, 0 insertions, 0 deletions