Dear Michal,
Le 16/09/2014 19:25, Michal Trojnara a écrit :
Honestly, I don't like the idea of using format strings that are clearly documented by Microsoft as obsolete and likely to be incompatible with future versions of Windows.
Ok...but I think you are and I am "partly" wrong : the interest of %hc/%lc or %hs/%hS was that they ARE STABLE in MEANING whatever you use printf or wprintf: for example %lc always interprets and prints a supposed wide char as ...a wide char, not a couple of ansi chars.
ie : those syntax are MUCH MORE CLEAR and EXPLICIT than just using "%s" or "%S" whose meanings are CHANGING whether you compile for unicode or not.
Anyway...I checked the standard C libc and it appears that %hc and %hs are NOT ISO C99 standard compliant while %lc and %ls are... See that pdf : http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf page 405-406 and here : http://www.gnu.org/software/libc/manual/html_node/Table-of-Output-Conversion...
***** Finally, it is easy to redefine the format_specs strings I gave in my v502 patch to correct values: so just remove the "h" letter in my ansi specs...and LET the "l" letter in my unicode format specs. *****
NOTE : this is where your MINGW warnings come from : in standard C, the %h prefix is reserved to numerical types, not string/char types. I do hope that you compiled with MinGW defining some UNICODE flag, and that MINGW knows how to deal with TCHAR... because, even if I can make mistakes, I am not a newbie and carefully checked those FORMAT_STRINGS : both for ansi and unicode in all the various possible cases...so that I did not see at once what was the problem with the mingw compiler...but now I think the issue with it is around numerical misinterpretation of wchars/wstrings due to my abusive use of "%h" flag...
Provided that we know what we are doing and get some code, with appropriate #define, that unambiguously formats Wide strings/chars as wide, and ansi as such, we can choose between various solutions. I prefer to use explicit FORMAT_STRINGS than obscuring the code by doubling any printf line, taking the risk to misuse some %l flag or, worsely, to play dangerously with %s and %S, because both can be used BOTH with printf and wprintf and CHANGE (I should say : REVERT) their meaning in ANSI and UNICODE compilation context.
Whatever you take the problem, you have to have different format_specs strings for unicode or ansi strings printf.
Regards Pierre
Le 16/09/2014 19:25, Michal Trojnara a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Pierre,
Be careful not to take unicode patch "partly"
Unfortunately applying a single huge patch makes the code hard to maintain and occasionally breaks some features that are not used by the author of the patch.
because many pieces of codes are relying one on the other, sometimes indirectly (eg through sprintf).
Honestly, I don't like the idea of using format strings that are clearly documented by Microsoft as obsolete and likely to be incompatible with future versions of Windows.
When compiled with MinGW it results with the following warnings: ui_win_gui.c: In function ‘edit_config’: ui_win_gui.c:1117:17: warning: format ‘%hs’ expects argument of type ‘short int *’, but argument 2 has type ‘TCHAR *’ [-Wformat] ui_win_gui.c: In function ‘service_install’: ui_win_gui.c:1182:9: warning: format ‘%hs’ expects argument of type ‘short int *’, but argument 2 has type ‘TCHAR *’ [-Wformat] ui_win_gui.c:1182:9: warning: format ‘%hs’ expects argument of type ‘short int *’, but argument 3 has type ‘LPSTR’ [-Wformat]
It was not obvious to track all of the modifications in 502.
Quoting Linus: https://www.kernel.org/doc/Documentation/SubmittingPatches
<begin of quote>
- Separate your changes.
Separate _logical changes_ into a single patch file.
For example, if your changes include both bug fixes and performance enhancements for a single driver, separate those changes into two or more patches. If your changes include an API update, and a new driver which uses that new API, separate those into two patches.
On the other hand, if you make a single change to numerous files, group those changes into a single patch. Thus a single logical change is contained within a single patch.
If one patch depends on another patch in order for a change to be complete, that is OK. Simply note "this patch depends on patch X" in your patch description.
If you cannot condense your patch set into a smaller set of patches, then only post say 15 or so at a time and wait for review and integration.
<end of quote>
Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlQYcoIACgkQ/NU+nXTHMtF/FgCg4vB2Oxo6v2GakR+qcuPPP83K h20AoNqJ6jqWVaVAL1belyXquUySXMku =5kyk -----END PGP SIGNATURE----- _______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users