[Top][All Lists]

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

Re: Subtle error defining VALMASK?

From: Paul Eggert
Subject: Re: Subtle error defining VALMASK?
Date: Wed, 10 Sep 2014 07:58:29 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

Dmitry Antipov wrote:

#define VALMASK_val (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX)

shouldn't it be

#define VALMASK_val (USE_LSB_TAG ? - (1L << GCTYPEBITS) : VAL_MAX)

or, if --with-wide-int on a 32-bit system:


There's no error here. All three definitions are equivalent because - (1 << GCTYPEBITS) equals -8, which sign-extends to the width of VAL_MAX. When it doesn't matter, it's better to avoid length suffixes on integer constants.

There is another programming style, where authors take care to write exact suffixes on constants, e.g., 'lseek (fd, 0L, SEEK_SET)' when lseek's 2nd argument is 'long'. In the old days before function prototypes this style was often necessary but that need went away long ago, and nowadays this other style is typically more trouble than it's worth. For example, the 'lseek' call would be "wrong" now because lseek's argument type was changed from 'long' to 'off_t', and so a maintainer would have to change the call to 'lseek (fd, (off_t) 0, SEEK_SET)', whereas the simpler style 'lseek (fd, 0, SEEK_SET)' would survive the API change without needing maintenance.

reply via email to

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