| Age | Commit message (Collapse) | Author |
|---|
|
Regression from 3.3.x.
Import of tab-delimited csv documents containing multi-line cells
were unfortunately broken with my fix for handling malformed csv
documents. The intent was to break out of the loop only when a tab
character is encountered before the closing quote is encountered, but
the old code would break out whenever a tab character is encountered
even outside the quotes.
This commit fixes it.
|
|
this patch removes the unused (according to OpenGrok) GetIsoFallback
function from the tools module.
|
|
This reverts commit bbad7057b2bdb614a5e97a945039323efe39c4ee.
|
|
|
|
|
|
|
|
The ones which use a definite 8-bit encoding read/write pascal-style
strings with a 16bit length prefix.
The ones which use a definite 16-bit encoding read/write pascal-style
UTF-16 strings with a 32bit length prefix, i.e. not ByteStrings at all
The "I dunno" ones might be UTF-16 strings or 8-bit strings, depending
on the charset. Rename to ReadUniOrByteString like the other
similar horrors to flag this misery
|
|
Nobody ever used the return values anyway, so for reading just
return the string and for writing the number of bytes written
Doesn't need to be members, make standalone functions
Rename to
read_lenPrefixed_uInt8s_ToO[U]String and
write_lenPrefixed_uInt8s_FromO[U]String, lengthy,
but much less unambiguous, seeing as a lot of users of it don't
seem to be aware that they read/write pascal-style length
prefixed strings, which isn't surprising given the
apparent simplicity of their original name.
added a unit test
|
|
This reverts commit 92f396733ebc518bcb7a9eae2dd3169d333b82b9.
|
|
This reverts commit d00fc0e293852cfc019ffaffa65bee327397677b.
|
|
The ones which use a definite 8-bit encoding read/write pascal-style
strings with a 16bit length prefix.
The ones which use a definite 16-bit encoding read/write pascal-style
UTF-16 strings with a 32bit length prefix, i.e. not ByteStrings at all
The "I dunno" ones might be UTF-16 strings or 8-bit strings, depending
on the charset. Rename to ReadUniOrByteString like the other
similar horrors to flag this misery
|
|
Nobody ever used the return values anyway, so for reading just
return the string and for writing the number of bytes written
Doesn't need to be members, make standalone functions
Rename to
read_lenPrefixed_uInt8s_ToO[U]String and
write_lenPrefixed_uInt8s_FromO[U]String, lengthy,
but much less unambiguous, seeing as a lot of users of it don't
seem to be aware that they read/write pascal-style length
prefixed strings, which isn't surprising given the
apparent simplicity of their original name.
added a unit test
|
|
|
|
|
|
|
|
|
|
Nobody ever checked the return value anyway, so just return the string
and use the stream state bits if necessary to find failures.
Doesn't need to be a member, make a standalone function
Rename it to read_zeroTerminated_uInt8s_AsO[U]String, stupid perhaps,
but *shrug*, unambiguous.
Drop misleading overloaded String variants use:
read_zeroTerminated_uInt8s_AsOString or
read_zeroTerminated_uInt8s_AsOUString
added a unit test, valgrinded it, found and fixed invalid read
in original implementation.
|
|
|
|
|
|
|
|
So drop the GVER thing and -DVCL and -DNT351.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+ IsValidDate() checks only day and month regarding the year, not Gregorian
cut-off date as now does IsValidAndGregorian().
+ Normalize() carries over invalid day and month values to next months and
years.
* All methods that return or internally use a day count now internally
normalize the date values, without modifying the actual Date instance. So,
if the date is not valid you may get unexpected results.
* Previously, a date with month>12 would had accessed the days-of-month
array out of bounds on all such methods. So you would had gotten
unexpected results anyway..
* Affected methods are:
GetDayOfYear()
GetWeekOfYear()
GetDaysInMonth()
static DateToDays()
|
|
+ IsValidDate() checks only day and month regarding the year, not Gregorian
cut-off date as now does IsValidAndGregorian().
+ Normalize() carries over invalid day and month values to next months and
years.
* All methods that return or internally use a day count now internally
normalize the date values, without modifying the actual Date instance. So,
if the date is not valid you may get unexpected results.
* Previously, a date with month>12 would had accessed the days-of-month
array out of bounds on all such methods. So you would had gotten
unexpected results anyway..
* Affected methods are:
GetDayOfYear()
GetWeekOfYear()
GetDaysInMonth()
static DateToDays()
|
|
Once smaller than 1582-10-15 decrementing a Date will not produce a valid date.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
