Hello Andy,
Thank you for the explanations.
Understood about alloca...as "name" is copied in "pname" later in
unicode case, it can NOT be taken on the stack with alloca.
if we were using a kind of tchar2char routine, doing malloc and memcpy
in char case, we could have simpler code...
But thanks for the explanation.
For dso_win32.c, yes you are right again : I missed the bug in the code,
at least because my first concern is mostly missing types and routines
and libs, around porting.
But I agree that len=0 init, was NOT the solution to the bug, just a
"workaround" to missing usage compilation warning.
About MultibyteToWideChar...the more you type, or paste, the more error
risk you take with some obscure flag, and the more others have to check,
for ...no real benefeat when other complicated things about cryptography
require more attention.
So, ok, let us stay like this : no need for asc_to_wide or anything like
tchar2wide and tchar2asc.
Finally, as far as I can tell, the code for e_capi.c is "logically" ok
for me, and compiles on WCE.
I will try to test it on WCE with some procedures I found on openssl
website.
problem is that I have no console on WCE to see printfs...
====
Something else : have you checked my other (very little and limited)
fixes to various other files for WCE openssl version ?
Will there be some revised explanations in INSTALL.WCE ? about various
compilers for example, evc3, evc4sp4 and vc 2005 ?
Thank you,
Yours sincerely,
Pierre
Le 20/12/2012 12:18, Andy Polyakov a écrit :
Good morning,
The piece of code Line 1119 is not clear :
len is a size in byte giving the size of the LP-T-STR name,
So, whatever is the sizeof(TCHAR), one is allowed to do : name =
(TCHAR *) malloc(len).
So it is not clear why one should use alloca when TCHAR is char, and
OPENSSL_malloc when TCHAR is wchar_t.
Because in wchar_t case you have to convert it to ASCII afterwards and
conversion takes a malloc-ation. alloca is about minimizing
malloc-ations.
Ok understood that alloca is working with the stack, so free is not
needed. I learnt something today...
BUT there may be something I do not understand : so why NOT use alloca
on BOTH CASES ?
that is to say : on line 1122 why not replace OPENSSL_malloc by alloca ?
as I said both are using the same len, expressed in bytes, parameter ?
Then we won't be able to return that pointer. Well, one certainly can
write code that does that, but there is no guarantee that the string
that we've placed there would reach the destination intact. And we don't
want that so much that we even say "we are not *able* to return that
pointer".
So I suggest to replace the code from line 1119 to line 1122 by just this :
name = alloca(len);
Am I mistaken somewhere ?
Yes. ANSI result has to be malloc-ated.
===
More generally I do NOT recommend using "sizeof(TCHAR)!=sizeof(char))"
where it is in fact expected to get a compilation directive such as
#ifdef UNICODE
It is not only confusing from an operational point of view, as if
both branches of the code could be used in the same run time session,
but also time consuming at run time...
The rationale behind using if(sizeof(TCHAR)!=sizeof(char)) in favor of
preprocessor directives is that compiler always parses both cases, so
that you don't have to explicitly test them separately. Yes, some
[otherwise redundant] casts sneak in, but the gain is that there is no
way to get one of code paths wrong. To demonstrate the point consider
one of your suggested modifications, to dso_win32.c. Is len=0 actually
proper solution? No, http://cvs.openssl.org/chngview?cn=23134 is. As
for branches. As conditions are constant, compiler eliminates the
unused code during optimization pass. At least all compilers I've
tested did that. So that it shouldn't have side effects at run time,
binary code should be as if it was #ifdef-ed.
"as if it was ifdef'd"...but with more confusion letting readers think
that both branches can run...
I do not see clearly the link with my suggestion..: when I am porting a
code, I JUST deal with compilation errors, wihout modifying, unless
discussed as we do with you, the branches and logic of the code.
But I agree that your code is making sense to solve the compilation
warning....
There was bug in the code, compilation would *fail* whenever certain
pre-processor condition was met. You was alarmed by warning, but was
still dazzled by #ifdefs and failed to see the *bug*.
Hmm, at least dont't you want that I propose to replace all those
painful MultibyteTowidechar and if sizeof(TCHAR)==sizeof(char) by JUST a
call to something like new routine asc_to_wide ?
Putting it to separate subroutine would make it impossible to use alloca.
at least the code would be more simple, clear, and consistent with what
is it already doing with wide_to_asc ?
Well, one can argue that I'm being ridiculous about talking about
sparing just few malloc-ations. But I can tell couple of stories about
true value of malloc-ation "zero" cost. I simply find it more
appropriate to be aware and [over]cautious at more occasions. It's also
kind of occupational hazard. When I look at code I see more of machine
code than high-level language. For example I don't care how long is
snippet if I can imagine how short is the machine code.
MultiByteToWideChar is very good example here. Yes, it's a lot of typing
(rather pasting), but number of compiled instructions is actually
modest. So I waste some bytes of recurring code sequence to spare
malloc-ation. Note that sparing malloc-ation is not self-purpose. For
example I don't spare malloc-ations in capi_dump_prov_info. This is
because it's on debugging path and you're less concerned about
performance when debugging. Bottom line is that lack of asc_to_wide is
not really a coincidence.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
