#asprintf

Use asprintf() instead of a fixed 128-byte size in SSL_CIPHER_description() when no storage buffer is passed.

Replace all use of ERR_add_error_data with ERR_asprintf_error_data. This avoids a lot of ugly gymnastics to do snprintfs before sending the bag of strings to ERR, and eliminates at least one place in dso_dlfctn.c where it was being called with the incorrect number of arguments and using random things off the stack as addresses of strings.

— beck

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/asn1/a_mbstr.c.diff?r1=1.14;r2=1.15

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/asn1/asn1_gen.c.diff?r1=1.6;r2=1.7

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/asn1/asn1_lib.c.diff?r1=1.24;r2=1.25

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/asn1/asn_mime.c.diff?r1=1.12;r2=1.13

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/asn1/tasn_dec.c.diff?r1=1.20;r2=1.21

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/bio/b_sock.c.diff?r1=1.32;r2=1.33

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/bio/bss_conn.c.diff?r1=1.22;r2=1.23

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/bio/bss_file.c.diff?r1=1.24;r2=1.25

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/cms/cms_smime.c.diff?r1=1.6;r2=1.7

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/comp/c_zlib.c.diff?r1=1.12;r2=1.13

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/conf/conf_def.c.diff?r1=1.18;r2=1.19

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/conf/conf_lib.c.diff?r1=1.8;r2=1.9

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/conf/conf_mod.c.diff?r1=1.17;r2=1.18

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/dso/dso_dlfcn.c.diff?r1=1.20;r2=1.21

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/engine/eng_cnf.c.diff?r1=1.7;r2=1.8

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/engine/eng_fat.c.diff?r1=1.8;r2=1.9

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/engine/eng_list.c.diff?r1=1.6;r2=1.7

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/evp/evp_pbe.c.diff?r1=1.13;r2=1.14

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/evp/evp_pkey.c.diff?r1=1.12;r2=1.13

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/ocsp/ocsp_ht.c.diff?r1=1.11;r2=1.12

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/ocsp/ocsp_vfy.c.diff?r1=1.7;r2=1.8

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/pem/pem_lib.c.diff?r1=1.22;r2=1.23

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/pkcs7/bio_ber.c.diff?r1=1.7;r2=1.8

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/pkcs7/pk7_smime.c.diff?r1=1.12;r2=1.13

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/ts/ts_conf.c.diff?r1=1.3;r2=1.4

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/ts/ts_rsp_verify.c.diff?r1=1.7;r2=1.8

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/ui/ui_lib.c.diff?r1=1.17;r2=1.18

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/x509/x509_att.c.diff?r1=1.6;r2=1.7

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/x509/x509name.c.diff?r1=1.8;r2=1.9

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/x509v3/v3_akey.c.diff?r1=1.8;r2=1.9

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/x509v3/v3_alt.c.diff?r1=1.17;r2=1.18

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/x509v3/v3_conf.c.diff?r1=1.10;r2=1.11

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/x509v3/v3_info.c.diff?r1=1.13;r2=1.14

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/x509v3/x509v3.h.diff?r1=1.12;r2=1.13

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/d1_pkt.c.diff?r1=1.16;r2=1.17

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/s3_pkt.c.diff?r1=1.35;r2=1.36

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/err/err.c.diff?r1=1.29;r2=1.30

add ERR_asprintf_error_data, A tool to be used to get rid of the far too frequent construct of 30 lines of pointer and strlcat insanity followed by an ERR_add_error_data. I will sweep through here like a chubby mongol horde in the next few days pillaging crappy ERR_add_error_data's. Oh and while we're at it fix the nasty vdata function to use something less hard on the eyes.

Recently, I did some cleanup to nvi2's string operations. Here are some notes.

First, we need a definition to the "C string". This is very important since some libc functions do not really work with the C strings. A C string is a NUL-terminated byte sequence[1]. Further more, a function which works with the C strings must always terminate its result with '\0'. Otherwise, the function is regarded to work with the "fixed width strings"[2], or, raw memory.

strncpy(3) has been criticized a lot for the inconsistency between its name and its behavior. Sometimes, it terminates its result; but if the supplied buffer is not big enough, strncpy will just fill the buffer, and wish it can simplify the succeeding truncation handling. However, since the behavior itself is "politically wrong", this API is error-prone.

The problem is caused by the length argument. If it is the length of the string, in such a case, memcpy(3) makes more sense and gives more efficiency. If the argument is the size of the buffer, since you probably not be able to resize the buffer, the buffer must be NUL-terminated. In such a case, strlcpy(3) should be used instead.

The similar problem also happens to strncat(3), and there is also a strlcat(3). But wait... When the last time you use str*cat? If you do want the performance, memcpy is still the best choice; and if you want a clean logic, you can always use snprintf(3), or my favorite asprintf(3) if you are not tied to an existing buffer.

Don't be fear of the dynamic allocation, which may be the only approach if you have to handle an input with an unlimited length, like, a very long line. getline(3) perfectly replaces fgets(3) here. getline(3) manages a reusable dynamically allocated buffer, so that you only need to free(3) it once after you've finished reading all the lines. Ah, yes, the GNU readline(3) should be criticized here -- you have to call free(3) for each line you read -- time to switch to the BSD editline(3) API.

Links:

[1] Nul-terminated string. https://en.wikipedia.org/wiki/Null-terminated_string