VS 2013 warns: Conversion rules for arithmetic operations in the
comparison mean that one branch cannot be executed.
Change-Id: I85f6df16b0ced94677568441d87a588bed1bfb9b
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
GCC gives the following warning which breaks compilation when using --enable-werror:
lockbyte.cxx: In function 'storeError store::FileLockBytes_createInstance(rtl::Reference<store::ILockBytes>&, rtl_uString*, storeAccessMode)':
lockbyte.css:512:37: error: 'prephitmp.221' may be used uninitialized in this function [-Werror=uninitialized]
lockbyte.cxx:906:1: note: 'prephitmp.221' was declared here
It's not clear from GCC's message, but what it warns about is
FileMapping::m_hFile. This is because of the following sequence:
* xMapping.release() makes xMapping.m_value be a default constructed
FileMapping
* the xMapping local variable in store::FileLockBytes_createInstance
gets destructed
* ~ResourceHolder() calls ResourceHolder::reset
* ResourceHolder::reset() calls FileMapping::UnmapFile::operator()
passing m_value as rMapping
* FileMapping::UnmapFile::operator() uses rMapping.m_hFile but
rMapping is a default constructed FileMapping and therefore has
m_hFile uninitialized
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>:
To me, this looks more like a compiler error. Also note that
ResourceHolder::reset only calls FileMapping::UnmapFile::operator() if tmp !=
value, which is not the case here, as both tmp and value are default-
constructed. And FileMapping::operator!= is carefule not to use the potentially
uninitialized m_hFile. But always intiializing m_hFile is probably not a bad
idea, anyway. And if it helps a certain compiler, all the better.
have MappedLockBytes take complete ownership of the file handle and
unmap it and close it on release. Otherwise xFile will close it
and MappedLockBytes will unmap it in that order, which breaks
post android requirement to have a valid file handle in unmap
On Android, when an app is installed, arbitrary files bundled in the
app won't be unpacked into actual separate files in the file
system. They will exist only as archive entries in the .apk file
(which is a zip archive).
The SDK tooling puts such files under the /assets folder in the
.apk. The LibreOffice bootstrapping code for Android maps the .apk
file into memory.
osl_openFile() knows about the /assets special case, and uses a
separate abstraction for such memory-mapped files.
Obviously, when producing an .apk, one needs to make sure these
bundled files are not compressed, if one wants to be able to use them
directly from the memory-mapped .apk file. We do that in our test and
sample Android projects.
When mapping such files under /assets , just return a pointer to the
file's location inside the mapped .apk archive.
We can't use the old osl_unmapFile() on such mapped files, as that
would unexpectedly unmap fairly arbitrary pages of the .apk mapping,
wreaking havoc on later use of the same pages.
So, introduce a new osl_unmapMappedFile() function that takes also the
oslFileHandle originally passed to osl_mapFile(). Use this instead in
the few places where the code actually called osl_unmapFile(). Make
sure osl_mapFile() is nonexistent on Android.
