Re: [PATCH 1/2] bcachefs: add fiemap delalloc extent detection

[Brian Foster <bfoster@redhat.com>]

On Mon, Jan 08, 2024 at 02:34:43PM -0800, Carl E. Thompson wrote:
> I'm not a kernel developer so feel free to ignore this.
> 
> > On 2024-01-08 7:33 AM PST Brian Foster <bfoster@redhat.com> wrote:
> 
> > ...
> 
> > 3. Logistically, this is likely to be a bit awkward for pretty much
> > everybody who has a history of working with C code.
> 
> I disagree with this point. The ability to declare variables anywhere has been around officially since c99 and unofficially for much longer. For half or more of the 50-year history of C it has been allowed so most people with longtime C experience aren't going to be confused.
> 
> In fact C **never** required that **all** variables be declared at the beginning of a function. C has always allowed variables to be declared at the beginning of **any** block including unattached / unconditional blocks which I have personally used to great effect to limit the scope of temporary variables and to declare them close to where they were used going as far back as the 80s.
> 

Ok, but I'm not referring to the pure act of declaring variables
differently (i.e. such as limiting scope, the other examples given,
etc.). I'm referring specifically to a policy where all function scope
variables are uniformly declared at first use rather than at
top-of-function.

> > In the context of kernel development, something also tells me this has
> > potential to be a tinderbox for a flamewar, but who knows.. ;P
> 
> Well that may be the **real** issue! From the outside the kernel developers seem reluctant to revisit old decisions... It's 2024 and the mailing lists still don't accept modern email formats (HTML) which seem like they would make discussion easier. I used to be one of those people who resisted the change and preferred text-based email only but it's now been decades. Time to let that one go!
> 
> > ...
> 

Hah, well as a mutt user I have to disagree with the HTML thing. ;) But
to be fair, the fact that something might incite a flamewar in a
community that is historically pretty bad at level-headed discussion is
not a great argument. The real issue there is indeed something
different.

My concern with this was more that perhaps there might be indirect cost
to such a policy that might not be fully factored into the value
judgement of adopting it purely to minimize likelihood of a particular
class of bug.

Brian