[stunnel-users] stunnel beta (5.04b1) is available for testing

[Pierre DELAAGE]

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
> stunnel-users at stunnel.org
> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users