Debian Bug#178459
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=178459

Related to issue 7161 that got out of my sight and seemed to develop
into something being a MacOSX problem.

If under Unix the locale environment specified with either LC_ALL,
LC_CTYPE, or LANG (with LC_ALL taking precedence over LC_CTYPE taking
precedence over LANG) is not supported by the OS (for example,
LC_ALL=xx) and the terminal output of an OOo startup reads

I18N: Operating system doesn't support locale ""

and you select menu Tools.Options.Load/Save.HTML_Compatibility the
application crashes:

#0  0x40b7858f in strlen () from /lib/libc.so.6
#1  0x40589b9a in rtl_getTextEncodingFromMimeCharset ()
   from /usr/lib/openoffice/program/libsal.so.3
#2  0x420a1cde in SvxTextEncodingBox::FillWithMimeAndSelectBest() ()
   from /usr/lib/openoffice/program/libsvx641li.so

In SvxTextEncodingBox::FillWithMimeAndSelectBest()
rtl_getTextEncodingFromMimeCharset() is called with a pCharSet* obtained
from rtl_getBestMimeCharsetFromTextEncoding() without checking for a
null pointer.

I found the following places where the offending code combination of
rtl_getBestMimeCharsetFromTextEncoding() /
rtl_getTextEncodingFromMimeCharset() is used without checking for the
null pointer.

svx/source/dialog/txencbox.cxx SvxTextEncodingBox::FillWithMimeAndSelectBest()
offmgr/source/offapp/app/htmlcfg.cxx OfaHtmlOptions::GetTextEncoding()
sfx2/source/bastyp/frmhtmlw.cxx SfxFrameHTMLWriter::Write()
sw/source/filter/html/wrthtml.cxx SwHTMLWriter::WriteStream()
sw/source/ui/uiview/srcview.cxx SwSrcView::SaveContent()
sw/source/ui/uiview/srcview.cxx SwSrcView::Load()

Here the pointer is unconditionally used to create a UniString:
forms/source/component/DatabaseForm.cxx ODatabaseForm::InsertTextPart()


For the SvxTextEncodingBox::FillWithMimeAndSelectBest() a fix could be,
that when no BestMime of gsl_getSystemTextEncoding() (which actually
calls osl_getThreadTextEncoding()) could be determined,
RTL_TEXTENCODING_ISO_8859_1 could be used. An alternative could be UTF8,
technically the most appropriate but from a user's view maybe most times
not desired, at least for HTML export. She may desire the encoding
matching the UI locale instead, which for most Western languages still
results in ISO-8859-1 but also leaves room for Eastern and CJK/CTL
encodings. Only if that ominously failed too, UTF8 would be selected.

Given that almost all of the above code places deal with HTML export
(SwSrcView being the HTML source view), we might create a method to
obtain an identical "Application"MimeCharsetEncoding in all cases.

Thoughts, anyone?