Extend the fill, alignSize, align{2,4} methods of `std.outbuffer.OutBuffer` to specify value to write
when filling (up to an alignment).
For flash device images it is desirable to use 0xff as the fill value,
because 0xff is the value of the unprogrammed flash memory cell. Padding
with 0 requires to programm the flash cell from 0xff to 0x00, which
increases wear and tear on the flash memory device. Usually there is some
larger block at the end if the flash memory image, which must be padded
up to the size of the flash device (usuallay a power of two). Instead
of padding with 0x00 the PR allows to fill with 0xff instead.
There might also be other use-cases, where it might be reasonable to fill
the alignment gaps with some other value than 0x00, e.g. when debugging
and viewing output data in a hex editor. It is easier to spot gaps, when
the padded spaces contain a custom value like 0x55 or 0xaa.
A new fill method was added, which allows filling with a user-defined value
instead of the 0 as in the previous implementation.
`sysErrorString` throws an exception for unknown error codes (e.g. from
libraries using `SetLastError`) and hence could hide the actual error
that caused the call to `sysErrorString`.
The new helper function wraps the error code lookup and returns `Error X`
on failure.
This ensures that the actual error message won't be suppressed when the
lookup error code => message fails. The exception will also be more
informative because `WindowsException` is explicitly intended for
Windows API errors.
This ensures that the method throws a `WindowsException` initialised
with the proper error code. Also avoids unrelated exceptions that
could suppress the error which caused the call to `sysErrorString`.
Catch possible exceptions arising from e.g. UTF decoding and ensure
that the message buffer doesn't contain partial output from a failed
step.
The logic is seperated into a dedicated method because it's required
for another bugfix.
The template constraint is needed to ensure that the inout constructor
overload is only considered when it is an exact match, without qualifier
conversions.
Without the constraint, a constructor call such as
const(SumType!(int[]))([1, 2, 3])
...would be ambiguous, since it would match both the const constructor
overload and the inout constructor overload at the "match with qualifier
conversion" level.
merge stable
Signed-off-by: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Merged-on-behalf-of: Nicholas Wilson <thewilsonator@users.noreply.github.com>
