[PATCH] Initialize m_hFile in FileMapping constructor.

[Catalin Iacob]

On Fri, Mar 23, 2012 at 9:00 AM, Stephan Bergmann <sbergman at redhat.com> wrote:
> That looks like a compiler error.  Have you tried with a plain
> (non-OpenSUSE) GCC 4.6.2, too?  (What's also odd is the mention of
> "lockbyte.css" -- is that a typo of yours, or is that a temporary file that
> specific compiler generates internally?)

Typo, I edited that to remove the full paths and make it shorter.

> ...but only if tmp != value, which is not the case here, as both tmp and
> value are default-constructed.  And FileMapping::operator!= is careful not
> to use the potentially uninitialized m_hFile.
>

I noticed this too but it's complicated to follow so I wasn't sure I
got it right.

> ...but always initializing m_hFile is probably not a bad idea, anyway. And
> if it helps your compiler, all the better.  ;)

Exactly

> (Though I would prefer an
> explicit m_hFile(0) there, esp. given the other members do not rely on
> implicit value-initialization, either.)

I had to choose between () and (0) and picked () thinking it's more
future proof about the type of m_hFile: if oslFileHandle becomes a
class instead of a typedef for void* the (0) becomes either a
compilation error or a call to some constructor that takes an int. But
all this is pretty theoretical anyway, I'm happy either way.

> So pushed this now.

Thanks