In the family of functions that create a text stream from a string (e.g.,
Streams::open_from_ISO_string, Str::new_from_ISO_string) we can mark the
input string as const since it is not supposed to be modified.
I ran into this when experimenting with trying to create a text stream
from the output of "getenv" which is "const char *". I ended up not
needing that, but this seems like a good change nonetheless.
By my reading of the semantic versioning spec, the sense of the comparison
of the number of prerelease version segments has to be reversed when one
of those numbers is zero.
In other words, zero prerelease segments takes precedence over any nonzero
number, but any nonzero number takes precedence over any lower nonzero
number.
Example given in the specification:
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta <
1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.
I had two failing test cases in foundation-test; in one case, the blessed
output seemed to be wrong, whereas the other case made this fix necessary.
There's a possible execution path here, where extindex is equal to 0 at
the time it's used as the count parameter in strncpy. GCC warns about this
because it leaves the destination string unchanged while the programmer
may expect it to be 0-terminated.
In this case it's OK because we write a 0 to the string directly
afterwards, but still we can silence the warning and avoid a no-op call
to strncpy by checking the count first.
Without including stdint.h, the compiler chokes on uint32_t. I assume that
on other platforms, another header must be pulling it in already, but on
GCC on Linux, it's not. However, stdint.h should be safe to include on all
platforms as it's part of C99.
