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.
GCC warns about switch statement fall-throughs unless they are annotated
with a /* fall through */ comment. However, it also has a mode that
understands the comment as long as it has the words "fall through"
somewhere in it. If we slightly tweak the wording of this comment, we can
use that mode to avoid the warning.
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.
Here, a value was being compared for equality with itself. GCC warns that
this is probably a mistake. I'm assuming that here we are meant to write
out a word count when the minimum and maximum counted words are equal?
This method is called with INT_METHOD_CALL, but had a void return type.
This caused the return value to be some random value from the stack, and
if it happened to be FALSE, LanguageMethods::tangle_line would write the
line out a second time. This was causing inweb to output invalid programs
due to every line being duplicated.
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.
