[PATCH] Initialize m_hFile in FileMapping constructor.
iacobcatalin at gmail.com
Fri Mar 23 10:58:55 PDT 2012
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. ;)
> (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.
More information about the LibreOffice