The ones which use a definite 8-bit encoding read/write pascal-style
strings with a 16bit length prefix.
The ones which use a definite 16-bit encoding read/write pascal-style
UTF-16 strings with a 32bit length prefix, i.e. not ByteStrings at all
The "I dunno" ones might be UTF-16 strings or 8-bit strings, depending
on the charset. Rename to ReadUniOrByteString like the other
similar horrors to flag this misery
Nobody ever used the return values anyway, so for reading just
return the string and for writing the number of bytes written
Doesn't need to be members, make standalone functions
Rename to
read_lenPrefixed_uInt8s_ToO[U]String and
write_lenPrefixed_uInt8s_FromO[U]String, lengthy,
but much less unambiguous, seeing as a lot of users of it don't
seem to be aware that they read/write pascal-style length
prefixed strings, which isn't surprising given the
apparent simplicity of their original name.
added a unit test
WriteLine just writes a line of text, WriteByteString writes
a 16bit length of following content. It can't make sense to
suddenly stick a pascal-style string in at the end of a file
that's otherwise plain text.
original git id that introduced the use of WriteByteString here
was ea76474a back in 2002
Perhaps this worked because partial strings never ended up
as trailing content, so only ever had an empty string as
the final partial string, so a 0x0000 got appended, as
opposed to a newline, so it appeared to do the right thing.
also use icon names *3.5* instead of *35*; this version is used on another
locations as well; it allows to reuse the UNIXBASISROOTNAME variable that
is substituted by the installer
rasqal 0.9.27 returns no variables for a SPARQL SELECT query with no
results; it is unclear whether that is allowed but it is a corner case
and probably we should not be testing for that.
When we have two consecutive paragraphs with different frame properties,
the second frame wasn't created. Now store the current paragraph
properties in order to create the frame later.
