mirror of
https://github.com/samba-team/samba.git
synced 2024-12-23 17:34:34 +03:00
103d248bee
It seems very likely that our clever attempts to dynamically realloc the output buffer were never triggered. Two lines of reasoning lead to this conclusion: 1. We allocate 3 * srclen to start with, but no conversion we use will more than that. To be precise, from 8-bit charsets we will only deal with codepoints in the Unicode basic multilingual plane (up to 0xFFFF). These can all be expressed as 3 or fewer utf-8 bytes. In UTF16 they are naturally 2 bytes, while in the DOS codes they are 1 byte. We have checked the code tables, and can not find a plausible (e.g. not EBCDIC) DOS code page or unix charset that is outside this range. Clients cannot chose the code page, the only code pages we will use come from 'unix charset' and 'dos charset' smb.conf parameters. Therefore the worst that can possibly happen is we expand 1 byte into 3 (specifically, when converting some e.g. CP850 codepoints to UTF-8). 2. If the reallocation was ever used, the results would have been catastrophically wrong, as the input pointer was not reset. Therefore we skip the complication of the goto loop and let E2BIG be just another impossible error to report. Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz> Reviewed-by: Andrew Bartlett <abartlet@samba.org> |
||
|---|---|---|
| .. | ||
| tests | ||
| charset_macosxfs.c | ||
| charset_proto.h | ||
| charset.h | ||
| codepoints.c | ||
| convert_string.c | ||
| iconv.c | ||
| pull_push.c | ||
| util_str.c | ||
| util_unistr_w.c | ||
| util_unistr.c | ||
| weird.c | ||
| wscript_build | ||
| wscript_configure | ||