[Top][All Lists]

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

bug#32252: [PATCH] %o and %x now format signed numbers

From: Andy Moreton
Subject: bug#32252: [PATCH] %o and %x now format signed numbers
Date: Tue, 24 Jul 2018 17:26:57 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (windows-nt)

On Tue 24 Jul 2018, Paul Eggert wrote:

> Helmut Eller wrote:
>> With your change %x will also have quite a different meaning in C11.
> Not really, as Emacs (format "%x" N) agrees with C11 printf ("%x", N) in all
> values of N that are valid in both languages. In C11, negative values are not
> valid, as printf ("%x", N) has undefined behavior when N is negative. So we
> are discussing an area where Emacs Lisp can define behavior without
> introducing incompatibilities with C11.

As emacs fixnums are signed, and the C printf conversion specifier "%x"
takes an unsigned int argument, there are expected to be differences in

However what matters in C (and in elisp) is not what the spec says, but
what the codebase of existing users does, and what existing library
implementations do.

When printing values with base!=10, it is always the underlying
representation (i.e. bit pattern) that is of interest, not the value
interpreted as a signed number. Long standing practice in many languages
shows values printed in hex, octal and binary as unsigned.

> If we changed (format "%x" -1) to signal an error instead, that would also be
> upward-compatible with C11. However, it's more useful for something like
> (format "#x%x" -1) to output a string that can 'read' can scan to get -1,
> something that's not true of Emacs now.

I agree that there is a problem, but not with your solution.

I think it would be better to change the reader to treat non-base10
values as if they were unsigned representations, so that `format' is
unchanged, and (read (format "#x%x" -1)) evaluates to -1.

That is consistent wth other languages and user expectation.

> It does matter to me, actually. I think Emacs should have sensible behavior
> even in corner cases that hardly ever arise in real programs.

I agree: a consistent model of behaviour is important, even if it may
take a while to fix buggy behaviour that disagrees with the model.


reply via email to

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