Ethereal-dev: Re: [Ethereal-dev] Re: [Ethereal-cvs] rev 13293: /trunk/gtk/: main.c print_dlg.c
Ulf Lamping wrote:
that
way you don't get compiler warnings if a case statement isn't handling a
particular status value if the routine in question won't return it.
Which compiler warning would that be? Sorry, I just don't understand
that one.
This one:
$ cat foo.c
enum foo {
ONE,
TWO,
THREE
};
int
bar(enum foo a)
{
switch (a) {
case ONE:
return 1;
case TWO:
return 2;
}
return 17;
}
$ gcc -c -O2 -Wall -W foo.c
foo.c: In function `bar':
foo.c:17: warning: enumeration value `THREE' not handled in switch
Seems you've just reverted some of the changes I've made ?!? We should
come to an agreement about this :-)
For the print functions, I would agree that both ways could be arguably
be ok, so no problem with the changes you've made (that's just a matter
of personal like/dislike IMHO).
When it comes to having separate error return enums for different
routines, yes, it's a matter of personal like/dislike - I personally
dislike the "enumeration value `XXX' not handled in switch" message. :-)
You *could* handle that by providing cases for all of them, or a default
case, but it seems a bit odd to have to handle CF_PRINT_WRITE_ERROR when
you're calling a function that doesn't print anything, and a default
case means that if you add a *new* error status you don't get warnings
about code that hasn't been modified to know about the new error status
(even if it doesn't have to do anything different for that error, it's
at least worth being warned about it so you know where to check to be
sure that it *doesn't* need to do anything different).
But when it comes e.g. to the cf_filter_packets function, I would simply
disagree, as an gboolean is unintuitive. What does it mean, if a
function named cf_filter_packets will return TRUE or FALSE? That's the
reason I've changed it to the error values.
What do you think about this?
I have no problem with introducing a cf_open_status_t error with
CF_OPEN_OK and CF_OPEN_ERROR, or just renaming the CF_ statuses in
cf_read_status_t to CF_READ_ and having a cf_status_t with CF_OK and
CF_ERROR for all routines that return only a success/failure indication.
