-
Eric Blake authored
When reporting that an unvisited member remains at the end of an input visit for a struct, we were using g_hash_table_find() coupled with a callback function that always returns true, to locate an arbitrary member of the hash table. But if all we need is an arbitrary entry, we can get that from a single-use iterator, without needing a tautological callback function. Technically, our cast of &(GQueue *) to (void **) is not strict C (while void * must be able to hold all other pointers, nothing says a void ** has to be the same width or representation as a GQueue **). The kosher way to write it would be the verbose: void *tmp; GQueue *any; if (g_hash_table_iter_next(&iter, NULL, &tmp)) { any = tmp; But our code base (not to mention glib itself) already has other cases of assuming that ALL pointers have the same width and representation, where a compiler would have to go out of its way to mis-compile our borderline behavior. Suggested-by:
Markus Armbruster <armbru@redhat.com>
Signed-off-by:
Eric Blake <eblake@redhat.com>
Reviewed-by:
Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1455778109-6278-2-git-send-email-eblake@redhat.com>
Signed-off-by:
Markus Armbruster <armbru@redhat.com>Eric Blake authoredWhen reporting that an unvisited member remains at the end of an input visit for a struct, we were using g_hash_table_find() coupled with a callback function that always returns true, to locate an arbitrary member of the hash table. But if all we need is an arbitrary entry, we can get that from a single-use iterator, without needing a tautological callback function. Technically, our cast of &(GQueue *) to (void **) is not strict C (while void * must be able to hold all other pointers, nothing says a void ** has to be the same width or representation as a GQueue **). The kosher way to write it would be the verbose: void *tmp; GQueue *any; if (g_hash_table_iter_next(&iter, NULL, &tmp)) { any = tmp; But our code base (not to mention glib itself) already has other cases of assuming that ALL pointers have the same width and representation, where a compiler would have to go out of its way to mis-compile our borderline behavior. Suggested-by:
Markus Armbruster <armbru@redhat.com>
Signed-off-by:
Eric Blake <eblake@redhat.com>
Reviewed-by:
Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1455778109-6278-2-git-send-email-eblake@redhat.com>
Signed-off-by:
Markus Armbruster <armbru@redhat.com>
Loading