Fix uninitialized read of size 1 in little2_updatePosition
Reported by Pascal Cuoq
Valgrind's view:
==4416== Conditional jump or move depends on uninitialised value(s)
==4416== at 0x41F187: little2_updatePosition (xmltok_impl.c:1748)
==4416== by 0x405F85: XML_GetCurrentColumnNumber (xmlparse.c:1931)
==4416== by 0x402F7B: reportError (xmlfile.c:67)
==4416== by 0x403041: processFile (xmlfile.c:84)
==4416== by 0x403752: filemap (unixfilemap.c:61)
==4416== by 0x403523: XML_ProcessFile (xmlfile.c:239)
==4416== by 0x402EBC: main (xmlwf.c:847)
Failing tests are:
[-] UTF-8 case 3: Expected movement by -1 chars, actually moved by 0 chars: "\xdf"
[-] UTF-8 case 4: Expected movement by 0 chars, actually moved by -1 chars: "\xdf\xbf"
[-] UTF-8 case 5: Expected movement by -1 chars, actually moved by 0 chars: "\xef"
[-] UTF-8 case 6: Expected movement by -2 chars, actually moved by -1 chars: "\xef\xbf"
[-] UTF-8 case 7: Expected movement by 0 chars, actually moved by -2 chars: "\xef\xbf\xbf"
[-] UTF-8 case 8: Expected movement by -1 chars, actually moved by 0 chars: "\xf7"
[-] UTF-8 case 9: Expected movement by -2 chars, actually moved by -1 chars: "\xf7\xbf"
[-] UTF-8 case 10: Expected movement by -3 chars, actually moved by -2 chars: "\xf7\xbf\xbf"
[-] UTF-8 case 11: Expected movement by 0 chars, actually moved by -3 chars: "\xf7\xbf\xbf\xbf"
Pascal Cuoq [Sun, 15 May 2016 17:11:55 +0000 (19:11 +0200)]
Avoid undefined behavior when computing larger blockSize. The compiler might reason that (end - start)*2 is negative only if (end - start) is negative, see https://godbolt.org/g/wVEoTM
lib/xmltok.c:1407:11: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
lib/xmltok.c:1409:16: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
Since commit e3e81a6d9f0885ea02d3979151c358f314bf3d6d
(released with Expat 2.1.0) Expat called srand by itself
from inside generate_hash_secret_salt for an instance
of XML_Parser if XML_SetHashSalt was either (a) not called
for that instance or if (b) salt 0 was passed to XML_SetHashSalt
prior to parsing. That call to srand passed (rather litle)
entropy extracted from the current time as a seed for srand.
That call to srand (1) broke repeatability for code calling
srand with a non-random seed prior to parsing with Expat,
and (2) resulted in a rather small set of hashing salts in
Expat in total.
For a short- to mid-term fix, the new approach avoids calling
srand altogether, extracts more entropy out of the clock and
adds some additional entropy from the process ID, too.
For a long term fix, we may want to read sizeof(long) bytes
from a source like getrandom(..) on Linux, and from similar
sources on other supported architectures.
examples/elements.c: Address compile warning on sign mismatch
examples/elements.c: In function ‘main’:
examples/elements.c:54:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
done = len < sizeof(buf);
^
doc/xmlwf.1: Generate from sources using docbook2X
As aside effect the mistaken content
BUGS
According to the W3C standard, an XML file without a
declaration at the beginning is not considered well-formed.
However, xmlwf allows this to pass.
disappears from the man page. This is related to bug 470
https://sourceforge.net/p/expat/bugs/470/ or
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412786
in Debian.
CMakeLists.txt: Align binary locations with Autotools
Target "xmlwf" even collided with the source folder of the
same name, previously:
$ cmake . && make
...
[ 82%] Linking C executable xmlwf
.../ld: cannot open output file xmlwf: Is a directory
collect2: error: ld returned 1 exit status
...
Karl Waclawek [Sun, 11 Mar 2012 05:13:12 +0000 (05:13 +0000)]
Fix for bug #3500861 did not work properly, fixed the fix by applying
the setContext() call only to the root parser.
Also added a make target to run the benchmark - it relies on the testdata
module being present at the same location as in the repository.
projects / libexpat / log