Document lack of support for 16-bit pointers #663
Conversation
This clearly states lack of support for 16-bit architectures as well as adds readable `compile_error!()` call. It also fixes a few stylistic mistakes - headings (top-level should not be repeated) and missing newlines. Closes rust-bitcoin#660
| ever be fixed, and there are no plans to do so. Of course, patches to | ||
| fix specific consensus incompatibilities are welcome. | ||
|
|
||
| ### Support for 16-bit pointer sizes |
There was a problem hiding this comment.
Nit: The limitation is that there is no support.
| ### Support for 16-bit pointer sizes | |
| ### No support for 16-bit pointer sizes |
There was a problem hiding this comment.
I went for consistency with previous chapter ("Consensus", not "No consensus").
TheBlueMatt
left a comment
TheBlueMatt
left a comment
There was a problem hiding this comment.
Note that even if we did 16-bit pointer support we'd have a lot of limitations - eg we can never deserialize or serialize a block as they're regularly longer than 64KiB.
|
We could with streaming deserialization which I was thinking of proposing but decided not to until I profile |
I don't think a host with 16-bit pointers will support deserializing a 4MiB object whether the source is a stream or not, given it only supports process memory of 64KiB :p |
|
@TheBlueMatt presumably it'd read data off some other storage medium using larger addressing integer just as it's possible to use more than 4GiB HDD on 32-bit platforms. :) Of course it couldn't hold whole thing in memory but some applications don't have to. |
5 participants
This clearly states lack of support for 16-bit architectures as well as
adds readable
compile_error!()call. It also fixes a few stylisticmistakes - headings (top-level should not be repeated) and missing
newlines.
Closes #660