Ethereal-dev: Re: [Ethereal-dev] Re: [Ethereal-cvs] rev 13293: /trunk/gtk/: main.c print_dlg.c
Guy Harris wrote:
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
Interesting, I didn't know that gcc can handle this and throw a warning
on it. And again, knowledge of mankind increases ;-)
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. :-)
Oh, you really don't like compiler warnings? ;-)))
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).
With the new knowledge from above, I see the difference now...
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,
sounds reasonable
or just renaming the CF_ statuses in
cf_read_status_t to CF_READ_
we should do that anyway
and having a cf_status_t with CF_OK and
CF_ERROR for all routines that return only a success/failure indication.
sounds better, I'll do that.
Do we want to use enum's with a different start values, so we will see
if a wrong CF_ enum value was used? e.g.:
CF_PRINT_OK = 0x10,
Regards, ULFL
