the first partition as root - in mixed EFI/BIOS setups this might not
be true (and in general the user is free to define arbitrary orders).
Pointed out by Robert Nestor.
GCC_NO_FORMAT_TRUNCATION -Wno-format-truncation (GCC 7/8)
GCC_NO_STRINGOP_TRUNCATION -Wno-stringop-truncation (GCC 8)
GCC_NO_STRINGOP_OVERFLOW -Wno-stringop-overflow (GCC 8)
GCC_NO_CAST_FUNCTION_TYPE -Wno-cast-function-type (GCC 8)
use these to turn off warnings for most GCC-8 complaints. many
of these are false positives, most of the real bugs are already
commited, or are yet to come.
we plan to introduce versions of (some?) of these that use the
"-Wno-error=" form, which still displays the warnings but does
not make it an error, and all of the above will be re-considered
as either being "fix me" (warning still displayed) or "warning
is wrong."
- file has looks bogus maybe-uninitialized
- llvm triggers an attribute violation:
ScheduleDAGInstrs.cpp:1430:14: error: declaration of
'llvm::raw_ostream& llvm::operator<<(llvm::raw_ostream&, const llvm::ILPValue&)'
with attribute 'noinline' follows inline declaration [-Werror=attributes]
- ntp and pkg_install have obvious restrict violations, should be
fixed but i'm avoiding patching upstream code in this pass
- tftp has an array bounds that doesn't seem real issue
- sysinst's partman.c has major problem with passing the same
string as source and dest in snprintf, as a way to strcat
with formatting which trip restrict violations. non trivial
to fix so for now the warning is elided.
- Xext's XEVI.c has similar issue as partman.c
everyone and GCC 8 gets these warnings turned off for now:
-Wno-format-truncation
-Wno-stringop-overflow
-Wno-stringop-truncation
-Wno-cast-function-type
as they trip a large amount of code. most of them should be
investigated, but the few i looked at were not finding actually
real bugs, vs instances of poor coding, so skipping for now.
with proper options, and the installed system does not use NAME= syntax
in fstab(5), use the device name we used to get here, instead of the
name from fstab, it might be different to what the real system calls the
device (compact flash root showing up as wd0 native, but sd? on the
card reader used for updating it right now).
This is an abuse of the upgrade functionality and in general pretty dangerous
when multiple devices are used in the upgraded fstab (e.g. separate /usr),
and it used to work more by accident with the old code.
However, it is a quite usefull way to upgrade tiny systems with compact flash
root, and it used to work - so support it properly (as far as we can).
Make supported file system types dynamic - instead of hardcoding the
available types at compile time, check for available newfs_* helper
binaries in the actual install environment at runtime.
martin