Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Compiling and linking code from different places in the file system
Date: Fri, 09 Mar 2018 10:10:06 -0800
Organization: None to speak of
Lines: 43
Message-ID: <lnmuzhce81.fsf@kst-u.example.com>
References: <p793c8$7d8$1@dont-email.me> <slrnp9h0lc.eu5.grahn+nntp@frailea.sa.invalid> <p7e47k$sua$1@dont-email.me> <slrnp9n8ll.eu5.grahn+nntp@frailea.sa.invalid> <bc4352bf-5ec2-4d47-9c47-22e261ea51f2@googlegroups.com> <6oSnC.178019$eQ7.108635@fx46.am4> <87o9k055d2.fsf@bsb.me.uk> <lxUnC.79953$zk1.77648@fx03.am4> <afce8849-eec5-4828-b141-3df0a9f7bb3b@googlegroups.com> <lny3j3eoxy.fsf@kst-u.example.com> <13a67039-e46b-4337-a1a3-058210e55b6e@googlegroups.com> <lntvtreju5.fsf@kst-u.example.com> <ba477256-00f2-4aaa-bb37-05c93ecc5422@googlegroups.com> <p7r0t0$tud$1@dont-email.me> <lnina6e9fs.fsf@kst-u.example.com> <p7s8ej$8ln$1@dont-email.me> <bf8ebc4b-1b0a-4213-a7c8-dd92f71874b5@googlegroups.com> <lntvtqcgfg.fsf@kst-u.example.com> <p7tj81$lag$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="bb2cdd46fc14bf16d0e6a78dcd8fc907"; logging-data="14465"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18+rPVm4RKHGubsCb6QoZJy"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:++/WY5KhzlVvUysnWMIC3uUW2kI= sha1:cEFfqx70YQAGm+VGnGHYP1M3PRY=
Xref: csiph.com comp.lang.c:127569

David Brown <david.brown@hesbynett.no> writes:
> On 09/03/18 00:10, Keith Thompson wrote:
>> jameskuyper@verizon.net writes:
>>> On Thursday, March 8, 2018 at 4:03:25 PM UTC-5, David Brown wrote:
>> [...]
>>>> Perhaps checking for (INT_MIN + 1) == -0x7fffffff would avoid any 
>>>> possible problems?
>>>
>>> Decimal constants have signed type unless explicitly terminated with a
>>> U or u. Octal and hexadecimal constants, on the other hand, can have
>>> either signed or unsigned types, depending upon the values of the
>>> corresponding *_MAX macros (6.4.4.1p4). For instance, that constant will
>>> have the type "unsigned int" if
>>> INT_MAX < 0x7fffffff && 0x7fffffff <= UINT_MAX - an unlikely combination
>>> on any real world machine, but permissible for a fully conforming
>>> implementation of C. If UINT_MAX == 0x7fffffff, the expression
>>> -0x7fffffff would have a value of 0x1.
>> 
>> For preprocessor arithmetic, signed and unsigned integer types are
>> treated as having the same representation as intmax_t and uintmax_t,
>> respectively, so they're at least 64 bits.
>
> That applies to C99 (and C11), but not C90 which does not have intmax_t
> and uintmax_t (assuming I remember correctly - I don't have C90 open at
> the moment).  And if we have C99 (or C11), we can just use int32_t and
> be happy!

In C90:

    The resulting tokens comprise the controlling constant expression
    which is evaluated according to the rules of 6.4 using arithmetic
    that has at least the ranges specified in 5.2.4.2, except that int
    and unsigned int act as if they have the same representation as,
    respectively, long and unsigned long.

(C90 didn't have intmax_t and uintmax_t, but if it did it presumably
would have defined them as long and unsigned long.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"