Re: [libvirt] [PATCH 12/33] Fix error reporting in port profile parsing/formatting APIs

After applying this patch, make fails with: CC libvirt_util_la-network.lo cc1: warnings being treated as errors util/network.c: In function 'virNetDevVPortProfileParse': util/network.c:712:23: error: assignment makes pointer from integer without a cast util/network.c:712:69: error: ordered comparison of pointer with integer zero [-Wextra] On 11/03/2011 01:30 PM, Daniel P. Berrange wrote: Actually I've noticed a *lot* of the *Format functions ignore the possibility of bad values in the vir*Def objects (e.g. invalid enum values), and have debated with myself about whether to ignore or report invalid data. The following should be "virtPort->virPortType = ....": A bit of digression: In the example here, you're doing something with the enum value aside from just converting it to a string, so there's a ready place to put in the check and return failure if it's out of bounds/unknown, but there are many many places where an XXXTypeToString() macro is used directly as an argument in a printf with no check for validity. On one hand, this is a bit sloppy if we consider that the [whatever]Def objects may contain unverified data (downright dangerous if you think about platforms that don't protect against NULL dereferences in printf!); on the other hand, if we changed every occurrence of that to get the string value into a temp and check for non-NULL before using it in a printf, it would add significant clutter to the code (domain_conf.c seems to be the biggest offender here). Even in this case, we're calling virBufferAsprintf with the unqualified return from virNetDevVPortTypeToString before we eventually vet it in the following switch statement. So do we consider objects sent to the Format functions to contain qualified data or not? If not, there's quite a large patch waiting in the wings :-) Anyway, ACK with the compile problem fixed.