Subject: Re: bug#64089: 30.0.50; `ldap-search' errors out with `wrong-type-argument listp' when called WITHDN == t

From: Eli Zaretskii <[email-masked]>
Date: Sat, 17 Jun 2023 11:41:54 +0300

> Cc: [email-masked], [email-masked],
>  [email-masked]
> Date: Sat, 17 Jun 2023 09:03:25 +0300
> From: Eli Zaretskii <[email-masked]>
> 
> > From: Filipp Gunbin <[email-masked]>
> > Cc: [email-masked], Stefan Monnier <[email-masked]>, Eli
> >  Zaretskii <[email-masked]>
> > Date: Sat, 17 Jun 2023 01:13:33 +0300
> > 
> > > I tried to make the patch as conservative as possible and
> > > intentionally do not check syntax of the dn line if its parsing is not
> > > required.
> > 
> > I think I have better patch here.  This is what it addresses:
> > 
> > 1) The bug you reported.  My patch tries to keep the API intact (we
> > don't want breakage, however I think not much people actually use withdn
> > arg): return dn as a string, prepended to attribute alist.
> > 
> > 2) dn is now parsed just like the other attributes, with the same
> > regexp.
> > 
> > 3) (unrelated, just noticed and fixed) Match data clobbering in this
> > piece:
> > 
> > -            ;; Need to handle file:///D:/... as generated by OpenLDAP
> > -            ;; on DOS/Windows as local files.
> > -            (if (and (memq system-type '(windows-nt ms-dos))
> > -                     (eq (string-match "/\\(.:.*\\)$" value) 0))
> > -                (setq value (match-string 1 value)))
> > 
> > 4) This code:
> > 
> > +          (when dn
> > +	    (cond (withdn 
> > +		   (push (cons dn (nreverse record))
> > +                         result))
> > 
> > intentionally doesn't check whether record is non-nil:  potentially we
> > could request "no attributes" (there's an option for that in ldapsearch,
> > however I don't think this is currently possible in ldap.el), and it's
> > ok to return just dn.
> > 
> > Please give it a try, if it's OK and others have no objections, I'll
> > install it on Monday (on master, I guess).
> 
> Yes, this is more complex change, so it is not appropriate for
> emacs-29.
> 
> I think I will install Jens's patch on emacs-29 marking it not for
> merging to master.

Now done, but without the "do not merge" mark, sorry.  So on master
you will need to undo the fix (but please wait for me to merge from
the branch to master).