GNU bug report logs - #34338
26.1; delete-file return codes and failures

Previous Next

Full log

Message #39 received at 34338 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 34338 <at> debbugs.gnu.org
Subject: Re: bug#34338: 26.1; delete-file return codes and failures
Date: Wed, 30 Oct 2019 23:52:50 +0100

Boruch Baum <boruch_baum <at> gmx.com> writes:

> How is it backwards incompatable? If the prior behavior was undefined,
> no one would have been using it for anything. From their perspective, a
> defined is just another form of undefined behavior, if you get my drift.

Having re-read the entire discussion, I think that we should perhaps
clarify what we're talking about.  Your proposal had three different
parts to it AFAICT:

Boruch Baum <boruch_baum <at> gmx.com> writes:

> B1) return t on success

Eli said that: "The function's return value is not documented, which is
an indication that it is 'not useful'."

Do you have a use-case in mind here?  Can't the caller just check using
'file-exists-p' if it matters instead?

> B2) raise an error when (not NOERROR) and:
> 
>   B2.1) file doesn't exist
> 
>   B2.2) (and (chmod -w) (not FORCE))
> 
>   B2.3) another form of permission denial is encountered

Eli replied: "In any case, you propose a backward-incompatible change in
behavior, so it won't fly.  We could perhaps do it the other way around:
add a new optional argument ERROR-OUT, which, when non-nil, will cause
the function to signal an error when B2.1 or B2.2 happen (I believe B2.3
already causes an error).  And similarly with FORCE."

I'm not against this part, but again I'm not sure what is the use-case
here.  And what about having the caller use 'file-exists-p' instead?

> B3) return nil when NOERROR and:
> 
>   B2.1) file doesn't exist
> 
>   B2.2)  another form of permission denial is encountered

I guess the inverted version of the above makes sense (return nil unless
ERROR-OUT), iff we add B1 and B2.

> C) maybe log the exact error or reason for nil to *Messages*.

This part was agreed to be left out already, and I agree.

Best regards,
Stefan Kangas

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.