Re: cvs commit: src/sys/kern vfs_bio.c vfs_syscalls.c src/sys/sys buf.h src/sys/vm vm_pager.c

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:
:On Wed, Aug 03, 2005 at 08:21:46AM -0700, Matthew Dillon wrote:
:> 
:> :
:> :On Tue, Aug 02, 2005 at 09:59:53PM -0700, Hiten Pandya wrote:
:> :>   Localise buffer queue information into kern/vfs_bio.c, it should not be
:> :>   messed with outside of the named file.  Convert the QUEUE_* #defines
:> :>   into enum bufq_type, prefix the names with 'B'.  The change to initpbuf()
:> :>   is acceptable since they are a hack anyway, not to mention that
:> :
:> :You might want to change the various switch statements to have no
:> :default case, allowing GCC to warn about missing cases.
:> :
:> :Joerg
:>     
:>     I'd rather not depend on that feature of GCC, it could bite us in some future
:>     release of GCC, plus it is not always desireable to actually list all cases
:>     in a switch state (though in the buffer cache case its probably fine).
:>     A default/panic case is more robust.
:
:The default + panic is not detectable at compile time, that's what I
:mean. The requirement is that the type of expression in the switch
:statement is an enum, it will warn if any case is missing. That's
:standard practise in other languages as well, not only C.
:
:It's not always a good thing, yes, but if you have more than two cases
:to handle (and that's why a switch is used after all), it can make the
:code more maintainable because you can't just add a new type and forget
:to handle it somewhere :-)
:
:Joerg

    I suppose, theoretically.  But in reality it seems to me far more likely
    that a person trying to code all cases would wind up simply producing
    code that will handle those cases with a panic anyway, or worse the 
    coder will try to actually code up something real for the cases that
    should otherwise contain an assertion, just to fill out the switch.

    In my view, a run-time panic works just as well in this case as 
    anything else.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>