This is actually unnecessary as the call in question uses only fields
that have been set explicitly, but good practice regardless and it's
not like it's on a performance-critical path.
buffer. If snprintf truncated the output, the length returned will be
greater and we'll write trash. Just call strlen instead. (And since
what we're doing is writing progress messages to the user, checking
carefully for truncation isn't really worthwhile either.)
Spotted when attending to PR 50998 from David Binderman; the issue
there (computation of an unused value) popped up because one of the
prints was already calling strlen.
The loop that picks delay_divisor might conceivably reject all values,
particularly if the hardware is sulking for some reason; in that case
it'll be left zero. Use 1 instead of 0 so we don't then crash.
If we don't find one of the expected device addresses, reject the
match, but do it by checking whether the loop matched something rather
than by testing an array entry that might be one past the end.
Note: I have also moved the test to be with the loop; since the call
to intio_map_allocate_region had gotten placed in between them, I've
moved it to go before rather than after them as (a) it doesn't
interact with the loop itself and (b) this seems like the best choice
given the history as it was deliberately added before the original
test.
I have not tried running this, not having an x68k, but as best I can
tell by reading the intio code it seems like it should be harmless
even if it's not really correct.
do anything with it...) because it's zooming off the end of the array it's
trying to use.
It looks to me as if NEW_MAP_SIZE has been accidentally used as both
the number of blocks occupied by the new partition table and also the
number of entries in it. Or something. This needs platform knowledge
to sort out. XXX.
Workaround for PR 50757.
In the new sljt version, ppc_cache_flush() is guarded by
SLJIT_CACHE_FLUSH_OWN_IMPL. We can keep is as long as we
don't define SLJIT_CACHE_FLUSH_OWN_IMPL.
