[openssl-dev] [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
VMS support is back in master (openssl 1.1) -- Rich Salz, OpenSSL dev team; rs...@openssl.org - http://rt.openssl.org/Ticket/Display.html?id=2449 Please log in as guest with password guest if prompted ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Richard Levitte rich...@levitte.org sms http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0-stable-SNAP-20110323_s1.zip Applied to the same three branches. Will show in tomorrow's snapshots. I sucked down an openssl-1_0_0-stable-SNAP-20110329 kit, and looked at the differences between it and what I had. Thanks for fixing the minor (indentation) and major (#include placement) problems. (Sometimes I actually try this stuff on a non-VMS system, but not always.) I'll run it through the usual grind, but what could go wrong now? Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
In message 11032216192727_20200...@antinode.info on Tue, 22 Mar 2011 16:19:27 -0500 (CDT), Steven M. Schweda s...@antinode.info said: sms http://antinode.info/ftp/openssl/1_0_0d/openssl-SNAP-20110321_s1.zip Changes applied, on the main development branch as well as 1.0.1-stable and 1.0.0-stable. Tomorrow's snapshots will hold the changes. -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
In message 11032315292753_20200...@antinode.info on Wed, 23 Mar 2011 15:29:27 -0500 (CDT), Steven M. Schweda s...@antinode.info said: sms From: Richard Levitte rich...@levitte.org sms sms sms http://antinode.info/ftp/openssl/1_0_0d/openssl-SNAP-20110321_s1.zip sms sms Just to clarify, you used openssl-SNAP-20110321.tar.gz for this? sms That's a different branch than the one 1.0.0d comes from... sms sms Yes. (Or openssl-SNAP-20110321^.tar.gz;1, as it's known around here.) sms [...] sms If you worked on 1.0.0d before and now played with HEAD, it must be sms confusing. There are some differences... sms sms The relevant stuff all looked familiar enough. sms smsThere does seem to be (at least) one significant difference, though, sms on a 32-bit (VAX) system: sms [...] smsThis stuff was not in 1.0.0d. Is this the kind of optional-feature sms module which can be omitted from the build on VAX, or is long sms long-free code available, or are we doomed now (on VAX)? We're not doomed before it's released, and as far as I'm concerned, we haven't rejected support for VAX (I've been sloppy for a time, but that's a different matter entirely). You have to see the development branch (HEAD) as relatively unstable, since that's where new features are added. on the release branches (where 1.0.0d resides, for example), things like this should not happen. Regarding VMS, well, it's not the main development platform (Unix is), so there will sometimes be things suddenly breaking in HEAD. It's up to us who use VMS to test and report problems or contribute changes. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Richard Levitte rich...@levitte.org Changes applied, on the main development branch as well as 1.0.1-stable and 1.0.0-stable. Tomorrow's snapshots will hold the changes. Ooh. Just moments too soon. I went through the exercise again on an openssl-1_0_0-stable-SNAP-20110323 kit, probably being a little more careful. Originals and changes should be available at: http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0-stable-SNAP-20110323_s1.zip (I would have gotten back sooner, but the VAX is sooo slw) Other than the (mostly esthetic) changes to the builders, there are functional changes to apps/CA.com (first suggested last December, as I recall) to avoid a DCL problem on VAX (possibly on old Alpha, too?): [...] --- TEST_CA Generate and certify a test certificate via the 'ca' program Making CA certificate ... %DCL-W-TKNOVF, command element is too long - shorten \SYS$DISK:[-.VAX.EXE.APPS]OPENSSL REQ -CONFIG CAss.cnf -NEW -X509 -KEYOUT GIMP$DUA0:[UTILITY.SOURCE.OPENSSL.OPENSSL-1_0_0-STABLE-SNAP-20110323.TEST.DEMOCA.PRIVATE]CAKEY.PEM -OUT GIMP$DUA0:[UTILITY.SOURCE.OPENSSL.OPENSSL-1_0_0-STABLE-SNAP-20110323.TEST. %DCL-W-TKNOVF, command element is too long - shorten Generating a 512 bit RSA private key [...] It happens because the old CA.com puts the full directory spec on the command line so many times. I forgot about it, because it happens to me only in stable snapshots, because those directory names are so much longer, but it could strike a real victim with a real released version, too. The new CA.com uses a (much shorter) logical name, and seems to work well everywhere: GIMP $ copy it$dkc0:[.apps]CA.com [.apps] GIMP $ @ [.test]tests.com test_ca @@@ TESTS.COM --- TEST_CA Generate and certify a test certificate via the 'ca' program Making CA certificate ... Generating a 512 bit RSA private key [...] I may be running out of complaints. Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
In message 11032507012111_20200...@antinode.info on Fri, 25 Mar 2011 07:01:21 -0500 (CDT), Steven M. Schweda s...@antinode.info said: smsOoh. Just moments too soon. I went through the exercise again on an sms openssl-1_0_0-stable-SNAP-20110323 kit, probably being a little more sms careful. Originals and changes should be available at: sms sms http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0-stable-SNAP-20110323_s1.zip Applied to the same three branches. Will show in tomorrow's snapshots. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Richard Levitte rich...@levitte.org sms http://antinode.info/ftp/openssl/1_0_0d/openssl-SNAP-20110321_s1.zip Just to clarify, you used openssl-SNAP-20110321.tar.gz for this? That's a different branch than the one 1.0.0d comes from... Yes. (Or openssl-SNAP-20110321^.tar.gz;1, as it's known around here.) [...] If you worked on 1.0.0d before and now played with HEAD, it must be confusing. There are some differences... The relevant stuff all looked familiar enough. There does seem to be (at least) one significant difference, though, on a 32-bit (VAX) system: GIMP $ cc /version Compaq C V6.4-005 on OpenVMS VAX V7.3 [...] e_aes.c typedef long long i64; ^ %CC-E-NOLONGLONG, In this declaration, 64-bit integral types are not supported on this platform. At line number 20 in GIMP$DUA0:[UTILITY.SOURCE.OPENSSL.OPENSSL-S NAP-20110321.CRYPTO.MODES]MODES_LCL.H;1. typedef unsigned long long u64; ^ %CC-E-NOLONGLONG, In this declaration, 64-bit integral types are not supported on this platform. At line number 21 in GIMP$DUA0:[UTILITY.SOURCE.OPENSSL.OPENSSL-S NAP-20110321.CRYPTO.MODES]MODES_LCL.H;1. GCM128_CONTEXT gcm; ...^ %CC-E-INCOMPMEM, The member gcm has an incomplete type. At line number 199 in GIMP$DUA0:[UTILITY.SOURCE.OPENSSL.OPENSSL- SNAP-20110321.CRYPTO.EVP]E_AES.C;1. #endif %VCG-I-NOBJECT, No object file produced. At line number 462 in GIMP$DUA0:[UTILITY.SOURCE.OPENSSL.OPENSSL- SNAP-20110321.CRYPTO.EVP]E_AES.C;1. %VCG-I-SUMMARY, Completed with 3 error(s), 0 warning(s), and 1 informational messages. [You have to admire the (s) in two out of three places, but not the one where it was wanted. I'll bet that they don't fix it.] At line number 462 in GIMP$DUA0:[UTILITY.SOURCE.OPENSSL.OPENSSL- SNAP-20110321.CRYPTO.EVP]E_AES.C;1. [...] Followed by the kinds of unpleasant consequences which one might expect after that. At first, I thought that this might be all my fault, because I had disabled some /WARNING = DISABLE stuff, which included LONGLONGTYPE and LONGLONGSUFX, but NOLONGLONG is a different thing, and not so easy to ignore: GIMP $ cc ll.c /warn = disable = NOLONGLONG %CC-I-CANTDISABLE, The message id nolonglong cannot be disabled. (I was just making sure that ignoring it would be a big mistake, but the compiler won't permit that big mistake to be made.) This stuff was not in 1.0.0d. Is this the kind of optional-feature module which can be omitted from the build on VAX, or is long long-free code available, or are we doomed now (on VAX)? Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
64 Automatic choice of 64 or 64=ARGV. 64=ARGVManual choice of 64=ARGV. 64=Manual choice of plain 64. Seems to be done, and the compiler test activity no longer leaves junk object and/or listing files lying around. Original (*.*_orig) and changed files (with VMS version numbers) should be available here: http://antinode.info/ftp/openssl/1_0_0d/openssl-SNAP-20110321_s1.zip Changes other than to the than the VMS builders: crypto/evp/evp_enc.c The fix here (previously discussed on this list) should already be in the normal code. apps/openssl.c Reformed argv[] duplication code. (Looks at VMS_TRUST_ARGV only for 64-bit argv[]. A 32-bit argv[] with 64-bit other-pointers must always be duplicated, no matter how trusting the victim may be.) ssl/dtls1.h Someone keeps adding stuff like: /* Unless _XOPEN_SOURCE_EXTENDED is defined, struct timeval will not be properly defined with DEC C, at least on VMS */ #if defined(__DECC) || defined(__DECCXX) #define _XOPEN_SOURCE_EXTENDED #endif I keep getting compiler complaints because of it: [...] Building The SSLTEST Test Program. #define _XOPEN_SOURCE_EXTENDED 1 /* Or gethostname won't be declared properly ^ %CC-W-MACROREDEF, The redefinition of the macro _XOPEN_SOURCE_EXTENDED conflicts with a current definition because the replacement lists differ. The redefinition is now in effect. at line number 189 in file IT$DKC0:[UTILITY.SOURCE.OPENSSL.openssl-SNAP-20110321.ssl]ssltest.c;1 [...] So I keep taking it out. I need more info than DEC C, at least on VMS to understand what the problem is, wherever it is, if there actually is one. I don't see it around here, where the cure always seems to be worse than the disease. util/libeay.num As usual, these guys were mismatched with util/ssleay.num reality, especially where VMS uses shortened names (crypto/symhacks.h). (And we ain't got no 128-bit integers, so EC_GFp_nistp224_method had to be tossed out.) I added a helpful comment section at the end of each file, and enhanced VMS/mkshared.com to include the concept of a comment, so that it could ignore these new comments. If these .num files are actually created automatically, then these changes may make little sense. Similarly, if there's some other consumer who reads these files, then he needs to ignore the comments, too. (Or else, the comments need to be removed, but if these files are being hand-edited (carelessly), then it's just possible that some comments might save us from some of these recurring shortened-name problems. I've tested these VMS builders with every pointer-size option (, 32, 64, 64=, and 64=ARGV), and the results look good on Alpha and IA64, except for one harmless quirk for which I blame HP. As I read the docs, an explicit /POINTER_SIZE=32 option should be equivalent to the default, /NOPOINTER_SIZE, but stuff in stdlib.h causes some (spurious, I claim) info messages, like: [...] Compiling The mem.c File. (LIBRARY,LIB) static void *(*realloc_func)(void *, size_t)= realloc; ..^ %CC-I-FUNCMIXPTR, In the initializer for realloc_func, function types differ because this declaration specifies short pointer and a previous declaration specifies long pointer. at line number 83 in file IT$DKC0:[UTILITY.SOURCE.OPENSSL.openssl-SNAP-20110321.crypto]mem.c;1 static void (*free_func)(void *)= free; ..^ %CC-I-FUNCMIXPTR, In the initializer for free_func, function types differ because this declaration specifies short pointer and a previous declaration specifies long pointer. at line number 90 in file IT$DKC0:[UTILITY.SOURCE.OPENSSL.openssl-SNAP-20110321.crypto]mem.c;1 [...] More compiler bug info: http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1474331 The complaints are only informational (-I-), so the build procedure is unaffected, and the stuff works, so they don't seem to matter much, and any sane victim will say instead of 32, so the whole annoyance should never be noticed, but you heard it here first. It's supposed to snow here, so I'll fire up the VAX, and verify that all is still well there. (What could go wrong? If the power stays up for a couple of days, that is.) SMS. __ OpenSSL Project http://www.openssl.org Development
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
In message 11032017084365_20200...@antinode.info on Sun, 20 Mar 2011 17:08:43 -0500 (CDT), Steven M. Schweda s...@antinode.info said: sms From: Richard Levitte rich...@levitte.org sms sms [...] tomorrow's snapshot [...] sms smsEvery time I look at the snapshot Web page, I get confused. README sms doesn't describe the -VMS_64BIT- or -WIN64- things, for example. Which sms tomorrow's snapshot would be the right one? (And which tomorrow?) I mean to comment on this... I've just removed the -VMS_64BIT- and -WIN64- snapshots. They were branch snapshots that haven't been touched for ages. The rest are described in README, as far as I can see. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
In message 11032216192727_20200...@antinode.info on Tue, 22 Mar 2011 16:19:27 -0500 (CDT), Steven M. Schweda s...@antinode.info said: sms64 Automatic choice of 64 or 64=ARGV. sms64=ARGVManual choice of 64=ARGV. sms64=Manual choice of plain 64. sms smsSeems to be done, and the compiler test activity no longer leaves sms junk object and/or listing files lying around. Original (*.*_orig) and sms changed files (with VMS version numbers) should be available here: sms sms http://antinode.info/ftp/openssl/1_0_0d/openssl-SNAP-20110321_s1.zip Just to clarify, you used openssl-SNAP-20110321.tar.gz for this? That's a different branch than the one 1.0.0d comes from... The way it's set up, we currently maintain the following branches: - OpenSSL_0_9_8-stable, which is version 0.9.8x (x = any letter), resulting in snapshot openssl-0.9.8-stable-SNAP-date.tar.gz - OpenSSL_1_0_0-stable, which is version 1.0.0x (x = any letter), resulting in snapshot openssl-1.0.0-stable-SNAP-date.tar.gz - OpenSSL_1_0_1-stable, which is version 1.0.1x (x = any letter), resulting in snapshot openssl-1.0.1-stable-SNAP-date.tar.gz - HEAD, which is version 1.1.0-dev, resulting in snapshot openssl-SNAP-date.tar.gz If you worked on 1.0.0d before and now played with HEAD, it must be confusing. There are some differences... sms ssl/dtls1.h Someone keeps adding stuff like: sms sms /* Unless _XOPEN_SOURCE_EXTENDED is defined, struct timeval will not be smsproperly defined with DEC C, at least on VMS */ sms #if defined(__DECC) || defined(__DECCXX) sms #define _XOPEN_SOURCE_EXTENDED sms #endif sms sms I keep getting compiler complaints because of it: sms sms [...] sms Building The SSLTEST Test Program. sms sms #define _XOPEN_SOURCE_EXTENDED 1 /* Or gethostname won't be declared properly sms ^ sms %CC-W-MACROREDEF, The redefinition of the macro _XOPEN_SOURCE_EXTENDED sms conflicts with a current definition because the replacement lists sms differ. The redefinition is now in effect. sms at line number 189 in file sms IT$DKC0:[UTILITY.SOURCE.OPENSSL.openssl-SNAP-20110321.ssl]ssltest.c;1 sms [...] sms sms So I keep taking it out. I need more info than DEC C, at least sms on VMS to understand what the problem is, wherever it is, if sms there actually is one. I don't see it around here, where the sms cure always seems to be worse than the disease. I've seen the compiler complain that struct timeval isn't defined. sms util/libeay.num As usual, these guys were mismatched with sms util/ssleay.num reality, especially where VMS uses shortened smsnames (crypto/symhacks.h). (And we ain't got smsno 128-bit integers, so EC_GFp_nistp224_method smshad to be tossed out.) I added a helpful comment smssection at the end of each file, and enhanced smsVMS/mkshared.com to include the concept of a smscomment, so that it could ignore these new smscomments. If these .num files are actually smscreated automatically, then these changes may smsmake little sense. Similarly, if there's some smsother consumer who reads these files, then he smsneeds to ignore the comments, too. (Or else, the smscomments need to be removed, but if these files smsare being hand-edited (carelessly), then it's smsjust possible that some comments might save us smsfrom some of these recurring shortened-name smsproblems. The proper way to handle this is with make update on Unix. I need to remember to use mkshared.com to see the problem, thanks for the reminder. I'll have a look at your zip. -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Richard Levitte rich...@levitte.org sms http://antinode.info/ftp/openssl/1_0_0d/openssl-SNAP-20110321_s1.zip Just to clarify, you used openssl-SNAP-20110321.tar.gz for this? That's a different branch than the one 1.0.0d comes from... Yes. (Or openssl-SNAP-20110321^.tar.gz;1, as it's known around here.) The way it's set up, we currently maintain the following branches: [...] Thanks for the more detailed explanation. If the README had said all that, then I might have chosen a different kit. If you worked on 1.0.0d before and now played with HEAD, it must be confusing. There are some differences... The relevant stuff all looked familiar enough. sms [...] sms So I keep taking it out. I need more info than DEC C, at least sms on VMS to understand what the problem is, wherever it is, if sms [...] I've seen the compiler complain that struct timeval isn't defined. As I said, 'I need more info than DEC C, at least on VMS to understand what the problem is [...]'. That's still true. I've seen is not much of an improvement. For me, it _always_ works better without this stuff. Perhaps /STANDARD = RELAXED made some difference, too. If you look closely at the current builders, you may find that I've emptied all (almost all?) of the COMPILEWITH_CCx module lists which were related to warning suppression. Around here, I get pretty clean builds -- the usual two %CC-I-QUESTCOMPARE (plus the newly discovered %CC-I-FUNCMIXPTR for an explicit /POINTER_SIZE=32) are all the complaints I get. (Plus a bunch more VAX-only old-compiler infos which can also be ignored.) Clean, that is, except when I get the extra help. SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
In message 11031918194299_20200...@antinode.info on Sat, 19 Mar 2011 18:19:43 -0500 (CDT), Steven M. Schweda s...@antinode.info said: sms I'll try something out... sms smsI'd guess that one could (conditionally) 1) declare the real argv[] sms as 32-bit pointers, 2) construct a new argv[] made of 64-bit pointers, sms 3) copy the original 32-bit pointers into the new 64-bit array sms (remembering to add the (big) NULL at the end), and then pass that array sms along, much as is done for the new NULL-terminated array. No need to declare the real argv anything more than it is right now. I've moved your code to main() and added a bit of code so that the argv copying is also done when sizeof(Argv) __INITIAL_POINTER_SIZE/8 That was easy enough. I did a little bit of renaming so the rest of main() would accept this new variable. sms I'd expect that the most annoying part would be either always doing it sms (annoying), or else adding some kind of builder option (annoying) to sms specify when not to use = ARGV in the compiler commands, and defining sms a macro to tell the code that it needs to use the new work-around. It's sms probably not hard to do, just not fun. Possibly: sms sms $!Compile with default (/NOPOINTER_SIZE). sms $! 32 Compile with /POINTER_SIZE=32 (SHORT). sms $! 64 Compile with /POINTER_SIZE=64[=ARGV] (LONG[=ARGV]). sms $! 64A Compile with /POINTER_SIZE=64 (LONG). For compilers sms $! before HP C V7.3, where =ARGV is not legal. (Adds sms $! annoying work-around code to cope with the 32-bit sms $! argv[] array.) sms sms But all the 64 consumers would need to be changed to deal with the new sms 64A option. Naah... this is only needed in makeapps.com, as far as I can tell, and it wouldn't be too hard to have a spot in the code simply try the following command: CC /POINTER_SIZE=64=ARGV NL: and see if that gives back a condition code from DCL (facility number 3) or the compiler (facility number something different ;-)). It's really just one or the other and is pretty easy to do. Getting to it. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Richard Levitte rich...@levitte.org sms But all the 64 consumers would need to be changed to deal with the new sms 64A option. Or an explicit 64 or 64=ARGV... Naah... this is only needed in makeapps.com, as far as I can tell, and it wouldn't be too hard to have a spot in the code simply try the following command: CC /POINTER_SIZE=64=ARGV NL: and see if that gives back a condition code from DCL (facility number 3) or the compiler (facility number something different ;-)). It's really just one or the other and is pretty easy to do. It depends on whether you want the user to be able to specify it or have it selected automatically. I lean toward letting the user decide, but anything which works is probably good enough. [.test]maketests.com, too? CC /NOLIST /NOOBJECT [...] SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
In message 11032008135776_20200...@antinode.info on Sun, 20 Mar 2011 08:13:57 -0500 (CDT), Steven M. Schweda s...@antinode.info said: sms From: Richard Levitte rich...@levitte.org sms sms Naah... this is only needed in makeapps.com, as far as I can tell, sms and it wouldn't be too hard to have a spot in the code simply try the sms following command: sms sms CC /POINTER_SIZE=64=ARGV NL: sms sms and see if that gives back a condition code from DCL (facility number sms 3) or the compiler (facility number something different ;-)). It's sms really just one or the other and is pretty easy to do. sms smsIt depends on whether you want the user to be able to specify it or sms have it selected automatically. I lean toward letting the user decide, sms but anything which works is probably good enough. (we're still talking about the case when the user explicitely asks for 64 bit pointers, saying 64 to the build scripts, right?) Hmm, previously, we had a hard case with 64=ARGV when the user gave 64, no choice there... Now, the build script adapts to what's possible (just 64 or 64=ARGV), and so does openssl.c. I'd say that should be pretty good as a default, so as far as I see, the choice the user has is to turn off 64=ARGV on systems where it's available... or would you rather have 64 (without =ARGV) the default when the user says 64 to the build scripts? sms [.test]maketests.com, too? Ah, true, forgot about that one. Done. -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Richard Levitte rich...@levitte.org (we're still talking about the case when the user explicitely asks for 64 bit pointers, saying 64 to the build scripts, right?) Right. Hmm, previously, we had a hard case with 64=ARGV when the user gave 64, no choice there... Now, the build script adapts to what's possible (just 64 or 64=ARGV), and so does openssl.c. I'd say that should be pretty good as a default, so as far as I see, the choice the user has is to turn off 64=ARGV on systems where it's available... or would you rather have 64 (without =ARGV) the default when the user says 64 to the build scripts? Having a fully automatic script means that, with my new compiler, I can't (conveniently) test the plain 64 case. My (fully manual) plan was to make the user specify, say, 64 or 64=ARGV, and act accoringly (which would let me do whatever I want). Perhaps better would be a three-choice scheme: 64 Automatic choice of 64 or 64=ARGV. 64=ARGVManual choice of 64=ARGV. 64=NOARGV Manual choice of plain 64. Easy for the normal victim, flexible enough for the perpetrator. Not very hard to implement. SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
In message 11032010253821_20200...@antinode.info on Sun, 20 Mar 2011 10:25:38 -0500 (CDT), Steven M. Schweda s...@antinode.info said: sms Perhaps better would be a three-choice scheme: sms sms 64 Automatic choice of 64 or 64=ARGV. sms 64=ARGVManual choice of 64=ARGV. sms 64=NOARGV Manual choice of plain 64. sms sms Easy for the normal victim, flexible enough for the perpetrator. Not sms very hard to implement. I like that idea. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
In message 20110320.185103.256442123.rich...@levitte.org on Sun, 20 Mar 2011 18:51:03 +0100 (CET), Richard Levitte rich...@levitte.org said: richard In message 11032010253821_20200...@antinode.info on Sun, 20 Mar 2011 10:25:38 -0500 (CDT), Steven M. Schweda s...@antinode.info said: richard richard sms Perhaps better would be a three-choice scheme: richard sms richard sms 64 Automatic choice of 64 or 64=ARGV. richard sms 64=ARGVManual choice of 64=ARGV. richard sms 64=NOARGV Manual choice of plain 64. richard sms richard sms Easy for the normal victim, flexible enough for the perpetrator. Not richard sms very hard to implement. richard richard I like that idea. While I do, I'm exhausted. As it stands now, there's just the 64 option to choose for 64 bits. It will do exactly what you mention above, and it seems to work well together with that changes I made in apps/openssl.c. Have a look at tomorrow's snapshot, please, and see how it works on your system. Let's do the rest, like the extra fancy 64-bit options another day. (or, well, nothing stops you, of course ;-)) Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Richard Levitte rich...@levitte.org richard sms 64 Automatic choice of 64 or 64=ARGV. richard sms 64=ARGVManual choice of 64=ARGV. richard sms 64=NOARGV Manual choice of plain 64. richard sms richard sms Easy for the normal victim, flexible enough for the perpetrator. Not richard sms very hard to implement. richard richard I like that idea. While I do, I'm exhausted. As it stands now, there's just the 64 option to choose for 64 bits. It will do exactly what you mention above, and it seems to work well together with that changes I made in apps/openssl.c. Have a look at tomorrow's snapshot, please, and see how it works on your system. Let's do the rest, like the extra fancy 64-bit options another day. (or, well, nothing stops you, of course ;-)) Sounds good to me. Perhaps a little different: 64 Automatic choice of 64 or 64=ARGV. 64=ARGVManual choice of 64=ARGV. 64=Manual choice of plain 64. Why invent a new, nonstandard keyword?, I always say. (If I said that it would be easy to add, then I don't have a good excuse not to add it.) [...] tomorrow's snapshot [...] Every time I look at the snapshot Web page, I get confused. README doesn't describe the -VMS_64BIT- or -WIN64- things, for example. Which tomorrow's snapshot would be the right one? (And which tomorrow?) SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
In message 11031820281928_20200...@antinode.info on Fri, 18 Mar 2011 20:28:19 -0500 (CDT), Steven M. Schweda s...@antinode.info said: smsMore VMS builder mysteries... sms smsIn makevms.com, I see: sms sms $! P6, if defined, sets a compiler thread NOT needed on OpenVMS 7.1 (and up). sms sms I find this about as clear as mud. Can anyone explain what sets a sms compiler thread means? What, exactly, is NOT needed on OpenVMS 7.1 sms (and up)? A compiler thread? P6? As I see it, if this P6 is _not_ sms defined, then all the subsidiary builders add the C macro PTHREAD_USE_D4 sms to the compiler commands (if the VMS version is V7.1 or higher). But if sms this P6 _is_ defined, then exactly the same thing happens (for slightly sms different reasons). What's really supposed to happen when? What would sms a user specify for this P6 (and why, and when)? Oh, you're talking about history. I just dug through the log, 'cause this is oold, we're talking about something that came with a complete replacement of makevms.com and friends, back in the first half of 1999. Really, I can't remember, and I can't remember the last time I used that parameter... I think I recall, from somewhere in the deep moldy cellars of my memory, is that back when the D4 implementation was introduced on VMS, there was talking of incompatibilities that could affect programs in a bad way. Just the fact that you had to actively enable it left people wondering. As I recall it, I went with it as a default on VMS version where it was known to work (7.1 and up), but gave people the option to use the older implementation if they preferred that. Hence, this parameter. smsCan this stuff actually be built on VMS before V7.1? It's been a long time since I last heard from anyone having a really old system. However, for a very long time (up until 2000 or 2001 at the very least), VMS 5.5 for VAX was the default oldest VMS version developpers supported. OpenSSL did it with flying colors, as I recall it. smsIf PTHREAD_USE_D4 were _always_ defined, then would it have any sms effect on VMS versions before V7.1? Is all this P6 stuff just a sms (confusing) waste of time and effort? I seem to recall it was dicy on pre-7.1. If my memory isn't totally off, it was present but not well supported on some pre-7.1 systems. smstest/maketests.com says: sms sms $! Should we add MTTEST,PQ_TEST,LH_TEST,DIVTEST,TABTEST as well? sms sms where crypto/threads/mttest.c and crypto/threads/th-lock.c seem to sms be the only consumers of pthread.h. Seems to me to be a reasonable sms question. What's the answer? Currently, there exists a sms crypto/threads]pthreads-vms.com (To compile mttest on VMS), which sms seems to be ignored by the other builders. Should test/maketests.com sms be building these programs? (Should we have tests which use them?) The build scripts are made to follow the Unix build as closely as possible in practice. Those test programs aren't used by default on Unix, so they haven't been introduced here either. Mind, they aren't really tests of OpenSSL functionality per se, I believe they are more the kind of test program that's lying around just in case you stumble on a problematic system. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Hey, about your latest changes, it seems that it has SSL_LIBCRYPTO32.OLB and SSL_LIBSSL32.OLB as default names (when have specified for the bits parameter)... is that your intention? I find it a bit confusing, I'd rather expect something like this: bits= = SSL_LIBCRYPTO.OLB, SSL_LIBSSL.OLB bits=32 = SSL_LIBCRYPTO32.OLB, SSL_LIBSSL32.OLB bits=64 = SSL_LIBCRYPTO64.OLB, SSL_LIBSSL64.OLB Also, it seems that /POINTER_SIZE=64=ARGV isn't supported with HP C 7.1. I get this when trying to build the test programs with your latest scripts, once for each file: %DCL-W-NOVALU, value not allowed - remove value specification \64=\ And indeed, I can't find that in the help file either... $ cc/ver HP C V7.1-015 on OpenVMS Alpha V8.3 -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Richard Levitte rich...@levitte.org To: openssl-dev@openssl.org, sms@antinode-info R: I'm subscribed to the list, so the extra copy isn't needed. about your latest changes, it seems that it has SSL_LIBCRYPTO32.OLB and SSL_LIBSSL32.OLB as default names (when have specified for the bits parameter)... is that your intention? I find it a bit confusing, I'd rather expect something like this: bits= = SSL_LIBCRYPTO.OLB, SSL_LIBSSL.OLB bits=32 = SSL_LIBCRYPTO32.OLB, SSL_LIBSSL32.OLB bits=64 = SSL_LIBCRYPTO64.OLB, SSL_LIBSSL64.OLB So far as I know, there is no difference between the results you get from specifying and those you get from specifying 32, so I didn't try to name then differently. I believe that the default, /NOPOINTER_SIZE, and an explict /POINTER_SIZE=32 differ only in that /POINTER_SIZE=32 enables the use of features like #pragma pointer_size, and we use these (even indirectly) only in the 64-bit-pointer case. On my VAX (V7.3) system, where there is no /[NO]POINTER_SIZE option, HP uses the 32 names for the shared images: Directory SYS$COMMON:[SYSLIB] SSL$LIBCRYPTO_SHR32.EXE;1 1653 1-APR-2004 11:05:45.08 (RWED,RWED,RE,RE) SSL$LIBSSL_SHR32.EXE;1 381 1-APR-2004 11:06:00.95 (RWED,RWED,RE,RE) On my non-VAX systems (Alpha V8.3 shown here), I see: Directory SYS$COMMON:[SYSLIB] SSL$LIBCRYPTO_SHR.EXE;1 3139 9-JUN-2006 09:49:15.55 (RWED,RWED,RE,RE) SSL$LIBCRYPTO_SHR32.EXE;1 3055 9-JUN-2006 09:49:58.37 (RWED,RWED,RE,RE) SSL$LIBSSL_SHR.EXE;1 492 9-JUN-2006 09:49:15.55 (RWED,RWED,RE,RE) SSL$LIBSSL_SHR32.EXE;1 483 9-JUN-2006 09:49:58.82 (RWED,RWED,RE,RE) So, my plan was to follow this scheme, and have a 32 at the end of all the 32-bit-pointer (.EXE and .OLB) names, and nothing in the 64-bit-pointer names. But I'm open to a good argument for any other reasonable scheme. (At least, with the SSL_ prefixes, we can distinguish the new (no 32) 64-bit stuff from the old (no 32) 32-bit stuff. Everything's complicated.) Also, it seems that /POINTER_SIZE=64=ARGV isn't supported with HP C 7.1. I get this when trying to build the test programs with your latest scripts, once for each file: %DCL-W-NOVALU, value not allowed - remove value specification \64=\ And indeed, I can't find that in the help file either... $ cc/ver HP C V7.1-015 on OpenVMS Alpha V8.3 That's depressing. My first impulse is to say that 64-bit pointers require a newer compiler. It's possible that the =ARGV isn't really needed, but I thought that that was the cure for the ACCVIO in the subject line of this thread. I'll go back and check, but I believe that without the =ARGV, the libraries and shared images may be ok, but all the main programs (openssl itself, and some/all of the tests?) will explode when they start passing 32-bit argv[] pointers around to consumers who expect 64-bit pointers. (HP supplies only one OPENSSL.EXE, and I'd bet that it's a 32-bit-pointer edition.) If the =ARGV really is needed to make the main programs work, then we can either require a newer compiler, or, perhaps, do more/different argv[] copying (on VMS) to provide a 64-bit argv[] when the C environment won't. (Which doesn't sound to me like much fun.) On a related topic, for those who haven't followed it, the ITRC discussion of the bad-argv[]-termination problem seems to have come to rest: http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1472203 The conclusion seems to be that the problem originally affected both Alpha and IA64, and that there was an ECO to fix the problem on IA64 (June 2010, which I seem to have installed on my IA64 systems), but none (yet) for Alpha. (Not enough complaints from paying Alpha customers, I assume.) The existing work-around in apps/openssl.c is conditional only on OPENSSL_SYS_VMS, so we should be safe everywhere. (And it wastes only a very little time when it's not needed.) SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Also, it seems that /POINTER_SIZE=64=ARGV isn't supported with HP C 7.1. [...] I can believe that. SYS$HELP:CC073.RELEASE_NOTES puts it under 5.2 Enhancements in V7.1, but SYS$HELP:CC071.RELEASE_NOTES doesn't mention it. Trust no one, I always say. That's depressing. My first impulse is to say that 64-bit pointers require a newer compiler. It's possible that the =ARGV isn't really needed, but I thought that that was the cure for the ACCVIO in the subject line of this thread. I'll go back and check, but I believe that without the =ARGV, the libraries and shared images may be ok, but all the main programs (openssl itself, and some/all of the tests?) will explode when they start passing 32-bit argv[] pointers around to consumers who expect 64-bit pointers. [...] Yup. With /POINTER_SIZE = 64, but without the = ARGV: [...] Compiling The OPENSSL.C File. ret=fp-func(Argc,Argv); ..^ %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value Argv is short pointer to char, which is not compatible with long pointer to char. at line number 302 in file IT$DKC0:[UTILITY.SOURCE.OPENSSL.openssl-1_0_0d.apps]openssl.c;6 ret=do_cmd(prog,Argc,Argv); .^ %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value Argv is short pointer to char, which is not compatible with long pointer to char. at line number 312 in file IT$DKC0:[UTILITY.SOURCE.OPENSSL.openssl-1_0_0d.apps]openssl.c;6 [...] And: [...] --- TEST_ENC cat %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0078DD540078DD50, PC=00271540, PS=001B Improperly handled condition, image exit forced. Signal arguments: Number = 0005 Name = 000C [Blah, blah, blah, ... (These dumps are very noisy on IA64.)] The 64-bit-pointer stuff wasn't my idea, and I have V7.3-xxx C compilers on my systems, so it'd be ok with me to leave things as-are, and demand a compiler which supports /POINTER_SIZE = 64 = ARGV, if the victim wants 64-bit pointers. But if someone thinks that it's worth the effort, I could try to find an easy way to make everything work with a pre-April-2007 compiler. SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
In message 11031907290331_20200...@antinode.info on Sat, 19 Mar 2011 07:29:03 -0500 (CDT), Steven M. Schweda s...@antinode.info said: sms From: Richard Levitte rich...@levitte.org sms To:openssl-dev@openssl.org, sms@antinode-info sms smsR: sms smsI'm subscribed to the list, so the extra copy isn't needed. Plus the extra copy bounces... sms about your latest changes, it seems that it has SSL_LIBCRYPTO32.OLB sms and SSL_LIBSSL32.OLB as default names (when have specified for the sms bits parameter)... is that your intention? I find it a bit sms confusing, I'd rather expect something like this: sms sms smsSo far as I know, there is no difference between the results you get sms from specifying and those you get from specifying 32, so I didn't sms try to name then differently. I believe that the default, sms /NOPOINTER_SIZE, and an explict /POINTER_SIZE=32 differ only in that sms /POINTER_SIZE=32 enables the use of features like #pragma sms pointer_size, and we use these (even indirectly) only in the sms 64-bit-pointer case. On my VAX (V7.3) system, where there is no sms /[NO]POINTER_SIZE option, HP uses the 32 names for the shared images: sms sms Directory SYS$COMMON:[SYSLIB] sms sms SSL$LIBCRYPTO_SHR32.EXE;1 sms 1653 1-APR-2004 11:05:45.08 (RWED,RWED,RE,RE) sms SSL$LIBSSL_SHR32.EXE;1 sms 381 1-APR-2004 11:06:00.95 (RWED,RWED,RE,RE) sms sms On my non-VAX systems (Alpha V8.3 shown here), I see: sms sms Directory SYS$COMMON:[SYSLIB] sms sms SSL$LIBCRYPTO_SHR.EXE;1 sms 3139 9-JUN-2006 09:49:15.55 (RWED,RWED,RE,RE) sms SSL$LIBCRYPTO_SHR32.EXE;1 sms 3055 9-JUN-2006 09:49:58.37 (RWED,RWED,RE,RE) sms SSL$LIBSSL_SHR.EXE;1 sms 492 9-JUN-2006 09:49:15.55 (RWED,RWED,RE,RE) sms SSL$LIBSSL_SHR32.EXE;1 sms 483 9-JUN-2006 09:49:58.82 (RWED,RWED,RE,RE) sms sms So, my plan was to follow this scheme, and have a 32 at the end of all sms the 32-bit-pointer (.EXE and .OLB) names, and nothing in the sms 64-bit-pointer names. But I'm open to a good argument for any other sms reasonable scheme. (At least, with the SSL_ prefixes, we can sms distinguish the new (no 32) 64-bit stuff from the old (no 32) 32-bit sms stuff. Everything's complicated.) 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... sms Also, it seems that /POINTER_SIZE=64=ARGV isn't supported with HP C sms 7.1. I get this when trying to build the test programs with your sms latest scripts, once for each file: sms sms %DCL-W-NOVALU, value not allowed - remove value specification sms \64=\ sms sms And indeed, I can't find that in the help file either... sms sms $ cc/ver sms HP C V7.1-015 on OpenVMS Alpha V8.3 sms smsThat's depressing. My first impulse is to say that 64-bit pointers sms require a newer compiler. It's possible that the =ARGV isn't really sms needed, but I thought that that was the cure for the ACCVIO in the sms subject line of this thread. I'll go back and check, but I believe that sms without the =ARGV, the libraries and shared images may be ok, but all sms the main programs (openssl itself, and some/all of the tests?) will sms explode when they start passing 32-bit argv[] pointers around to sms consumers who expect 64-bit pointers. (HP supplies only one sms OPENSSL.EXE, and I'd bet that it's a 32-bit-pointer edition.) sms smsIf 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... Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Richard Levitte rich...@levitte.org smsI'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. smsIf 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
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
More VMS builder mysteries... In makevms.com, I see: $! P6, if defined, sets a compiler thread NOT needed on OpenVMS 7.1 (and up). I find this about as clear as mud. Can anyone explain what sets a compiler thread means? What, exactly, is NOT needed on OpenVMS 7.1 (and up)? A compiler thread? P6? As I see it, if this P6 is _not_ defined, then all the subsidiary builders add the C macro PTHREAD_USE_D4 to the compiler commands (if the VMS version is V7.1 or higher). But if this P6 _is_ defined, then exactly the same thing happens (for slightly different reasons). What's really supposed to happen when? What would a user specify for this P6 (and why, and when)? I find the comments in pthread.h to be somewhat confusing, but it looks to me as if defining PTHREAD_USE_D4 activates some Temporary support for POSIX 1003.4a/D4 migration stuff, which effectively substitutes (the newer?) pthread_d4.h for the (older?) stuff in pthread.h. Does anyone know why we should do one thing or another? Is there a document somewhere, or has the oral tradition been broken? If defining PTHREAD_USE_D4 is really what we want for VMS V7.1 and up, which is what we seem to be getting, then should we admit that we ignore this P6 for VMS V7.1 and up, or should specifying some P6 actually do something on newer VMS versions? Can this stuff actually be built on VMS before V7.1? If PTHREAD_USE_D4 were _always_ defined, then would it have any effect on VMS versions before V7.1? Is all this P6 stuff just a (confusing) waste of time and effort? test/maketests.com says: $! Should we add MTTEST,PQ_TEST,LH_TEST,DIVTEST,TABTEST as well? where crypto/threads/mttest.c and crypto/threads/th-lock.c seem to be the only consumers of pthread.h. Seems to me to be a reasonable question. What's the answer? Currently, there exists a crypto/threads]pthreads-vms.com (To compile mttest on VMS), which seems to be ignored by the other builders. Should test/maketests.com be building these programs? (Should we have tests which use them?) SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
In message 11031501491312_20200...@antinode.info on Tue, 15 Mar 2011 01:49:13 -0500 (CDT), Steven M. Schweda s...@antinode.info said: sms http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s4a.zip Got openssl-1_0_0d_s4.zip and openssl-1_0_0d_s4a.zip couple of days ago, it's getting tested right now. -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Richard Levitte rich...@levitte.org Got openssl-1_0_0d_s4.zip and openssl-1_0_0d_s4a.zip couple of days ago, it's getting tested right now. My VAX just finished its run through the latest stuff, and it seems to be happy. (The Perl build finished, some of its tests passed, and it seems to work well enough to do test/cms-test.pl. Having a working bc is nice, too.) What could go wrong? Of course, What won't you like? is a different question. I've already supplied a list (or two, or ...) of things I don't like. I still haven't tried to use these libraries or shared images with any other programs. Because of the new HP-like naming, existing builders for other programs may not find the expected .OLB or .EXE without some help -- either revised builders, or SET FILE /ENTER = old_name SSL_whatever. SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
There are probably more such items, lost in the mists of time, but these
were easy to find in the old-complaint pile.
Going back to 3-APR-2010, for example, I provided a fix for a test
problem involving multi-dot file names on an ODS2 file system. I'll try
again.
[...]
2496048:error:02001FFF:system library:fopen:reason(4095):
GIMP$DUA0:[UTILITY.SOURCE.OPENSSL.OPENSSL-1_0_0D.CRYPTO.BIO]BSS_FILE.C;1:
169:fopen('resp1.tsr.token','wb')
2496048:error:2006D002:BIO routines:BIO_new_file:system lib:
GIMP$DUA0:[UTILITY.SOURCE.OPENSSL.OPENSSL-1_0_0D.CRYPTO.BIO]BSS_FILE.C;1:174:
[...]
2496048:error:02001FFF:system library:fopen:reason(4095):
GIMP$DUA0:[UTILITY.SOURCE.OPENSSL.OPENSSL-1_0_0D.CRYPTO.BIO]BSS_FILE.C;1:
169:fopen('resp2.tsr.token_der','wb')
2496048:error:2006D002:BIO routines:BIO_new_file:system lib:
GIMP$DUA0:[UTILITY.SOURCE.OPENSSL.OPENSSL-1_0_0D.CRYPTO.BIO]BSS_FILE.C;1:174:
[...]
test/testtsa.com:
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s4a.zip
I find that it's always more satisfying the second or third time around,
don't you? But next year, you're on your own.
SMS.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
RE: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Hello Steven, I'm having a good time, even if no one else cares. I do care. I apologize for being silent, but I have been very busy with less open source issues. I have tested your changes on IA64 and they work well, indeed. It was a bit tricky with the unusual extra 64 parameter for tests and install - but it worked perfect. Thank you very much for all effort. Hope, Richard will merge them into the code and we'll be lucky to see them in the next release. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 14 mars 2011 13:27 To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS New (complete) replacement file kit: http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s4.zip This includes a util/libeay.num with OPENSSL_strcasecmp, and updated builders. Previously, LINK commands in the builders lacked explicit /[NO]MAP options, so, in batch mode, where the default is /MAP, image map files (.MAP) were spewed out into the source directories. Now, for a NODEBUG build, there should be explicit /NOMAP options everywhere (except for the main shared images, as before, whether that actually makes sense or not). For a DEBUG build, there should be explicit /MAP options which specify appropriate architecture-specific destination directories, so that a .MAP file appears next to the corresponding .EXE file (leaving the source directories unmolested). More builders which open files in DCL should now have ON CONTROL_C error handling which will more reliably close these files if the user whacks the things mid-stream. Some of the test/*.com procedures are still vulnerable. I'm having a good time, even if no one else cares. SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Arpadffy Zoltan zoltan.arpad...@scientificgames.se I'm having a good time, even if no one else cares. I do care. I apologize for being silent, but I have been very busy with less open sour= ce issues. I wasn't complaining about you, but there are still some open questions on this stuff, and feedback from the official OpenSSL folks has been sparse. Pending mysteries include: What to do about defining a pointer-sized integer type. What to do with apparently unused .com files: crypto/des/des-lib.com crypto/threads/pthreads-vms.com demos/engines/rsaref/build.com VMS/test-includes.com If these things are ever to be used, then they need some serious updating. (Am I missing some documentation related to that RSA stuff?) Why this symlink is in the kit: apps/md4.c;1 - ../crypto/md4/md4.c So far, I've left in the C compiler options to disable some warnings: LONGLONGTYPE, LONGLONGSUFX, FOUNDCR. I suspect that now, with /STANDARD = RELAXED, the first two aren't actually needed. If the source kit is properly packaged, then the last one probably isn't either. If these things aren't actually needed, then why not simplify things by removing them? (I may run the experiment when I get bored.) The compiler still emits a couple of %CC-I-QUESTCOMPARE diagnostics which are caused by time_t and size_t being unsigned (around here): if (timeleft.tv_sec 0) ^ %CC-I-QUESTCOMPARE, In this statement, the unsigned expression timeleft.tv_sec is being compared with a relational operator to a constant whose value is not greater than zero. This might not be what you intended. at line number 226 in file IT$DKC0:[UTILITY.SOURCE.OPENSSL.openssl-1_0_0d.crypto.bio]bss_dgram.c;1 if (*outlen = 0) ^ %CC-I-QUESTCOMPARE, In this statement, the unsigned expression *outlen is being compared with a relational operator to a constant whose value is not greater than zero. This might not be what you intended. at line number 180 in file IT$DKC0:[UTILITY.SOURCE.OPENSSL.openssl-1_0_0d.engines.ccgost]gost94_keyx.c;1 If these things vary by environment, and I assume that at least time_t does, then it might be nice to have some configure test to see what's what, and act accordingly. Having a LINK options file named VAX_DECC_OPTIONS.OPT even on a non-VAX system seems misleading, at best. I also doubt that we actually need any of this stuff, anyway, on any system where this stuff can be built: SYS$SHARE:CMA$OPEN_LIB_SHR/SHARE SYS$SHARE:CMA$OPEN_RTL/SHARE Cleaning out all the GNU C and VAX C stuff might be fun, too, unless there's any evidence that anyone would notice. There are probably more such items, lost in the mists of time, but these were easy to find in the old-complaint pile. I have tested your changes on IA64 and they work well, indeed. It was a bit tricky with the unusual extra 64 parameter for tests and ins= tall - but it worked perfect. Just as you need to specify 64 when you build the stuff, you need to specify which stuff to test, and which stuff to install. Did you actually use the resulting libraries or shared images (with their new names), or did you stop when the tests worked? It'd be nice if someone else could try the new zlib stuff, too. Thank you very much for all effort. Hope, Richard will merge them into the code and we'll be lucky to see them = in the next release. I'll be holding my breath. It would be nice, of course, to have a release actually work properly on VMS when it's released. (0.9.8r was a pleasant surprise that way, I recently discovered.) Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s3e.zip Wheee. Will the fun never end? Perhaps after I run VMS/mkshared.com on a VAX, and notice a few other careless errors therein. http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s3f.zip Sigh. No doubt those were the last bugs. It still says this: $! So far, tests have only been made on VMS for Alpha. VAX will come in time. which doesn't seem to be true now. SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Ooh. So close. http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s3d.zip Less buggy editions of: crypto/install-crypto.com ssl/install-ssl.com VMS/mkshared.com SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Ooh. So close. Progress continues. In my never-ending quest for fun, I tried linking an OPENSSL.EXE using the shared images (SSL_*_SHR*.EXE) instead of the object libraries (SSL_*.OLB), which is something the normal VMS builders don't do. Naturally, it didn't work. But it was pretty close. The first problem was new, and mine -- VMS/mkshared.com wasn't looking for ZLIB in the .num files, and I was (or thought that I was) enabling zlib support. That fix seems easy: ALP $ gdiff -u VMS/mkshared.com;-1 VMS/mkshared.com --- VMS/mkshared.com;-1 2011-03-11 12:43:19 -0600 +++ VMS/mkshared.com2011-03-11 22:57:42 -0600 @@ -356,6 +356,7 @@ $ endif $! $ if ((plat_entry .eqs. VMS) .or. - +((plat_entry .eqs. ZLIB) .and. (ZLIB .nes. )) .or. - (arch_vax .and. (plat_entry .eqs. VMSVAX))) then - truesum = truesum + 1 $! Replacement file: http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s3e.zip The second problem appears to be not all my fault (for a change). [...] %ILINK-I-UDFSYM,OPENSSL_STRCASECMP %ILINK-W-USEUNDEF, undefined symbol OPENSSL_STRCASECMP referenced [... in a bunch of places ...] I threw that one in at the end of what looked like the appropriate .num file: ALP $ gdiff -u util/libeay.num;-1 util/libeay.num --- util/libeay.num;-1 2010-07-25 11:56:06 -0500 +++ util/libeay.num 2011-03-11 23:23:49 -0600 @@ -4189,3 +4189,4 @@ CRYPTO_cbc128_decrypt 4561 EXIST::FUNCTION: CRYPTO_cfb128_encrypt 4562 EXIST::FUNCTION: CRYPTO_cfb128_8_encrypt 4563 EXIST::FUNCTION: +OPENSSL_strcasecmp 4594 EXIST::FUNCTION: and then all seemed well. I assume that there's some Master Keeper of the Dot-num Files who should be adding that to the master file in the actual right place, with the actual right number. Or, if there's some other thing to do, then do that. Wheee. Will the fun never end? SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Today's project: Restore command-line case preservation for openssl.exe (on modern non-VAX systems, with Parse Style: Extended). New: apps/vms_decc_init.c. Modified: apps/makeapps.com, plus a bunch of test/*.com files which depended on DCL+C command-line downcasing (or were in danger of doing so). (Except for a new accomodation for 64-bit pointers, this is probably all old stuff which got ignored in the past.) Replacement files: http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s3b.zip Bonus features: apps/CA.com now has a prompt which looks like a prompt instead of a casual remark. test/tests.com now directs SYS$ERROR and SYS$OUTPUT in many places to files instead of to the null device (NLA0:), allowing some diagnosis after a test failure. Addition of (what I hope are) well-placed set noon and set on commands should avoid a variety of problems when a test fails. (I got hit by a definition of SYS$ERROR which persisted after a premature exit from test/tests.com, and messed up the next build.) test/clean_test.com (new) deletes miscellaneous test results files. Question of the day: Is apps/openssl-vms.cnf actually good for anything? Some of the tests use various test/*.cnf files, and these seem to have no VMS-specific variants. SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s3.zip
Unless I've missed something, [...]
Naturally, that was too good to be true. I now have enough Perl on
my VAX system to run into a test failure:
[...]
--- TEST_CMS
CMS consistency test
CMS = PKCS#7 compatibility tests
signed content DER format, RSA key: OK
signed detached content DER format, RSA key: OK
signed content test streaming BER format, RSA: OK
signed content DER format, DSA key: OK
signed detached content DER format, DSA key: OK
signed detached content DER format, add RSA signer: OK
signed content test streaming BER format, DSA key: OK
%DCL-W-TKNOVF, command element is too long - shorten
%DCL-W-TKNOVF, command element is too long - shorten
\mcr SYS$DISK:[-.VAX.EXE.APPS]openssl.exe cms -sign -in smcont.txt
-outform DER -nodetach -signer smime-certs/smrsa1.pem -signer
smime-certs/smrsa2.pem -signer smime-certs/smdsa1.pem -signer
smime-certs/smdsa2.pem -stream -out test.cms 2 cms.err cms
\mcr SYS$DISK:[-.VAX.EXE.APPS]openssl.exe cms -sign -in smcont.txt
-outform DER -nodetach -signer smime-certs/smrsa1.pem -signer
smime-certs/smrsa2.pem -signer smime-certs/smdsa1.pem -signer
smime-certs/smdsa2.pem -stream -out test.cms 2 cms.err cms
signed content test streaming BER format, 2 DSA and 2 RSA keys: generation err
%SYSTEM-F-ABORT, abort
[...]
If you don't work with it regularly, it's easy to forget how lame VMS
VAX V7.3 can be.
A matched pair of changes to test/cms-test.pl and test/tests.com
sucks about twenty characters out of those command lines, which seems to
be good enough (for now). Instead of making Perl expand a DCL symbol
(EXE_DIR - SYS$DISK:[-.VAX.EXE.APPS], in this case) to find
openssl.exe, it's shorter (and cleaner-looking, and less work for
Perl) to define a logical name (OSSLX), and then use that. And a
.exe was redundant, too. (Every byte counts, I always say.)
ALP $ gdiff tests.com;5 tests.com;
345,346c345,346
$ ! The following makes perl include the DCL symbol table in the env.
$ define/user perl_env_tables clisym_local,lnm$file_dev,ctrl_env
---
$ ! Define the logical name used to find openssl.exe in the perl script.
$ define /user_mode osslx 'exe_dir'
ALP $ gdiff cms-test.pl_orig cms-test.pl
59,60c59,60
if ( $^O eq VMS -f $ENV{EXE_DIR}openssl.exe ) {
$ossl_path = pipe mcr $ENV{EXE_DIR}openssl.exe;
---
if ( $^O eq VMS -f OSSLX:openssl.exe ) {
$ossl_path = pipe mcr OSSLX:openssl;
That should be turning:
mcr SYS$DISK:[-.VAX.EXE.APPS]openssl.exe
into:
mcr OSSLX:openssl
With any luck, we won't need to start abbreviating the file names soon.
OSSLX could be even shorter, but I thought that I'd leave a few fat
cells for the next fellow to trim. Replacement files:
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s3a.zip
What could go wrong now?
SMS.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Dr. Stephen Henson st...@openssl.org [...] A simple workaround would be to copy argv into a malloced copy that is properly NULL terminated if you haven't done that already. As all the apps go through main() code in apps/openssl.c you should only need to change one place. That probably makes (much) more sense than fiddling with all the consumers. With HP's newly restrictive patch (un)availability policy, there's not much chance of being able to get away with doing nothing, even if it is all their fault. While you're here, please don't forget that I'm still waiting for wisdom on what to add where to get around the crypto/bn problems caused by sizeof size_t != sizeof void*. Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Dr. Stephen Henson st...@openssl.org [...] A simple workaround would be to copy argv into a malloced copy that is properly NULL terminated if you haven't done that already. As all the apps go through main() code in apps/openssl.c you should only need to change one place. http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s3.zip Unless I've missed something, this should be a complete set of replacement files to be laid over (unzip -V, on VMS) a clean 1.0.0d kit. The new apps/openssl.c obviates most of the other replacement apps/*.c files in previous kits. It seems to work here, but complaints are always welcome. Other than the still-pending mystery of how best to handle the pointer-sized replacement for size_t, these changes may now be ready to be ignored. SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s2e.zip Bad crypto/crypto-lib.com. (Minor error on VAX.) Trust no one, I always say. (Especially me.) It'll be a while before the VAX build gets finished, so stay tuned. There seems to be some evidence that argv[] _should_ be NULL-terminated, which would seem to shift the the blame for the misbehavior of the apps/ programs (on Alpha with 64-bit pointers) from programs themselves to HP's C compiler team. http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1472203 SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Steven, I am sorry, I could not test your changes yet - I'll do it, hopefully, during this week. ...but to be honest, I am more curious what is Richard's opinion about your changes. Regards, Z From: Steven M. Schweda [s...@antinode.info] Sent: Sunday, March 06, 2011 2:53 AM To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS I apparently forgot to include the modified/new start-up procedures (VMS/openssl_startup.com, VMS/openssl_undo.com) in previous update collections: http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s2c.zip SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Arpadffy Zoltan zoltan.arpad...@scientificgames.se I am sorry, I could not test your changes yet - I'll do it, hopefully, duri= ng this week. ...but to be honest, I am more curious what is Richard's opinion about your= changes. I'm curious about anyone's opinion, but you know as much as I do. Please let me know if you see any problems. (By the way, did you have any actual need for the 64-bit-pointer stuff, or was that work done mostly for fun?) Today's change set includes different names for the various [...]install.com procedures, and better clean-up of the logical names which each one defines. http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s2d.zip Ideally, with these changes, no one should find any WRK_* logical names left defined after running any of these procedures. Also, with the new, unique procedure names, the (new) @@@ whatever.com messages should provide some useful information. I think that I've exhausted my to-do list, so, unless I find some new problems, I may be quiet for a while. My VAX is still working on a Perl build (which I was hoping to use for OpenSSL testing), so I still haven't tried the latest version of everything there. (But what could go wrong?) I tried building the original and modified 1.0.0d code on an HP-UX (11.31 ia64) system, and I didn't see any significant differences in the test results. So, either those command-line argc+argv changes were all good, or else the tests are insufficient to show the new problems. Complaints are always welcome, of course. SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
I apparently forgot to include the modified/new start-up procedures (VMS/openssl_startup.com, VMS/openssl_undo.com) in previous update collections: http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s2c.zip SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s2.zip For an install.com which works better (perhaps even properly): http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s2a.zip $ pipe show time ; @ install.com 'p1' ; show time That 'p1' should have been: ''p1' , of course. Sigh. It must all be bug-free, now, though. SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s1.zip A revised, possibly better, replacement file kit (unzip -V) is now available: http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s2.zip The builders should now be able to deal with both 32- and 64-bit pointers in the same source kit directory tree. That should include install.com and VMS/mkshared.com. The object libraries and shared images should now have HP-like names (with $ - _): 32-bit 64-bit SSL_LIBCRYPTO32.OLBSSL_LIBCRYPTO.OLB SSL_LIBSSL32.OLB SSL_LIBSSL.OLB SSL_LIBCRYPTO_SHR32.EXESSL_LIBCRYPTO_SHR.EXE SSL_LIBSSL_SHR32.EXE SSL_LIBSSL_SHR.EXE Among other advantages, this allows one installation directory tree (or SYS$LIBRARY) to accomodate all of them. (When run twice (for 32- and 64-bit builds) with one destination directory, install.com will copy the header files twice, but these may be purged, as suggested.) Other than comments in the changed files, I haven't updated any documentation. (And some of the comments could still use some work.) My VAX is currently saturated building perl, so I haven't tried the latest stuff there. (But what could go wrong? (And who'd care if it did?)) If it finishes the perl job before summer, then I should be able to check that again. For the morbidly curious, my do-everything build procedures (with zlib support) look like these: IT $ type [-]btsi_z.com $ pipe show time ; - @ makevms.com ALL NODEBUG DECC TCPIP - utility_root:[source.zlib.zlib-1_2_5l] ; - show time $ pipe show time ; @ [.test]tests.com ; show time $ pipe show time ; @ [.vms]mkshared.com - utility_root:[source.zlib.zlib-1_2_5l] ; - show time $ pipe show time ; @ install.com 'p1' ; show time IT $ type [-]btsi_64z.com $ pipe show time ; - @ makevms.com ALL 64 NODEBUG DECC TCPIP - utility_root:[source.zlib.zlib-1_2_5l]libz_64 ; - show time $ pipe show time ; @ [.test]tests.com 64 ; show time $ pipe show time ; @ [.vms]mkshared.com 64 - utility_root:[source.zlib.zlib-1_2_5l]libz_64 ; - show time $ pipe show time ; @ install.com ''p1' 64 ; show time Note the 64 arguments on all the procedures for the 64-bit build. Omit the libz path, if you don't have/want zlib support. As one might expect, I'm still awaiting some discussion of the pending mysteries, so there's still work left to be done. Complaints are always welcome. Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
IT $ type [-]btsi_z.com $ pipe show time ; - @ makevms.com ALL NODEBUG DECC TCPIP - utility_root:[source.zlib.zlib-1_2_5l] ; - show time $ pipe show time ; @ [.test]tests.com ; show time $ pipe show time ; @ [.vms]mkshared.com - utility_root:[source.zlib.zlib-1_2_5l] ; - show time $ pipe show time ; @ install.com 'p1' ; show time Oops. Lost a parameter () on mkshared.com: $ pipe show time ; - @ makevms.com ALL NODEBUG DECC TCPIP - utility_root:[source.zlib.zlib-1_2_5l] ; - show time $ pipe show time ; @ [.test]tests.com ; show time $ pipe show time ; @ [.vms]mkshared.com - utility_root:[source.zlib.zlib-1_2_5l] ; - show time $ pipe show time ; @ install.com 'p1' ; show time I suppose that it could benefit from a 'That's not 64!' message. Perhaps in the next round. SMS. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Hello, I seem to have 1.0.0d builds working on VMS Great news, I would be happy to try the build with your changes. Could you please send some instructions where the patch can be found? Or it would be the best to post the diffs here, making available for Richard to merge into the code. Thank you, Steven. Best regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 28 februari 2011 07:28 To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS I seem to have 1.0.0d builds working on VMS with 32- or 64-bit pointers, but I'm still waiting for some guidance on how to make some of the needed changes: 1. I need a macro/typedef for an integer with the same size as a pointer. On non-VMS systems intptr_t might be suitable, but not on VMS, so it appears to me that some new OpenSSL-specific thing must be added. I can get it defined appropriately on VMS. Elsewhere, I don't care; size_t (as is used now), intptr_t, whatever. But I'd be happier (others, too, I'd guess) if someone else chose the name, placement, and other details. I've identified two places where use of size_t caused problems on VMS with 64-bit pointers, crypto/bn/bn_mont.c and crypto/bn/bn_nist.c. It might be wise to scan the code for other inappropriate uses of size_t, as I haven't done that. 2. The argv-using apps/*.c programs need reform to use argc instead of looking for a NULL terminator at the end of argv[]. (Looking for a NULL makes sense for envp[], which is expected to be NULL-terminated, but not so much for argv[], where it causes bad behavior on VMS Alpha with 64-bit pointers, and where argc is obviously available and suitable.) I've converted apps/cms.c and apps/smime.c, because those were causing test failures. My current scheme changes code like this: [...] int MAIN(int argc, char **argv) [...] char **args; [...] args = argv + 1; [...] while (*args) [or similar] [...] args++; [...] to code like this: [...] int MAIN(int argc, char **argv) [...] int argi; char **args; [...] argi = 1; args = argv[argi])[0]; [...] while (argi argc) [or similar] [...] args = argv[++argi]; [...] The maintainer(s) may prefer some other scheme/details, so I'm reluctant to fiddle with the other, similar programs in that collection until someone higher up nods, or complains, or something. (Also, I wouldn't bet that any other of those programs gets tested on VMS, so there's probably some risk in my making the changes to them.) For the ones I have changed, I can supply patches or whole replacement files, if anyone is interested. If some decision maker can settle these pending items, then I can pack this batch of changes into a form which might be more easily adopted into the main code base. Other changes: I've added a C macro, OPENSSL_NO_SETVBUF_IONBF, which is defined only on VMS, and which is used to bracket instances of setvbuf(..., _IONBF, ...). On VMS, this use of setvbuf() is unsupported, and is incompatible with 64-bit pointers. Everyone else can ignore this new macro, and get the same behavior as before. I've modified the VMS builders to allow the user to specify a path to a zlib object library (expecting zlib.h to be in the same directory). I've also done some tidying in the VMS builders (typography, lame code reduction, ...). I've added a new VMS-specific header file, crypto/vms_rms.h to reduce the code clutter involved with NAM versus NAML (RMS file name) structures (in crypto/LPdir_vms.c and crypto/dso/dso_vms.c). I use essentially similar stuff in many other projects. You're welcome to it. (I haven't added a copyright heading.) Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Arpadffy Zoltan zoltan.arpad...@scientificgames.se I seem to have 1.0.0d builds working on VMS Great news, I would be happy to try the build with your changes. Could you please send some instructions where the patch can be found? Or it would be the best to post the diffs here, making available for Richar= d to merge into the code. As I've explained, the stuff I have is not what I'd want in the official code, so I haven't produced a real patch kit, but you might try this: http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s1.zip That's a zip -w (store file version numbers) archive which should include all the new or changed files. If you have your source code in a [.openssl-1_0_0d...] directory tree, then unzip -V (retain VMS version numbers) should put these files (with their higher version numbers) over the originals without destroying anything. (If your directory name is different, then you'll need to move/rename or copy the new files to where you want them.) Note that I didn't try to test all of the new explicit-32-bit descriptor code. If the normal tests hit it, then it's been tested. If not, then it hasn't. It all looked plausible, and the compiler was happy, but I don't promise anything. Those changes should all be invisible in a 32-bit-pointer build, so any new problems should be confined to a 64-bit-pointer environment. If you try to use the new zlib stuff, then you'll need to have an appropriate zlib object library available. The VMS builders in the standard zlib kit don't have a 64-bit-pointer option, so you'll need to do some editing there. I haven't tried using a LIBZ.OLB with the wrong pointer size. The OpenSSL builders trust the user, and don't try to check anything. I assume that something will explode, but I don't know what or where. Wake me when it catches fire. Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
I seem to have 1.0.0d builds working on VMS with 32- or 64-bit pointers, but I'm still waiting for some guidance on how to make some of the needed changes: 1. I need a macro/typedef for an integer with the same size as a pointer. On non-VMS systems intptr_t might be suitable, but not on VMS, so it appears to me that some new OpenSSL-specific thing must be added. I can get it defined appropriately on VMS. Elsewhere, I don't care; size_t (as is used now), intptr_t, whatever. But I'd be happier (others, too, I'd guess) if someone else chose the name, placement, and other details. I've identified two places where use of size_t caused problems on VMS with 64-bit pointers, crypto/bn/bn_mont.c and crypto/bn/bn_nist.c. It might be wise to scan the code for other inappropriate uses of size_t, as I haven't done that. 2. The argv-using apps/*.c programs need reform to use argc instead of looking for a NULL terminator at the end of argv[]. (Looking for a NULL makes sense for envp[], which is expected to be NULL-terminated, but not so much for argv[], where it causes bad behavior on VMS Alpha with 64-bit pointers, and where argc is obviously available and suitable.) I've converted apps/cms.c and apps/smime.c, because those were causing test failures. My current scheme changes code like this: [...] int MAIN(int argc, char **argv) [...] char **args; [...] args = argv + 1; [...] while (*args) [or similar] [...] args++; [...] to code like this: [...] int MAIN(int argc, char **argv) [...] int argi; char **args; [...] argi = 1; args = argv[argi])[0]; [...] while (argi argc) [or similar] [...] args = argv[++argi]; [...] The maintainer(s) may prefer some other scheme/details, so I'm reluctant to fiddle with the other, similar programs in that collection until someone higher up nods, or complains, or something. (Also, I wouldn't bet that any other of those programs gets tested on VMS, so there's probably some risk in my making the changes to them.) For the ones I have changed, I can supply patches or whole replacement files, if anyone is interested. If some decision maker can settle these pending items, then I can pack this batch of changes into a form which might be more easily adopted into the main code base. Other changes: I've added a C macro, OPENSSL_NO_SETVBUF_IONBF, which is defined only on VMS, and which is used to bracket instances of setvbuf(..., _IONBF, ...). On VMS, this use of setvbuf() is unsupported, and is incompatible with 64-bit pointers. Everyone else can ignore this new macro, and get the same behavior as before. I've modified the VMS builders to allow the user to specify a path to a zlib object library (expecting zlib.h to be in the same directory). I've also done some tidying in the VMS builders (typography, lame code reduction, ...). I've added a new VMS-specific header file, crypto/vms_rms.h to reduce the code clutter involved with NAM versus NAML (RMS file name) structures (in crypto/LPdir_vms.c and crypto/dso/dso_vms.c). I use essentially similar stuff in many other projects. You're welcome to it. (I haven't added a copyright heading.) Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Steven M. Schweda wrote: What seems (to me) to be needed in these cases is some macro or typedef which is an integer whose size is reliably the same as that of a pointer, which size_t is not. Hi Steve, Please take a look at your copy of stdint.h. See if you have a definition for the intptr_t and uintptr_t types. The POSIX standard(*) says The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to a pointer to void, and the result will compare equal to the original pointer: intptr_t. Ditto for uintptr_t, except that it is unsigned. The standard also says that intptr_t and uintptr_t are required on XSI-conformant systems; otherwise, they are optional. So you might have to define _XSI_SOURCE to make their declarations visible. It seems to me that this data type is just what you (and OpenSSL) are looking for. Hope this info helps. (*) The POSIX-2008 standard is online at http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm. You must pre-register to view it, but the registration step carries no charge and is simple to perform. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Green, Paul paul.gr...@stratus.com What seems (to me) to be needed in these cases is some macro or typedef which is an integer whose size is reliably the same as that of a pointer, which size_t is not. =20 Hi Steve, Please take a look at your copy of stdint.h. See if you have a definition for the intptr_t and uintptr_t types. Around here, they're in inttypes.h. (We don't have to show you any stinking stdint.h!) The POSIX standard(*) says The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to a pointer to void, and the result will compare equal to the original pointer: intptr_t. Ditto for uintptr_t, except that it is unsigned. The standard also says that intptr_t and uintptr_t are required on XSI-conformant systems; otherwise, they are optional. So you might have to define _XSI_SOURCE to make their declarations visible. It seems to me that this data type is just what you (and OpenSSL) are looking for. Hope this info helps. You might think so, but, in its boundless wisdom, DEC/Compaq/HP has implemented these things in an unfortunate way: /* ** Declare [un]signed integral types large enough to hold any pointer. */ #if !defined(__VAX) typedef int64_t intptr_t; typedef uint64_t uintptr_t; #else typedef int32_t intptr_t; typedef uint32_t uintptr_t; #endif So, on a non-VAX (64-bit-capable) system, these types are _always_ 64 bits, irregardful of the actual pointer size. This leads to annoying complaints like %CC-I-INTCONSTTRUNC (and friends) when trying to get from one of these types back to a 32-bit pointer. I sent a complaint about this to HP back in 2009, but the responding Indian didn't see it as a problem, so I gave up. (And even if they did fix it now, many old systems would be stuck with the problem, so it's mostly hopeless.) Because of these sorry facts, I see no easy way to avoid adding and using an OpenSSL-defined type, although on most systems, intptr_t would seem to be an ideal value to use for the thing. (*) The POSIX-2008 standard is online at http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm. You must pre-register to view it, but the registration step carries no charge and is simple to perform. Thanks for the link. Perhaps I'll forward that to HP when I get sufficiently bored. On a different point, a closer look at the 64-bit-pointer test results shows a problem on Alpha (but not on IA64) somewhere in the CMS = PKCS#7 compatibility test sequence. Perhaps some file I/O thing? The perl script doesn't seem to handle an explosion here very well. A search for fail in the test results transcript won't detect the absence of an ALL TESTS SUCCESSFUL message, making it easy for a casual inspection to miss this kind of failure. Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Steven M. Schweda sms@antinode-info
On a different point, a closer look at the 64-bit-pointer test
results shows a problem on Alpha (but not on IA64) somewhere in the CMS
= PKCS#7 compatibility test sequence. Perhaps some file I/O thing?
The perl script doesn't seem to handle an explosion here very well. A
search for fail in the test results transcript won't detect the
absence of an ALL TESTS SUCCESSFUL message, making it easy for a
casual inspection to miss this kind of failure.
The cause of this test failure seems to be yet another unexpected
quirk -- not really file I/O. So far as I can see, all the popular
app/*.c main programs (cms.c, genpkey.c, nseq.c, ocsp.c, pkcs12.c,
pkcs8.c, pkey.c, pkeyparam.c, and smime.c) scan their argument list
using this scheme:
[...]
int MAIN(int argc, char **argv)
[...]
char **args;
[...]
args = argv + 1;
[...]
while (*args) [or similar]
[...]
args++;
[...]
That is, they look for a NULL terminator at (past) the end of argv.
My apparent problem is that on VMS V8.3 Alpha (at least), with 64-bit
pointers, the argv array is not reliably NULL-terminated, and when
it's not, these programs (cms in the case at hand) will grab at least
one noise pointer after the end of the actual argument list. For
example, some diagnostic output looked like this:
cms. argc = 10.
[Here, it's looking at the non-option (file-name) arguments...]
cms(0). argc_x = 3, *args: smime-certs/smrsa1.pem.
cms(1). argc_x = 3, *args: smime-certs/smrsa1.pem.
file_ctrl(). ptr: %x004e077a smime-certs/smrsa1.pem.
cms(1). argc_x = 2, *args: smime-certs/smrsa2.pem.
file_ctrl(). ptr: %x004e0791 smime-certs/smrsa2.pem.
cms(1). argc_x = 1, *args: smime-certs/smrsa3.pem.
file_ctrl(). ptr: %x004e07a8 smime-certs/smrsa3.pem.
cms(1). argc_x = 0, *args: ÀØÜz.
file_ctrl(). ptr: %x7adcd870 ÀØÜz.
Error opening recipient certificate file ÀØÜz
910895052:error:02001002:system library:fopen:no such file or directory:ALP$DKA0
:[UTILITY.SOURCE.OPENSSL.openssl-1_0_0d_64.crypto.bio]bss_file.c;3:403:fopen('ÀØ
Üz','r')
910895052:error:20074002:BIO routines:FILE_CTRL:system lib:ALP$DKA0:[UTILITY.SOU
RCE.OPENSSL.openssl-1_0_0d_64.crypto.bio]bss_file.c;3:405:
unable to load certificate
(argc_x is my own decrementing argc-related variable, and when it
hit zero, it was time to stop.)
Perhaps argv _should_ be NULL-terminated, but that seems not to be
the case here. (Eventually, the programs are likely to run into enough
zero bytes to stop the scan, but who knows when?) I have no idea how
much space is actually allocated in this case, so I'd be reluctant to
jam a NULL into argv[ argc], just so that this code will work reliably.
One possible solution (work-around?) would be not to look for a
NULL terminator in argv, but instead count the arguments, and quit
when the last argument has been processed. For example, instead of
bumping that args pointer through the argv array (looking for that
NULL), one could use an integer argument counter, say, arrghc, look at
argv[ arrghc] instead of *args, and stop when arrghc gets up to
argc. Making the changes to all these files would be tedious, but
(not having tried it) I don't see any obvious problems.
Using the known count (argc) makes more sense to me than looking
for a terminating (NULL) value, but what do I know?
Again, even if there's some Standard which demands a NULL after the
(known) end of argv, I ain't got one, so it wouldn't help.
Thoughts?
Steven M. Schweda sms@antinode-info
382 South Warwick Street(+1) 651-699-9818
Saint Paul MN 55105-2547
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
RE: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Hello, It is interesting that not forcing the /pointer_size=64 - the build is OK (by running @makevms all nodebug) Until now, I believed that DCC will use 64-bit pointers on a 64-bit architecture when the pointer size is not explicitly specified. LIBCRYPTO.OLB;312952 15-FEB-2011 11:40:04.66 (/pointer_size not specified - everything is OK) LIBCRYPTO.OLB;212501 10-FEB-2011 18:28:46.78 (/pointer_size=64 FAILED) LIBCRYPTO32.OLB;2 12404 15-FEB-2011 11:40:05.13 (/pointer_size=32) LIBCRYPTO32.OLB;1 12404 10-FEB-2011 18:28:47.14 (/pointer_size=32) Seems, there is some kind of smart cast around descriptors when not explicitly specified that the pointers' size is 64-bit. It is time to dig deeper into the literature. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 14 februari 2011 19:52 To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS From: Arpadffy Zoltan via RT r...@openssl.org I have tested 1.0.0d release on OpenVMS and found many warnings during th= e build with 64bits pointer size that produced many annoying warning mess= ages during linking against the library - like: Building The BNTEST Test Program. %ILINK-W-COMPWARN, compilation warnings module: DSO_VMS file: USRDSK:[ZAY.WORK.OPENSSL-100D.IA64.EXE.CRYPTO]LIBCRYPTO.OLB= ;1 You get the LINK warning bacause you didn't fix the compiler warnings. Unfortunately the 64bit pointer size build on ALPHA has the very same fai= l. Compaq C V6.4-008 on OpenVMS Alpha V7.3-2 That's not _un_fortunate, that's _fortunate_. _Un_fortunate would be if you got results on Alpha which differed from those on IA64. Compiling The o_dir.c File. (LIBRARY,LIB) (*ctx)-filespec_dsc.dsc$a_pointer =3D (*ctx)-filespec; ...^ %CC-W-MAYLOSEDATA2, In this statement, (*ctx)-filespec has a larger da= ta size than short pointer to char. Assignment can result in data loss. at line number 121 in file USRDSK:[ZAY.WORK.OPENSSL-100D.CRYPTO]LPDIR_VMS= .C;1 Well, yeah. I'd expect a complaint every time you use a 32-bit descriptor in a 64-bit-pointer environment. While I've never used one, I assume that that's why 64-bit descriptors exist, and I'd guess that you'll need to fix all the (VMS-specific) code which uses descriptors. Knowing nothing, I'd assume that you'd need to add some 64-bit-descriptor declarations, contitional on __INITIAL_POINTER_SIZE (if __INITIAL_POINTER_SIZE == 64, say). With any luck, the consumers of these descriptors might accept either descriptor type. setvbuf(in, NULL, _IONBF, 0); /* don't do buffered reads */ ..^ %CC-W-MAYLOSEDATA2, In this statement, in has a larger data size than = short p ointer to short pointer to struct _iobuf. Assignment can result in data= loss. at line number 147 in file USRDSK:[ZAY.WORK.OPENSSL-100D.CRYPTO.RAND]RAND= FILE.C; Apparently (stdio,h), setvbuf() is in the category of functions and declarations which do not support 64 bit pointers being passed (or returned). I'd guess that you'll need to disable that code on VMS, at least when 64-bit pointers are used. (It may be unwise to have the behavior on VMS depend on the pointer size, so it might be better to disable it always on VMS.) Any such change should include a good explanation in its comments. Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Arpadffy Zoltan zoltan.arpad...@scientificgames.se It is interesting that not forcing the /pointer_size=3D64 - the build is OK= (by running @makevms all nodebug) Interesting, perhaps, but not really news. 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. [...] Until now, I believed that DCC will use 64-bit pointers on a 64-bit archite= cture when the pointer size is not explicitly specified. If DCC is anything like DEC/Compaq/HP C, then no, as documented. Seems, there is some kind of smart cast around descriptors when not explici= tly specified that the pointers' size is 64-bit. HELP CC Language_topics Preprocessor #pragma Look for pointer_size. It is time to dig deeper into the literature. The time for that might actually have been near when you were first thinking about saying /POINTER_SIZE = 64. Note that (as I read the stuff) most of the RMS structures, including FAB and NAM[L], support only 32-bit pointers/descriptors, so all those file names can't use 64-bit pointers/descriptors. I took a quick look at this stuff and decided that some thought would be needed to decide how to make it work. I suspect that some string copying will be needed for the RMS stuff. Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Hello Steven, The time for that might actually have been near when you were first thinking about saying /POINTER_SIZE = 64. Yes, you are right... I was running ahead without learning enough about the topic. Then, after all, I think, the best solution would be to leave as it is and close this (#2449) issue. We can continue to live with default (/NOPOINTER_SIZE) and optional 32-bit build (/POINTER_SIZE=32) Maybe, it would be useful to change the makevms.com script that do not allow /POINTER_SIZE=64 parameter, but in those cases change that to /NOPOINTER_SIZE instead. What is your opinion? Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 15 februari 2011 14:48 To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS From: Arpadffy Zoltan zoltan.arpad...@scientificgames.se It is interesting that not forcing the /pointer_size=3D64 - the build is OK= (by running @makevms all nodebug) Interesting, perhaps, but not really news. 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. [...] Until now, I believed that DCC will use 64-bit pointers on a 64-bit archite= cture when the pointer size is not explicitly specified. If DCC is anything like DEC/Compaq/HP C, then no, as documented. Seems, there is some kind of smart cast around descriptors when not explici= tly specified that the pointers' size is 64-bit. HELP CC Language_topics Preprocessor #pragma Look for pointer_size. It is time to dig deeper into the literature. The time for that might actually have been near when you were first thinking about saying /POINTER_SIZE = 64. Note that (as I read the stuff) most of the RMS structures, including FAB and NAM[L], support only 32-bit pointers/descriptors, so all those file names can't use 64-bit pointers/descriptors. I took a quick look at this stuff and decided that some thought would be needed to decide how to make it work. I suspect that some string copying will be needed for the RMS stuff. Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Arpadffy Zoltan zoltan.arpad...@scientificgames.se Then, after all, I think, the best solution would be to leave as it is and = close this (#2449) issue. We can continue to live with default (/NOPOINTER_SIZE) and optional 32-bit = build (/POINTER_SIZE=3D32) Maybe, it would be useful to change the makevms.com script that do not allo= w /POINTER_SIZE=3D64 parameter, but in those cases change that to /NOPOINTE= R_SIZE instead. What is your opinion? My opinion is that if a build with 64-bit pointers is important, then the VMS-specific code should be fixed enough to let it work. If it's not important, then why do _anything_ with /POINTER_SIZE? Why have a build option which doesn't work? As usual, it might be nice to know how HP handled this, but I'm not holding my breath while we wait to hear from them. Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Hello, Why have a build option which doesn't work? Actually, it works good enough to keep, as we can still use the following options: - 32 for build with /POINTER_SIZE=32 - that is used often together with older applications. - for build with default /NOPOINTER_SIZE (that is definitely not compatible nor exchangeable with /POINTER_SIZE=32 built libraries. Therefore, the important thing that is needed to be noted for such dummy dreamers like me, that parameter 64 is not equal to parameter - and those two are not exchangeable. Hmmm also make a side note, that the current OpenSSL code is not able to be built with full 64-bit pointer size option - but as we lived so far without it - we can continue to use the OpenSSL libraries as it is, until somebody really needs 64-bit pointer size. Thank you, Steven. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 15 februari 2011 15:40 To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS From: Arpadffy Zoltan zoltan.arpad...@scientificgames.se Then, after all, I think, the best solution would be to leave as it is and = close this (#2449) issue. We can continue to live with default (/NOPOINTER_SIZE) and optional 32-bit = build (/POINTER_SIZE=3D32) Maybe, it would be useful to change the makevms.com script that do not allo= w /POINTER_SIZE=3D64 parameter, but in those cases change that to /NOPOINTE= R_SIZE instead. What is your opinion? My opinion is that if a build with 64-bit pointers is important, then the VMS-specific code should be fixed enough to let it work. If it's not important, then why do _anything_ with /POINTER_SIZE? Why have a build option which doesn't work? As usual, it might be nice to know how HP handled this, but I'm not holding my breath while we wait to hear from them. Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Steven, You are right again - as always. I checked the HP's code and indeed, they use $ USER_CCFLAGS == /pointer_size=64 This means that the HP SSL product really does deliver both 32 and 64 bit libraries. It would be fruitful, if somebody competent could look into the HP's code and see how they solved the 64-bit descriptors issue. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 15 februari 2011 16:14 To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS From: Arpadffy Zoltan zoltan.arpad...@scientificgames.se Why have a build option which doesn't work? Actually, it works good enough to keep, as we can still use the following o= ptions: - 32 for build with /POINTER_SIZE=3D32 - that is used often together with o= lder applications. - for build with default /NOPOINTER_SIZE (that is definitely not compati= ble nor exchangeable with /POINTER_SIZE=3D32 built libraries. A library built using /POINTER_SIZE=32 is _not_ the same as one built using /NOPOINTER_SIZE? Really? I can see where /POINTER_SIZE=64 would be different. How is /POINTER_SIZE=32 different? (I can also see where it might be important to say /POINTER_SIZE=64=ARGV, when building a main program with 64-bit pointers, too.) Therefore, the important thing that is needed to be noted for such dummy dr= eamers like me, that parameter 64 is not equal to parameter - and those = two are not exchangeable. Perhaps everyone else reads the HELP (or the other documentation). Hmmm also make a side note, that the current OpenSSL code is not able to be= built with full 64-bit pointer size option - but as we lived so far withou= t it - we can continue to use the OpenSSL libraries as it is, until somebod= y really needs 64-bit pointer size. Define we. HP supplies SSL$LIBCRYPTO_SHR.EXE, SSL$LIBCRYPTO_SHR32.EXE, SSL$LIBSSL_SHR.EXE, and SSL$LIBSSL_SHR32.EXE. I thought that the whole idea was to get the OpenSSL builder(s) to create SSL_LIBCRYPTO_SHR.EXE/OLB, SSL_LIBCRYPTO_SHR32.EXE/OLB, SSL_LIBSSL_SHR.EXE/OLB, and SSL_LIBSSL_SHR32.EXE/OLB, that is, 32- and 64-bit libraries and shared images. (Even if no one wanted to add the SSL_ prefixes.) Did I miss something? Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
From: Arpadffy Zoltan via RT r...@openssl.org I have tested 1.0.0d release on OpenVMS and found many warnings during th= e build with 64bits pointer size that produced many annoying warning mess= ages during linking against the library - like: Building The BNTEST Test Program. %ILINK-W-COMPWARN, compilation warnings module: DSO_VMS file: USRDSK:[ZAY.WORK.OPENSSL-100D.IA64.EXE.CRYPTO]LIBCRYPTO.OLB= ;1 You get the LINK warning bacause you didn't fix the compiler warnings. Unfortunately the 64bit pointer size build on ALPHA has the very same fai= l. Compaq C V6.4-008 on OpenVMS Alpha V7.3-2 That's not _un_fortunate, that's _fortunate_. _Un_fortunate would be if you got results on Alpha which differed from those on IA64. Compiling The o_dir.c File. (LIBRARY,LIB) (*ctx)-filespec_dsc.dsc$a_pointer =3D (*ctx)-filespec; ...^ %CC-W-MAYLOSEDATA2, In this statement, (*ctx)-filespec has a larger da= ta size than short pointer to char. Assignment can result in data loss. at line number 121 in file USRDSK:[ZAY.WORK.OPENSSL-100D.CRYPTO]LPDIR_VMS= .C;1 Well, yeah. I'd expect a complaint every time you use a 32-bit descriptor in a 64-bit-pointer environment. While I've never used one, I assume that that's why 64-bit descriptors exist, and I'd guess that you'll need to fix all the (VMS-specific) code which uses descriptors. Knowing nothing, I'd assume that you'd need to add some 64-bit-descriptor declarations, contitional on __INITIAL_POINTER_SIZE (if __INITIAL_POINTER_SIZE == 64, say). With any luck, the consumers of these descriptors might accept either descriptor type. setvbuf(in, NULL, _IONBF, 0); /* don't do buffered reads */ ..^ %CC-W-MAYLOSEDATA2, In this statement, in has a larger data size than = short p ointer to short pointer to struct _iobuf. Assignment can result in data= loss. at line number 147 in file USRDSK:[ZAY.WORK.OPENSSL-100D.CRYPTO.RAND]RAND= FILE.C; Apparently (stdio,h), setvbuf() is in the category of functions and declarations which do not support 64 bit pointers being passed (or returned). I'd guess that you'll need to disable that code on VMS, at least when 64-bit pointers are used. (It may be unwise to have the behavior on VMS depend on the pointer size, so it might be better to disable it always on VMS.) Any such change should include a good explanation in its comments. Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Hello, I have tested 1.0.0d release on OpenVMS and found many warnings during the build with 64bits pointer size that produced many annoying warning messages during linking against the library - like: Building The BNTEST Test Program. %ILINK-W-COMPWARN, compilation warnings module: DSO_VMS file: USRDSK:[ZAY.WORK.OPENSSL-100D.IA64.EXE.CRYPTO]LIBCRYPTO.OLB;1 ...that most likely produces an ACCVIO I have build on an IA64 environment HP C V7.2-001 on OpenVMS IA64 V8.3 and got: test BN_mont Montgomery multiplication test failed! %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00649D580064 9D50, PC=00274650, PS=001B Improperly handled condition, image exit forced. Signal arguments: Number = 0005 Name = 000C 00649D5800649D50 00274650 001B Register dump: R0 = R1 = 007D R2 = 7ACAF340 R3 = 00032A00 R4 = 7FFCF818 R5 = 7FFCF8B0 R6 = 100A R7 = 0001 R8 = R9 = 0014 R10 = 12D061D4 R11 = 12D061C0 SP = 7ACAF330 TP = 7B722D40 R14 = 7B8E19DC R15 = 7ACAF330 R16 = 0001 R17 = FFDD R18 = 001A R19 = 0040 R20 = 12D061D4 R21 = 12D061C0 R22 = 8002A330 R23 = 001DB1A9 R24 = 0011 R25 = 0001 R26 = 5964280C R27 = 31750614 R28 = 0008 R29 = 0011 R30 = B2C85018 R31 = 7ACAF7C5 PC = 00274650 BSP/STORE = 07FDBFFD4448 / 07FDBFFD4290 PSR = 101308026030 IIPA = 00274640 B0 = 00032A30 B6 = 00032A00 B7 = 000326B0 Interrupted Frame RSE Backing Store, Size = 4 registers R32 = 00649D5800649D50 R33 = 881A3D00 R34 = R35 = C205 It is interesting that the 32 bit pointer size build has not had such problems at all. Unfortunately the 64bit pointer size build on ALPHA has the very same fail. Compaq C V6.4-008 on OpenVMS Alpha V7.3-2 test BN_mont Montgomery multiplication test failed! %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0038BF880038BF80, PC=00228FB4, PS=001B Improperly handled condition, image exit forced. Signal arguments: Number = 0005 Name = 000C 0038BF880038BF80 00228FB4 001B Register dump: R0 = 0002 R1 = 0038BF880038BF80 R2 = 80023F70 R3 = 7AE07340 R4 = 0001 R5 = 000ED530 R6 = R7 = 7AE073E8 R8 = 000ED550 R9 = 0002 R10 = 80023F70 R11 = 7FFCDBE0 R12 = 7FFCDA60 R13 = 7AF247E0 R14 = R15 = 7AF23E20 R16 = 0038BF880038BF80 R17 = 7AE07340 R18 = 7AE072E8 R19 = 0001 R20 = 00CB R21 = 0020 R22 = 23A567C0 R23 = R24 = 0014 R25 = 0001 R26 = 00228E2C R27 = 0004CE58 R28 = 2825CECD R29 = 7AE07260 SP = 7AE07260 PC = 00228FB4 PS = 201B @MAKEVMS.COM ALL 64 nodebug Compiling The o_dir.c File. (LIBRARY,LIB) (*ctx)-filespec_dsc.dsc$a_pointer = (*ctx)-filespec; ...^ %CC-W-MAYLOSEDATA2, In this statement, (*ctx)-filespec has a larger data size than short pointer to char. Assignment can result in data loss. at line number 121 in file USRDSK:[ZAY.WORK.OPENSSL-100D.CRYPTO]LPDIR_VMS.C;1 %LIBRAR-W-COMCOD, compilation warnings in module O_DIR file USRDSK:[ZAY.WORK.OPE NSSL-100D.IA64.OBJ.CRYPTO]O_DIR.OBJ;1 dso_vms.c p-filename_dsc.dsc$a_pointer = p-filename; ^ %CC-W-MAYLOSEDATA2, In this statement, p-filename has a larger data size than short pointer to char. Assignment can result in data loss. at line number 212 in file USRDSK:[ZAY.WORK.OPENSSL-100D.CRYPTO.DSO]DSO_VMS.C;1 p-imagename_dsc.dsc$a_pointer = p-imagename;
