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 openssl-dev@openssl.org Automated List Manager majord...@openssl.org
