https://bugs.freedesktop.org/show_bug.cgi?id=58838
Owen Genat <owen.ge...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Hardware|Other |All
OS|Windows (All) |All
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #5 from Owen Genat <owen.ge...@gmail.com> ---
I am now confirming this bug as a result of further testing and to partly to
get developer input on what is happening here. Status set to NEW. Version left
as-is due to the original report mentioning U+0173 and this does appear to have
changed behaviour under v3.6. Platform set to All/All. Expanding on my testing
in comment #2:
> I have conducted these tests under Ubuntu 10.04 x86_64 running TDF LO
> v.3.5.7.2 and
> TDF LO v4.0.2.2. There is no difference in output between the LO versions. As
> can
> be seen in the attachment most empty string tests return a FALSE value that
> is the
> same as that returned for a NULL value. There are some characters though
> (0-8,
> 14-31, 127, 249-251, 254-255 for the CHAR() function and 0-8, 14-31, 127-132,
> 134-159 for the UNICHAR() function) that return a TRUE value.
I have now opened the attachment to that comment under Crunchbang 11 x86_64
running:
- v3.3.4.1 OOO330m19 Build:401
- v3.4.6.2 OOO340m1 Build:602
- v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v3.6.7.2 Build ID: e183d5b
- v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a
Character comparisons, for the CHAR and UNICHAR functions, that report TRUE
when equated with an empty string (via infix operator "=") are listed (refer
columns E and I). Anomalies in comparing the returned boolean values (columns
O, P, Q) are also indicated:
v3.3.4.1
CHAR: 0-8, 14-31, 127.
UNICHAR: 0-8, 14-31, 127-132, 134-159.
All boolean results compare OK.
v3.4.6.2
As above for v3.3.4.1.
v3.5.7.2
CHAR: 0-8, 14-31, 127, 249-251, 254-255.
UNICHAR: 0-8, 14-31, 127-132, 134-159.
All boolean results compare OK.
v3.6.7.2
CHAR: 0-8, 14-31, 127, 249-251.
UNICHAR: 0-8, 14-31, 127-132, 134-159, 173.
All boolean results compare OK.
v4.0.6.2
As above for v3.6.7.2.
v4.1.3.2
CHAR: 0-8, 14-31, 127, 249-251.
UNICHAR: 0-8, 14-31, 127-132, 134-159, 173.
Boolean results for 254-255 return FALSE even though both character comparisons
(CHAR and UNICHAR) also return FALSE. This appears to be erroneous.
Overall the behaviour of characters 173, 249-251, and 254-255, when compared
against an empty string, have changed across versions. In itself this is not
unusual or worrying other than there does not appear to be any discernible
pattern to the changes, especially in terms of improvement or consistency.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
