As we have seen in the previous sections, both weird integers and unaligned integers usually imply that poke has to work with partial bytes. However, since the underlying IO devices are always byte oriented, poke needs to read in full bytes in order to work with a subset of them.
This may lead to surprising behavior when dealing with write-only IO spaces. Consider this scenario:
$ cat "abc" > writeonly $ chmod a-r writeonly $ ls -l writeonly --w------- 1 jemarch jemarch 4 Sep 16 22:37 writeonly
This can be written to, but not read from: it is write-only. If we then fire up poke and try to read its contents, we get:
(poke) dump 76543210 0011 2233 4455 6677 8899 aabb ccdd eeff 0123456789ABCDEF 00000000: ???? ???? ???? ???? ???? ???? ???? ???? ................ 00000010: ???? ???? ???? ???? ???? ???? ???? ???? ................ 00000020: ???? ???? ???? ???? ???? ???? ???? ???? ................ 00000030: ???? ???? ???? ???? ???? ???? ???? ???? ................ 00000040: ???? ???? ???? ???? ???? ???? ???? ???? ................ 00000050: ???? ???? ???? ???? ???? ???? ???? ???? ................ 00000060: ???? ???? ???? ???? ???? ???? ???? ???? ................ 00000070: ???? ???? ???? ???? ???? ???? ???? ???? ................
This is as expected: no bytes can be read from the read-only file. Writing, however, shall work in principle. Indeed, writes that involve full bytes (any number of them) work as expected:
(poke) byte @ 2#B = 'x'
The third character in the file indeed changes from 'c' to
'x', this can be verified by changing the permission of the
file and taking a look. But if a write involves writing partial
bytes, as it happens with weird integers and non-aligned integers,
poke cannot perform the operation:
(poke) byte @ 9#b = 'x' unhandled wrong permissions exception (poke) uint<3> @ 0#B = 2 unhandled wrong permissions exception