Issue 70752 - unhelpful string constructors ...
Summary: unhelpful string constructors ...
Status: ACCEPTED
Alias: None
Product: utilities
Classification: Unclassified
Component: code (show other issues)
Version: 680m189
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: OOo 3.x
Assignee: AOO issues mailing list
QA Contact: issues@tools
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-23 17:37 UTC by mmeeks
Modified: 2017-05-20 11:33 UTC (History)
3 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 mmeeks 2006-10-23 17:37:31 UTC 
The existing string constructors cause problems because people do:

String( ...CONST_ASCII_PARAM("foo"))

and this bogusly passes the length as the textencoding to the string:

UniString( const sal_Char* pByteStr,
	   rtl_TextEncoding eTextEncoding,
	   sal_uInt32 nCvtFlags = BYTESTRING_TO_UNISTRING_CVTFLAGS );

Which is deadly broken - a number of these happen on OO.o startup, see bug i#70166#.

In order to do anything, I'd like a design that would be acceptable up-stream,
an idea might be some:

class StringEncoding {
      rtl_TextEncoding eEncoding;
public:
     explicit StringEncoding( rtl_TextEncoding eFoo ) : eEncoding (eFoo) {}
};
...


UniString( const sal_Char* pByteStr,
-	   rtl_TextEncoding eTextEncoding,
+	   StringEncoding aTextEncoding,
	   sal_uInt32 nCvtFlags = BYTESTRING_TO_UNISTRING_CVTFLAGS );

or whatever you like.
Thanks.
Comment 1 Stephan Bergmann 2006-10-24 08:40:58 UTC 
taken over
Comment 2 Stephan Bergmann 2006-10-24 16:01:00 UTC 
I would suggest to just drop

UniString(
  const sal_Char* pByteStr,
  rtl_TextEncoding eTextEncoding,
  sal_uInt32 nCvtFlags = BYTESTRING_TO_UNISTRING_CVTFLAGS);

and only keep

UniString(
  const sal_Char* pByteStr,
  xub_StrLen nLen,
  rtl_TextEncoding eTextEncoding,
  sal_uInt32 nCvtFlags = BYTESTRING_TO_UNISTRING_CVTFLAGS);

and do an incompatible cleanup from tools upwards.  (ByteString, rtl::OUString,
rtl::OString seem to not have any equally problematic functions, by the way.)

@kr,mt:  Are you planning on any tools string changes, anyway?  Otherwise, I
would suggest we do this on a OOo 2.x target (I assume there are not too many
occurrences of that constructor).
Comment 3 Stephan Bergmann 2006-10-24 16:10:44 UTC 
It appears that issue 70166 will introduce some code to work around consequences
of this issue.  That work-around code should be removed once this issue is fixed.
Comment 4 kay.ramme 2006-10-24 17:21:01 UTC 
Removing the c'tor looks fine for me!
Comment 5 Stephan Bergmann 2006-10-25 08:57:03 UTC 
Valid uses of the to-be-dropped ctor

  String(p, enc[, flags])

can be replaced with

  String(p, STRING_LEN, enc[, flags])

see tools/source/string/strucvt.cxx:1.10 l. 115--116.
Comment 6 Mathias_Bauer 2007-12-04 14:47:41 UTC 
according to release status meeting -> target 3.x
Comment 7 Marcus 2017-05-20 11:33:52 UTC 
Reset assigne to the default "issues@openoffice.apache.org".