On the OpenIndiana Hipster distribution, compiling with GCC 4.9 would
fail because __BYTE_ORDER__ was defined but not to any of the values
assumed to be associated with this define (__LITTLE_ENDIAN__ or
__BIG_ENDIAN__). Instead it was defined to either
__ORDER_LITTLE_ENDIAN__ or __ORDER_BIG_ENDIAN__. This caused
compilation to fail.
Fixed by checking that all referenced defines are in fact defined
before using them and adding an additional #elif clause for this newly
discovered condition.
The previous fix for the warning referred to 'prevbuf' being used
uninitialized and this is also what the compiler says. However
initializing 'prevbuf' doesn't make the warning go away and further
testing revealed that it is really 'savebuf' being possibly used prior
to initialization that is the source of the warning (the incorrect
warning message is probably an optimization-related gcc bug). So replace
previous ineffective fix with explicit initialization of 'savebuf'.
For 64-bit (e.g. x86_64) Linux the 64-bit wide types resolve to long,
not long long as is the case in 32-bit (e.g. i386) Linux. So we need an
explicit cast to long long for 64-bit types since the format string must
specify the 'll' modifier in order to print 64-bit values.
Some compilers issue a warning when a pointer is initialized in
both alternatives of a condition. Force an extra initialization
to avoid such warnings.
Closing the volume is the way to sync the MFT to disk. When not doing
so, the MFT runlists in $DATA and $Bitmap are not synced if they have
been updated in the second resizing stage relative to runlists which
have grown outside their original MFT record.
Unlike in most cases, the bad sector inode has to be closed if it
was updated and required MFT extents (when there are a lot of bad
sectors and some of them were outside the truncated partition).
Not doing so causes the inode to not be fully synced to device.
This fixes compiler warnings emitted when you compare an le32 value with
e.g. 'const_cpu_to_le32(-1)' on a little-endian system, because
previously the expansion of the macro expression 'const_cpu_to_le32(-1)'
would be '(-1)' on a little-endian system but '(u32)((((u32)(-1) &
0xff000000u) >> 24) | (((u32)(-1) & 0x00ff0000u) >> 8) | (((u32)(-1) &
0x0000ff00u) << 8) | (((u32)(-1) & 0x000000ffu) << 24))' on a
big-endian system, i.e. the type of the expanded expression would be
'int' (signed) in the little-endian case but 'u32' (unsigned) in the
big-endian case.
With this commit the type of the expanded expression will be 'le32' in
both the little-endian and the big-endian case.
This field is always assigned a signed value, and compared to other
signed values (ntfs_time values are signed little-endian 32-bit
integers).
This fixes two compiler warnings about signed/unsigned comparison.
These variable are only ever assigned to/from s64 values, so their type
should be s64, not u64. This fixes a compiler warning about
signed/unsigned comparison.
The UTF-16LE label buffer containing the result of mbs2ucs is the one
that should be NULL-terminated when the label is longer than permitted.
Not the input buffer, which is a function parameter assumed to be
NULL-terminated anyway.
This is done to match the type of the LSN struct members in layout.h.
The effect of this change is that while these members were declared with
the le64 type previously, leLSN resolves to sle64. I.e. what was
previously unsigned fields are now signed.
Following this change we also need to switch over a few macros from
unsigned to signed versions in the code that uses these struct
definitions.
Strict checking of endian-specific types mean that types that have a
fixed endianness in the data representation of the value are now defined
as complex types, enabling the compiler to catch mixed usage of these
types with native-endian types. This allows us to catch most issues
relating to usage on big-endian systems since we cannot anymore assign a
fixed-endian value to a native-endian variable and vice-versa without a
compiler error.
The downside is that we aren't able to apply simple binary operators to
the fixed-endian types anymore since they are complex... so all
combining fixed-endian constants and values with |, &, etc. and
comparison with ==, !=, <=, etc. must be replaced with a macro which
unpacks the wrapped value and performs the operation. Lots of changes,
lots of work but in the interest of good code quality it's justified.