In message <20151222153437.192023un5jh69...@www.polarhome.com> on Tue, 22 Dec 2015 15:34:37 +0100, Zoltan Arpadffy <z...@polarhome.com> said:
zoli> Hi, zoli> zoli> > zoli> May I ask you, if the new build will cover the long names issue zoli> > ( zoli> > zoli> symhacks.h ) too? zoli> > zoli> > It's been pointed out to me by the vms-ports folks that it should be zoli> > possible to solve using the compiler's "#pragma names shortened" zoli> > rather than maintaining symhacks... Then, it's just a matter of doing zoli> > the same thing manually when producing the SYMBOL_VECTOR for a zoli> > shareable image. I'm also thinking that "#pragma names as_is" should zoli> > be norm and that we could produce upper case aliases in SYMBOL_VECTOR zoli> > (you know how that's done, right?). Does that sound like a way zoli> > forward to you? zoli> zoli> It is not my decision, but I don't like either of these approaches. zoli> zoli> The code itself needs to be written that it is as much as possible zoli> portable. In the end, this is a LINKER vs rest of the world issue. In this day and age, the 31 char limitation is a bit aged, and LINKER should really be updated to allow longer symbol names. If nothing else, C++ symbol munging would require it. I certainly hope VSI receives the messages and starts dealing with it. Either way, we're dealing with C, with case sensitive symbols and symbols longer than 31 chars. The names pragmas are helpful portability tools, the smoothest at this point is to put them to good use. zoli> It is not impossible to maintain a code base that uses up to 32 char zoli> long function names - without losing the readability of the code. zoli> I agree that it requires some extra focus from the developers side - zoli> but coding a security software needs that (and even more) focus zoli> anyway. That can certainly be argued... Again, that's more of a LINKER issue than anything else. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
