c41dffe86e
* src/rtl/fstemp.c
* hb_fsCreateTempEx(): changed to have only one return point
! hb_fsCreateTempEx(): do not call hb_fsNameConv() before
calling hb_fsCreateEx(). Latter does this since a few
commits, causing a regression here.
! low level hb_fsTempName() fixed to use HB_FSNAMECONV()
instead of HB_TCHAR_*() macros. This is slightly inappropriate
for 'prefix' parameter, but will do for now.
! low level hb_fsTempName() fixed to convert back result
to _SET_OSCODEPAGE. This fixes caller hb_fsCreateTemp()
which passes the value to hb_fsCreateEx().
! hb_fsTempDir(): fixed to convert result to _SET_OSCODEPAGE.
; NOTE: These are supposed to fix some recent and not so recent
oddities with HB_FCREATETEMP[EX]() and HB_DIRTEMP()
functions when used with non-ASCII chars, especially
on Windows. Tests done only on Windows, please review
and test, also on other platforms, non-UNICODE mode.
Regressions are possible.
Oddly, HB_FCREATETEMP() won't work well without properly
set _SET_OSCODEPAGE, probably something requiring further
fixes (and/or internal unicode support?).
; NOTE: As a loose rule of thumb, each Harbour high-level (.prg)
and low-level (.c) public APIs should expect and return
strings in _SET_CODEPAGE, while applying FSCONV transformations
on input filenames, and converting to/from _SET_OSCODEPAGE
when interfacing with OS-level FS APIs (_SET_OSCODEPAGE
should be ignored if OS-level FS APIs are capable of
handling unicode, f.e. in Windows default build mode).
Currently, low-level code uses a mixture of different
methods to achieve this, HB_TCHAR_* macros and equivalent
APIs, HB_FSNAMECONV(), hb_osDecodeCP()/hb_osEncodeCP(),
hb_fsNameConv(), Str API.
* contrib/hbmzip/mzip.c
+ Changed to use HB_FSNAMECONV() instead of HB_TCHAR_*() macros.
; review me!