Re: enumeration of bicycle sheds
On Thu, Feb 18, 2010 at 7:18 AM, Iain Hibbert wrote:
> On Thu, 18 Feb 2010, Terry Moore wrote:
>
>> Looking at C99, trailing commas _are_ allowed in enum lists.
>
> I know that, but C89 expressly forbade it and apparently C++ is similar.
> I'm not claiming that its reasonable and incidentally, share/misc/style
> says to not use the comma..
>
> If you or anybody wants to argue for or against enum vs #define for lists
> of internal state variables, please go ahead. If the type checking for
> enum was strong enough that
>
> enum val { FOO, BAR };
> int v = FOO;
>
> or
>
> enum val { FOO, BAR };
> enum val v = 3;
>
> actually caused warnings then I would be more inclined to use it. In the
> meantime, I generally prefer #define but am not greatly attached.
>
Debugging anything which uses #define is a major pita. That's why
people went to this and things like static const variables instead.
James
Re: Lost file-system story
On Tue, Dec 13, 2011 at 4:09 PM, Greg A. Woods wrote: > At Wed, 14 Dec 2011 09:06:23 +1030, Brett Lymn > wrote: > Subject: Re: Lost file-system story >> >> On Tue, Dec 13, 2011 at 01:38:57PM +0100, Joerg Sonnenberger wrote: >> > >> > fsck is supposed to handle *all* corruptions to the file system that can >> > occur as part of normal file system operation in the kernel. It is doing >> > best effort for others. It's a bug if it doesn't do the former and a >> > potential missing feature for the latter. >> > >> >> There are a lot of slips twixt cup and lip. If you are really unlucky >> you can get an outage at just the wrong time that will cause the >> filesystem to be hosed so badly that fsck cannot recover it. Sure, fsck >> can run to completion but all you have is most of your FS in lost+found >> which you have to be really really desperate to sort through. I have >> been working with UNIX for over 20years now and I have only seen this >> happen once and it was with a commercial UNIX. > > I've seen that happen more than once unfortunately. SunOS-4 once I think. > > I agree 100% with Joerg here though. > > I'm pretty sure at least some of the times I've seen fsck do more damage > than good it was due to a kernel bug or more breaking assumptions about > ordered operations. > > There have of course also been some pretty serious bugs in various fsck > implementations across the years and vendors. > I'd be suspicious of fsck failing on a regularly mounted disk with corruption that can't otherwise be tracked to outside influences (bad ram, bad disk cache, etc). I've seen some bizarre things happen on ram errors over the years for instance. James
