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-Conversions.html#Table-of-Output-Conversions
*****
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>
3) 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
[email protected]
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
_______________________________________________
stunnel-users mailing list
[email protected]
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
