Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!mcsun!hp4nl!sci.kun.nl!cs.kun.nl!lwj
From: lwj@cs.kun.nl (Luc Rooijakkers)
Newsgroups: comp.lang.c
Subject: Re: Is #define THING -10 completely safe?
Message-ID: <2698@wn1.sci.kun.nl>
Date: 29 Jan 91 10:01:51 GMT
References: <33@christmas.UUCP> <14998@smoke.brl.mil>
Sender: root@sci.kun.nl
Organization: University of Nijmegen, The Netherlands
Lines: 53

In <14998@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:

>In article <33@christmas.UUCP> rtm@island.COM (Richard Minner) writes:
>>Something I've been curious about, should the above be
>>#define INT_MIN   (-2147483648)

>Yes.

This may have been the intention of the comittee. However, I cannot find
such a guarantee:

	2.2.4.2 Sizes of Integral Types <limits.h>

	The values given below shall be replaced by constant expressions
	suitable for use in #if preprocessing directives.
	
Now, an expression like -2147483648 certainly satisfies the above
constraints.

>>The precedence rules seem to imply that ()'s aren't needed
>>with a negative integer constant.

>There are contexts that could cause trouble, e.g. "x-INT_MIN"
>or "x=INT_MIN".  While the C standard requires that these work
>as expected, many older C implementations will misinterpret
>these.

Right. As has been pointed out already, however, there are also contexts
that can cause trouble where the standard requires it, e.g.

	INT_MIN[p]

which expands to

	-2147483648[p]

which is equivalent to

	-(2147483648[p])

Thus, I would conclude that INT_MIN cannot be used in this way in a
strictly conforming program. Instead, 

	(INT_MIN)[p]
	
would have to be used.

(This is an obscure corner of the language, I agree.)

--
Luc Rooijakkers                                 Internet: lwj@cs.kun.nl
Faculty of Mathematics and Computer Science     UUCP: uunet!cs.kun.nl!lwj
University of Nijmegen, the Netherlands         tel. +3180652271