The warnings looked like this:
htmlparse.c: In function ‘yyparse’:
htmlparse.c:1810:18: warning: passing argument 1 of ‘yyerror’ from incompatible pointer type [-Wincompatible-pointer-types]
htmlparse.y:40:13: note: expected ‘PyObject ** {aka struct _object **}’ but argument is of type ‘PyObject * {aka struct _object *}’
htmlparse.c:1927:12: warning: passing argument 1 of ‘yyerror’ from incompatible pointer type [-Wincompatible-pointer-types]
htmlparse.y:40:13: note: expected ‘PyObject ** {aka struct _object **}’ but argument is of type ‘PyObject * {aka struct _object *}’
The argument is not used, so it doesn't really matter what pointer type
it is.
Fixes a bunch of warnings like
htmlparse.y:509:25: warning: operation on ‘self->userData->buf’ may be undefined [-Wsequence-point]
htmlparse.y:518:29: warning: operation on ‘self->userData->tmp_buf’ may be undefined [-Wsequence-point]
which were a result of (macro-expanded) code like this (simplified):
if ((tmp = (tmp = PyMem_Realloc(...))) == NULL) return NULL;
The PyMem_Resize(p, ...) macro assigns the new value to p before
returning it, so there's no need to assign it again.
See http://bugs.python.org/issue1668036 for evidence (from 2007) that
this is indeed a documented side-effect of the macro API.
tough call, but i think it actually matters... In the code of conduct,
a "community member" is not necessarily an official status. by
conflating the "maintainer" and "member" status, we would have
diminished the role of non-official members... People are a member of
the community when they participate, regardless of their official
status, and deserve the same respect as anyone else.
also use "administrator" instead of "owner". i do not "own" this
project, i administer it. we do not have to comply with GitHub's
proprietary vocabulary
The test unzipps a zip file with a weird-looking non-ASCII filename in it.
I don't think zip files specify the encoding for filenames. Different
unzip utilities may interpret the filename differently. Plus, the byte
representation of the unzipped filename may be different depending on
the filesystem charset.
To me it looks as if the filename is garbage encoded as valid UTF-8, and
the test expectation is to get it in latin-1 or something.
The HTML tag has two attributes with URLs:
<applet archive="file.html" src="file.css">
It would appear that the order in which these attributes are crawled
does not match the order in the result file.
Possibly the crawling order is non-deterministic, although I cannot
reproduce that. If that's the case, the fix would be to sort the
attributes in the crawler before following them, which means we want the
expected results sorted as well (and since 'archive' comes before 'src',
so file.html should come before file.css).
We must do this, because py.test adjusts sys.path to make
'tests.test_foo' importable [*]. When py.test does this, the
'linkcheck' directory at the top of the git tree is the one that gets
imported in the tests. If we've told pip to use develop mode, all's
fine. If we haven't, then we're going to get errors because extension
modules like _network.so get installed into
.tox/*/lib/*/site-packages/linkcheck/network and not into
./linkcheck/network/
[*] http://doc.pytest.org/en/latest/goodpractices.html#choosing-a-test-layout-import-rules
