emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trunk r117396: Do not allow out-of-range character position in Fcomp


From: Stefan Monnier
Subject: Re: trunk r117396: Do not allow out-of-range character position in Fcompare_strings.
Date: Wed, 25 Jun 2014 11:17:50 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

>> IIUC, this small discussion ended with "it's too late to fix".  Why did
>> you make the change, then?
> "Too late" for emacs-24, which is in pretest stage.

That was a misunderstanding: the discussion has never been about
emacs-24 AFAICT since it's not about fixing a bug.

>> And if it's okay to change the semantics, why not change it the other
>> way, relaxing `substring' requirements?
> Why relaxing?

It can be convenient.  There's always a tension between checking args
sanity and providing a useful fallback behavior for
"non-canonical" values.

> IMO relaxing just means more error-prone code (imagine
> an `aset' which silently ignores writing an element beyond array end,
> or `aref' which always returns nil in that case).

We don't have the behavior for aref, but we do have it for nth and
gethash and people frequently rely on this behavior.

> Anyway, you can defsubst a tiny wrapper to relax if you need.

Most of your patch is good.  The only problematic part is the one that
signals an error for greater-than-length values.  Adding a wrapper won't
solve that problem, since the main issue is not that the new semantic is
bad but that it breaks backward compatibility.

Now that it's installed, I guess we can try to run with it for a while,
but I expect we'll get many bug reports from it because external
packages rely on that behavior (just like bundled packages relied on it,
or even more so since many external packages don't use string-prefix-p
because it didn't exist back then).


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]