[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#8345) inconsistencies regarding LDIF line length



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?