From: Richard Levitte <rich...@levitte.org>

> sms>    I'm subscribed to the list, so the extra copy isn't needed.
> 
> Plus the extra copy bounces...

   Hmmm.  I was getting two.  Anyway, ...

> However, there's a point here.  When /NOPOINTER_SIZE is used ("" was
> specified for size), are the pointers long or short by default?  I've
> always assumed they are long on Alpha and IA64, which make libraries
> built without setting /POINTER_SIZE close to 64 bit, doesn't it?  In
> that case, I think it's quite confusing that libraries built like that
> should end up being called whatever32.ext...

   We already had this discussion (Tue, 15 Feb 2011 08:03:09 -0600
(CST)) when M. Zoltan expressed the same belief.  As I quoted then:

      HELP CC /POINTER_SIZE

[...]
     Specifying /POINTER_SIZE=32 directs the compiler to assume that all
     pointers are 32-bit pointers.  But unlike the default of
     /NOPOINTER_SIZE, /POINTER_SIZE=32 enables use of the #pragma
     pointer_size long and #pragma pointer_size short preprocessor
     directives to control pointer size throughout your program.
[...]

The default on VMS has always been what it has always been, 32-bit
pointers.

> sms>    If the "=ARGV" really is needed to make the main programs work, then
> sms> we can either require a newer compiler, or, perhaps, do more/different
> sms> argv[] copying (on VMS) to provide a 64-bit argv[] when the C
> sms> environment won't.  (Which doesn't sound to me like much fun.)
> 
> I'll try something out...

   I'd guess that one could (conditionally) 1) declare the real argv[]
as 32-bit pointers, 2) construct a new argv[] made of 64-bit pointers,
3) copy the original 32-bit pointers into the new 64-bit array
(remembering to add the (big) NULL at the end), and then pass that array
along, much as is done for the new NULL-terminated array.  I'd expect
that the most annoying part would be either always doing it (annoying),
or else adding some kind of builder option (annoying) to specify when
not to use "= ARGV" in the compiler commands, and defining a macro to
tell the code that it needs to use the new work-around.  It's probably
not hard to do, just not fun.  Possibly:

$!      ""      Compile with default (/NOPOINTER_SIZE).
$!      32      Compile with /POINTER_SIZE=32 (SHORT).
$!      64      Compile with /POINTER_SIZE=64[=ARGV] (LONG[=ARGV]).
$!      64A     Compile with /POINTER_SIZE=64 (LONG).  For compilers
$!              before HP C V7.3, where "=ARGV" is not legal.  (Adds
$!              annoying work-around code to cope with the 32-bit
$!              argv[] array.)

But all the "64" consumers would need to be changed to deal with the new
"64A" option.

   SMS.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to