libnm: reorder fields in NMIPAddress/NMIPRoute struct
Order the fields by their size, to minimize the alignment gaps. I guess, that doesn't matter because the alignment of the heap allocation is larger than what we can safe here. Still, there is on reason to do it any other way. Also, it's not possible via API to set family/prefix to values outside their range, so an 8bit integer is always sufficient. And we don't want that invariant to change. We don't ever want to allow the caller to set values that are clearly invalid, and will assert against that early (g_return()). Point is, we can do this and there is no danger of future problems. And even if we will support larger values, it's all an implementation detail anyway.
This commit is contained in:
@@ -169,9 +169,10 @@ G_DEFINE_BOXED_TYPE(NMIPAddress, nm_ip_address, nm_ip_address_dup, nm_ip_address
|
||||
struct NMIPAddress {
|
||||
guint refcount;
|
||||
|
||||
char *address;
|
||||
int prefix, family;
|
||||
gint8 family;
|
||||
guint8 prefix;
|
||||
|
||||
char *address;
|
||||
GHashTable *attributes;
|
||||
};
|
||||
|
||||
@@ -608,13 +609,14 @@ G_DEFINE_BOXED_TYPE(NMIPRoute, nm_ip_route, nm_ip_route_dup, nm_ip_route_unref)
|
||||
struct NMIPRoute {
|
||||
guint refcount;
|
||||
|
||||
int family;
|
||||
char *dest;
|
||||
guint prefix;
|
||||
char *next_hop;
|
||||
gint64 metric;
|
||||
gint8 family;
|
||||
guint8 prefix;
|
||||
|
||||
char *dest;
|
||||
char *next_hop;
|
||||
GHashTable *attributes;
|
||||
|
||||
gint64 metric;
|
||||
};
|
||||
|
||||
/**
|
||||
|
Reference in New Issue
Block a user