GNU bug report logs - #20783
25.0.50; [PATCH] byte-to-position has internal off-by-one bug

Previous Next

Package: emacs;

Reported by: Wolfgang Jenkner <wjenkner <at> inode.at>

Date: Wed, 10 Jun 2015 15:20:05 UTC

Severity: normal

Tags: patch

Found in version 25.0.50

Fixed in version 25.1

Done: Wolfgang Jenkner <wjenkner <at> inode.at>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Wolfgang Jenkner <wjenkner <at> inode.at>
Cc: 20783 <at> debbugs.gnu.org
Subject: bug#20783: 25.0.50; [PATCH] byte-to-position has internal off-by-one bug
Date: Tue, 16 Jun 2015 19:08:49 +0300
> From: Wolfgang Jenkner <wjenkner <at> inode.at>
> Cc: 20783 <at> debbugs.gnu.org
> Date: Tue, 16 Jun 2015 17:40:38 +0200
> 
> +      while (!CHAR_HEAD_P (*chp))
> +	{
> +	  pos_byte--;
> +	  /* There's no buffer gap in the middle of a character.  */
> +	  chp--;
> +	}

Thanks, but I'd prefer we didn't have code that manipulated pointers
to buffer text directly.  E.g., if we ever have some kind of
multi-threading, or even if at some point someone adds a non-trivial
function call to this loop, this code will be a subtle bug waiting to
bite.  It's fundamentally not safe to do this, and not only due to the
gap considerations, but also because in general BEG_ADDR might change
under certain circumstances behind your back.  (Buffer text and string
data are implemented with double indirection for good reasons.)

For some very tight loops, it might be justified to take these
shortcuts (with WARNING COMMENTS CRYING BLOODY MURDER all around), but
this function doesn't belong to those cases.

So I prefer the previous variant, even though it will lose that
benchmark.




This bug report was last modified 9 years and 345 days ago.

Previous Next


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