Bug 39895

Created attachment 18527 [details]
Explicitly call FormatMessageA on Win32, naive transcode on WinCE

Mass reassign the 44 open apr-bugs to apr bug list

Of course, FormatMessageA is the wrong API when OS >= NT (and the unicode output
should be passed through the utf-8 filter, just as we do the filenames)...

so the patch needs a bit of massaging before it's committed, but I agree with
the spirit of your patch.

It compiles and builds fine on VS C++ 6.0, but it introduces C++ comments (//) 
on C code.

Created attachment 20120 [details]
Slight modification of previous patch

Slight modification of previous patch, removing C++ style comment and checking
for negative TCHAR values.

Created attachment 20121 [details]
Alternative minimal patch for the issue

This patch eliminates the problematic call to FormatMessage on WinCE entirely
and falls back to just output the error code.

I looked hard at trying to address Will Rowe's comments on 2006-09-20, but I
could not come up with a simple solution.  Both patches will address my original
issue (only getting the first letter of any message and possible buffer overrun
on WinCE) without changing the established behavior on other platforms.  I 'd
prefer the in-place transcode over skipping the formatted message, but either is
fine.  

The issue that apr_strerror may not return a UTF-8 encoded message is not a
WinCE specific issue and I've really tried to make no change to behavior on
other platforms in the WinCE patches.  

If there were a pool handy, it would be simple to allocate memory double the
size of the destination buffer, call FormatMessage, and then
apr_conv_ucs2_to_utf8 to transcode to UTF-8.  However,  without a memory pool,
then you are constrained by the buffer available.  Even if you were able to
write a bulletproof in-place transcoder, you would still have the side effect of
reducing the maximum message that can be placed in the buffer by half.  If this
was to be addressed (maybe if APR 2 and got a pool in scope), it should be split
off into a different bug and not hold up the WinCE specific fix.

If your concern was that a caller was expecting UTF-8 and might get a message in
the current default encoding that was not valid UTF-8, you still call
FormatMessageA but walk through the message and replace any code point >= 0x80
with '?'.  However, again that is not something WinCE specific and should be
done under a different bug.

(WinCE does not have FormatMessageA or FormatMessageW, just FormatMessage which
takes LPWSTR regardless of the state of _UNICODE or _MBCS).

Created attachment 20122 [details]
Previous mid contained spurious test changes

Created attachment 20123 [details]
Previous min contained spurious test changes

(In reply to comment #7)
> The issue that apr_strerror may not return a UTF-8 encoded message is not a
> WinCE specific issue and I've really tried to make no change to behavior on
> other platforms in the WinCE patches.  

Hold on .. why do you make that assumption?  What is the issue with returing
a UTF-8 message?  The issue is that utf8 can be reasonably rendered in an ascii
derived character set, and ONLY utf8 will represent the filename/symbol/entity
that is was substituted from the OS call with unicode args.

In any case, it won't fit, we can't rely on formatting this forwards or reverse
into utf-8 since utf-8 is variably sized smaller or longer than the original
bytestream, so my thought is that only TLS store would help us here.  Since I'm
not hacking that in today - I've deployed your 'ascii only' flavor in trunk
for the moment, which is better than nothing.

If both TLS and proper string handling is deployed, I'll be all for bumping
this back to 1.2/0.9, so note the initial patch to trunk is r543549.