All current pif names are quite short, and we expect them to remain short
when/if we allow arbitrary pifs. However, because of the structure of
the current code we don't enforce any limit on the length.
This will become more important with dynamic configuration updates, so
start enforcing a length limit. Specifically we allow pif names to be up
to IFNAMSIZ bytes, including the terminating \0. This is semi-arbitrary -
there's no particular reason we have to use the same length limit as
kernel netif names. However, when we do allow arbitrary pifs, we expect
that we might support a similar number to the number of kernel interfaces.
It might make sense to use names matching kernel interface names in that
future. So, re-use IFNAMSIZ to avoid surprise.
Signed-off-by: David Gibson
---
pif.c | 2 +-
pif.h | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/pif.c b/pif.c
index 1e807247..4e25e3fa 100644
--- a/pif.c
+++ b/pif.c
@@ -17,7 +17,7 @@
#include "inany.h"
#include "epoll_ctl.h"
-const char *pif_type_str[] = {
+const char pif_type_str[][IFNAMSIZ] = {
[PIF_NONE] = "<none>",
[PIF_HOST] = "HOST",
[PIF_TAP] = "TAP",
diff --git a/pif.h b/pif.h
index 7bb58e5c..c467a941 100644
--- a/pif.h
+++ b/pif.h
@@ -35,7 +35,8 @@ enum pif_type {
PIF_NUM_TYPES,
};
-extern const char *pif_type_str[];
+/* Limit pif names to the same length as kernel interface names */
+extern const char pif_type_str[][IFNAMSIZ];
static inline const char *pif_type(enum pif_type pt)
{
@@ -43,6 +44,7 @@ static inline const char *pif_type(enum pif_type pt)
return pif_type_str[pt];
else
return "?";
+ static_assert(sizeof("?") <= IFNAMSIZ);
}
static inline const char *pif_name(uint8_t pif)
--
2.53.0