Issue 114600 - assertion: bad pCharClass
Summary: assertion: bad pCharClass
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
Keywords: regression
: 115522 (view as issue list)
Depends on:
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: ---


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. 
<> 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.