In particular, a #f argument can make sense if the length is 0.
Technically, a byte string's byte array is supposed to be nul-terminated,
but many uses of byte strings get away without that terminator. I've
adjust the documentation to note that `bytes-copy` will work with a
non-terminated byte string.
Merge to v6.1.1
The fixup is not allowed to changed the virtual
address of a SHT_PROGBITS section, so a expanded
".dynstr" section might have to be moved to a
virtual address after everything else.
This bug could result in weird "cannot re-define a constant: lifted.0.2"
errors, or probably even worse collsisions of definitions, but I think
only in a namespace created from `module->namespace`.
So far, I haven't been able to create a reasonably small test,
because so many things have to line up in just the right way.
Merge to v6.1.1
If you set the locale to something like "us_EN.1252", then
"1252" was returned as the encoding, but "CP1252" is more likely
to be recognized by `bytes-open-converter`.
Also, document representation information on paths. In particular,
explain that Unix and Mac OS X paths are natively byte strings, while
Windows paths are natively UTF-16 code-unit sequences. The byte-string
representation of a Windows path is a UTF-8-like encoding of the UTF-16
code-unit sequence, which is why it makes no sense to convert it using
the current locale's encoding.
Sounds like a bad name, but I don't have anything better. It's not some
"current-...-print" thing since it works on the sexpr that is intended
to be pretty-printed. So I went with the above.
This uses a technique discovered by Ryan and Dan that
allows the typed class macro to function without invasively
local-expanding the entire class macro (using its private
context information).
Instead, it expands into many helper macros inside the
normal class body and communicates among them using
`syntax-local-value` and compile-time state within the
class body.
This rewrite didn't save that many lines, but it did
reduce the amount of magic that's used.
