[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?