Issue 114600 - assertion: bad pCharClass
Summary: assertion: bad pCharClass
Status: CLOSED FIXED
Alias: None
Product: porting
Classification: Code
Component: code (show other issues)
Version: DEV300m87
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: Mathias_Bauer
QA Contact: issues@porting
URL:
Keywords: regression
: 115522 (view as issue list)
Depends on:
Blocks:
 
Reported: 2010-09-19 18:43 UTC by 400guy
Modified: 2017-05-20 09:14 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description 400guy 2010-09-19 18:43:18 UTC 
To raise the assertion ...

(*) Open a new Writer document.

(*) Type two lines, "first line" and "second line".

(*) Save the document.

(*) Type ctrl-A to select the entire contents.  Program hightlights
    the selection.

(*) Type ctrl-X to delete the entire contents.  Program presents Debug
    Output ...

        Error: bad pCharClass
        From File /home/terry/OOo_hacking/DEV300_m87/sal/rtl/source/uri.cxx at
Line 604
        Abort ? (Yes=abort / No=ignore / Cancel=core dump)


I am running a non-product build of DEV300_m87.
Comment 1 Stephan Bergmann 2010-09-20 14:52:49 UTC 
Apparently a regression introduced with the fix for issue 106861. 
<http://hg.services.openoffice.org/cws/sw321bf01/rev/02b1fd6f2c08> uses
rtl::Uri::encode to encode a MIME parameter value in a broken way.  For one, the
calling code claims that '%' need not be encoded, which can never be true for
URI syntax (hence the failed assertion).  And for another, the calling code also
claims that '"' need not be encoded, which clearly conflicts with the clients'
use of quoted-string to encode the MIME parameter value.  Additionally, it looks
odd to put a protocol of URI-style--encoding a parameter value on top of MIME
instead of using RFC 2184 conventions directly.
Comment 2 Mathias_Bauer 2011-04-27 09:19:17 UTC 
*** Issue 115522 has been marked as a duplicate of this issue. ***
Comment 3 mikhail.voytenko 2011-05-04 11:48:31 UTC 
Indeed, it was a quick showstopper fix for the problem. Any available encoding way that would be accepted by mimetype format was better than the situation there. So it was indeed a misuse of the URI encoding to get a simple and fast solution.
Comment 4 Mathias_Bauer 2011-05-04 12:01:54 UTC 
So we can fix this by encoding the following characters in transfer.cxx

%
"
\
'

Adding a new function that implements RFC 2184 is out of scope for 3.4, IMHO.
Comment 5 Stephan Bergmann 2011-05-04 12:26:55 UTC 
svl/inettype.hxx and tools/inetmime.hxx deal with MIME type representations, but seem to not offer exactly what would be needed here (e.g., INetContentTypes::appendUSASCIIParameter only works for ASCII values).

@mba: Why include ' in the list of encoded characters?
Comment 6 Mathias_Bauer 2011-05-04 12:29:34 UTC 
Thanks for the heads-up, adding ' that was a mistake.