| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| | |
zone offset
|
| | |
| |
| |
| | |
positive time zone offset like "31 Jan 14 23:59:59 +0100"
|
| |/
|
|
| |
change was only meant for builds with TCL_UTF_MAX > 3.
|
| |\ |
|
| | |\ |
|
| | |\ \
| | | |
| | | |
| | | |
| | | | |
default read ahead limit set to 4K (instead of 1); better SF/BO prevention;
code simplification, no interim copy/move buffers, no decompression d-string, the inflate occurring in single step (ResultDecompress combines ResultGenerate and ResultCopy);
better handling in non-blocking mode (also recognizes or distinguish no data/EAGAIN cases).
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
expansion) and [f70ce1fead] (multi-stream decoding without readahead limit shenanigans) are fixed.
Verified that the tests fail with commit [4eb66645d6], just before the zlib fixes.
Tweaked the zlib manpage paragraphs about -limit.
Tweaked some code comments.
Fixed typos in description of two unrelated zlib tests.
|
| | | | |
| | | |
| | | |
| | | | |
d-string, the inflate occurring in single step (ResultDecompress combines ResultGenerate and ResultCopy); better handling in non-blocking mode (also recognizes or distinguish no data/EAGAIN cases)
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
generate needed anymore
|
| | | | |
| | | |
| | | |
| | | | |
(4K); better fix avoiding BO (replacement for [54605d16b9])
|
| | | | |
| | | |
| | | |
| | | | |
done (and unget the unprocessed data back to input channel)
|
| |\ \ \ \
| |/ / / |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| |/ / / |
|
| | | | | |
|
| | |\ \ \
| | | |/
| | |/| |
|
| | | | |
| | | |
| | | |
| | | | |
(parse.tokenPtr may be used uninitialized, for instance it returns from Tcl_ParseCommand etc with error before TclParseInit gets called)
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | | |
with literal T behaves strange
(I like it!)
|
| | | |
| | |
| | |
| | | |
U+FFFF.
|
| | | |
| | |
| | |
| | | |
for lead bytes F0-F5, Tcl_UtfCharComplete() should guarantee that those 4 bytes are available, not 3.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
individual bytes of a string searching for '(', ')', '::' or other single bytes. It is overkill to use Tcl_UtfPrev/Tcl_UtfNext for that, since those characters can only appear as their ASCII byte, not as any other sequence.
This effectively removes the last Tcl_UtfNext() call from the core, the only ones left are in tclTest.c for test commands. So the TclUtfNext() macro doesn't make sense any more.
Remove "register" keyword from many files.
|
| | | | |
| | | |
| | | |
| | | | |
individual bytes of a string searching for '(', ')', '::' or other single bytes. It is overkill to use Tcl_UtfPrev/Tcl_UtfNext for that, since those characters can only appear as their ASCII byte, not as any other sequence.
|
| |\ \ \ \
| |/ / /
|/| | | |
|
| | |\ \ \
| | | | |
| | | | |
| | | | | |
TCL_UTF_MAX value, since we didn't figure out yet how it should behave for TCL_UTF_MAX>3.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
correct, now they are. Make next/prev behavior the same for all TCL_UTF_MAX values, since the exact behavior for TCL_UTF_MAX>3 should be worked out further for Tcl 8.7 first, then everything agreed upon can be backported.
|
| | |\ \ \ \
| | |/ / /
| | | | |
| | | | | |
the right answer. Add testcase 4.14 with similar corner-case, this one is OK.
|
| | | | | | |
|
| | |/ / /
|/| | |
| | | |
| | | |
| | | | |
[6596c4af31e29b5d]. Just look at the Tcl_UtfAtIndex() implementation for TCL_UTF_MAX=4: It's not the same.
There are no test-cases for Tcl_UniCharAtIndex(), see [f45d0dc1a7], not really worth to write one, since the implementation of this function didn't change in 20 years.
|
| | | | |
| | | |
| | | |
| | | | |
Christian Werner for the Bug report and the Fix.
|
| | | | |
| | | |
| | | |
| | | | |
testcases in 4 groups (utf-7.10, utf-7.15, utf-7.40 and utf-7.48) , where Tcl_UtfPrev() didn't jump to the beginning of the UTF-8 character, even though there was no limitation which prevented that. So, this is actually a bug-fix for the TIP #389 implementation.
|
| | | | | |
|
| | | | |
| | | |
| | | | |
For start bytes F0-F4, case TCL_UTF_MAX=4, Tcl_UtfToUniChar() reads 3 bytes but only advances 1 byte. So Tcl_UtfCharComplete() must make sure 3 bytes are available, not 1. Adapt Tcl_UtfCharComplete() accordingly. No change for TCL_UTF_MAX=[3|6]
|
| |\ \ \ \ |
|
| | |\ \ \ \
| | |/ / / |
|
| | | |\ \ \ |
|
| | |/ / / /
| | | | |
| | | | | |
recent reforms. Older efforts aborted.
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | | |
in "utf16" build any more.
|
| | | | | | |
| | | | | |
| | | | | | |
Make sure that Tcl_UtfPrev() never reads more than 3 trail bytes (or 4 when TCL_UTF_MAX > 4). Those are the same limits as for Tcl_UtfNext() and Tcl_UtfToUniChar()
|
| | |\ \ \ \ \ |
|
| | | | | | | | |
|
| | |\ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \
| |_|_|_|_|_|_|/ / /
|/| | | | | | | / /
| | |_|_|_|_|_|/ /
| |/| | | | | | | |
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
bytes after the string-end are read. The command will return -1 in that case. No need for additional arguments any more.
|
