Full_Name: Ryan Tandy Version: master, 2.4 OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan
This is sort of a follow-up to ITS#7871. ldif_sput gained an LDIF_KLUDGE, but ldif_put did not, so the latter now wraps at 76 columns instead of 78. (IMO ldif_sput and ldif_put could both just pass 0 for wrap instead of a specific number, and let ldif_sput_wrap set the default.) LDIF_SIZE_NEEDED still assumes wrapping to LDIF_LINE_WIDTH columns, so code that does LDIF_SIZE_NEEDED and then ldif_sput is now allocating (slightly) more memory than it actually needs. 389-ds does this, for example. (And actually, couldn't LDIF_SIZE_NEEDED just be a thinner wrapper around LDIF_SIZE_NEEDED_WRAP?) Not sure exactly what the policies are around API changes in exposed headers, but for 2.5, maybe LDIF_LINE_WIDTH could change to 78 and LDIF_KLUDGE could go away entirely? Should I take this part to -devel? BTW, is it still necessary for ldif.c to re-implement base64 instead of using the lutil functions?
