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: Thu, 08 Mar 2018 13:55:17 -0800
Organization: None to speak of
Lines: 66
Message-ID: <ln6066dygq.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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="d5db3c990c5a8317a11173691196aced"; logging-data="1478"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX182JjnL+nWv22FUK4FqgGdV"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:5pDMbeAf1Ybp7WOfj7YyfWkErdg= sha1:a0Zll4ysMY65+OpEDPAwMWXQiug=
Xref: csiph.com comp.lang.c:127506

David Brown <david.brown@hesbynett.no> writes:
> On 08/03/18 18:58, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> And then name one where you could not do this to get valid int32_t and
>>> uint32_t types:
>>>
>>> #include <limits.h>
>>>
>>> #if INT_MIN == -2147483647
>>> typedef int int32_t;
>>> typedef unsigned int uint32_t;
>>> #elif LONG_MIN == -2147483647
>>> typedef long int int32_t;
>>> typedef unsigned long int uint32_t;
>>> #elif SCHAR_MIN == -2147483647
>>> typedef signed char int32_t;
>>> typedef unsigned char uint32_t;
>>> #else
>>> #error No support for 32-bit sized types
>>> #endif
>> 
>> You mean -2147483648, not -2147483647.  And the expression -2147483648
>> can be problematic.  I'd check the value of INT_MAX (and I'd likely use
>> 0x7fffffff because it's easier to see typos).
>> 
>
> Yes, I meant -2147483648 - and yes, hex is easier in this case.
>
> But I did mean to check INT_MIN rather than INT_MAX - because (as far as 
> I can see) that check will also ensure that the representation is two's 
> complement and not one's complement or sign magnitude (which could have 
> INT_MAX equal to 2147483647 and INT_MIN equal to -2147483647).  For C99 
> compatible int32_t and uint32_t types, int32_t must be two's complement.
>
> Perhaps checking for (INT_MIN + 1) == -0x7fffffff would avoid any 
> possible problems?

#if INT_MIN == -2147483647-1
...

If you need to support non-two's-complement systems you might consider
something like:

#if INT_MIN == -2147483647-1
typedef int int32_t;
typedef int32_t signed32_t;
#elif INT_MIN == -2147483647-1
typedef int signed32_t;
...
#endif

The idea being that int32_t meets the strict C99/C11 requirements, while
signed32_t is a 32-bit signed type that might not be two's-complement,
which is probably good enough for most uses.  You might also think about
padding bits.  (Macros should be defined so you can tell which types
exist.)

In most contexts, assuming two's-complement probably isn't too bad, but
the assumption should at least be documented.

-- 
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"