- define a HERE variable to indicate where the source tree is (used
very little right now)
- make more use of copying and making attribute changes to {file}.new,
and then move it to {file}
- use 'mv -f' to avoid all those questions to the user when the file
in question doesn't have write attributes for that user.
the one to be used to denote local labels in single function scope.
Problem is that SHA uses same label set across functions, therefore I
have to switch back to $ prefix.
the one to be used to denote local labels in single function scope.
Problem is that SHA uses same label set across functions, therefore I
have to switch back to $ prefix.
BIO_s_bio.pod. The most logical is to move everything needed from
BIO_new_bio_pair.pod to BIO_s_bio.pod (including the nice example)
and toss BIO_new_bio_pair.pod. I hope I got all the info over properly.
PR: 370
BIO_s_bio.pod. The most logical is to move everything needed from
BIO_new_bio_pair.pod to BIO_s_bio.pod (including the nice example)
and toss BIO_new_bio_pair.pod. I hope I got all the info over properly.
PR: 370
pushed item. The index is the number of items - 1. And if a NULL item was
found, actually use it.
Finally, provide a little bit of safety in CRYPTO_lock() by asserting the a
requested dynamic lock really must exist, instead of just being silent about it
pushed item. The index is the number of items - 1. And if a NULL item was
found, actually use it.
Finally, provide a little bit of safety in CRYPTO_lock() by asserting the a
requested dynamic lock really must exist, instead of just being silent about it
(before SSLeay, maybe?), it's better to have that macro protect
the compatibility header des_old.h. In the new des.h, let's use
a slightly different protecting macro.
The rationale is that there are application that might include (via
other header files, perhaps) both an old libdes des.h and OpenSSL's
des.h. Whichever comes first would overshadow the other because of
the clash in protecting macro. This fix solves that problem.
(before SSLeay, maybe?), it's better to have that macro protect
the compatibility header des_old.h. In the new des.h, let's use
a slightly different protecting macro.
The rationale is that there are application that might include (via
other header files, perhaps) both an old libdes des.h and OpenSSL's
des.h. Whichever comes first would overshadow the other because of
the clash in protecting macro. This fix solves that problem.
