Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: does a double cast to unsigned makes sense in any circumstance?
Date: Fri, 28 Jan 2022 19:37:41 -0800
Organization: None to speak of
Lines: 55
Message-ID: <87fsp7ky9m.fsf@nosuchdomain.example.com>
References: <86czl8kaew.fsf@levado.to> <sqvfed$rps$1@dont-email.me> <8635lotrby.fsf@levado.to> <ss06le$h5n$1@dont-email.me> <87y23fxt9p.fsf@nosuchdomain.example.com> <86a6fur0rh.fsf@levado.to> <87tue2xbu5.fsf@nosuchdomain.example.com> <864k5n9wdw.fsf@levado.to>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="7db0e57409d381c02446ec8e6e17a154"; logging-data="11515"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Jj4qEToNgv6sYvsj7X+18"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:vf17+2sEn/MU3rQs+zbScec6GA8= sha1:ItvdXsrTPPJ40ZEZXRPe8ySRXMc=
Xref: csiph.com comp.lang.c:164709

Meredith Montgomery <mmontgomery@levado.to> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>> [...]
>>>>> "... the value is converted by repeatedly adding ... one more than the
>>>>> maximum value that can be represented in the new type until the value is
>>>>> in the range of the new type." (6.3.1.3p2).
>>>>>
>>>>> It's the other direction that's dangerous: conversion of an integer
>>>>> value to a signed integer type that is not representable in that type
>>>>> has undefined behavior.
>>>>
>>>> No, converting an out-of-range integer value to a signed integer type
>>>> yields an implementation-defined result or raises an
>>>> implementation-defined signal.  (C99 added the option of raising a
>>>> signal; in my opinion that was a bad idea.)
>>>
>>> Just curious --- why do you think a signal is a bad idea?
>>
>> A signal isn't inherently a bad idea, particularly if portable code can
>> handle it.  But the fact that the signal is implementation-defined makes
>> that impossible.  (And freestanding implementations needn't support
>> <signal.h>.)
>
> What's a freestanding implementation?

See section 4 of any edition of the C standard.  I usually use
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf, a draft
that's close to C11.

    The two forms of *conforming implementation* are hosted and
    freestanding. A *conforming hosted implementation* shall accept any
    strictly conforming program. A *conforming freestanding implementation*
    shall accept any strictly conforming program in which the use of the
    features specified in the library clause (clause 7) is confined to the
    contents of the standard headers <float.h>, <iso646.h>, <limits.h>,
    <stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and
    <stdnoreturn.h>. A conforming implementation may have extensions
    (including additional library functions), provided they do not alter
    the behavior of any strictly conforming program.

Basically a hosted implementation is the kind that you're most likely to
encounter.  It generates code that runs under an operating system, and
it supports the entire standard library.  A freestanding implementation
targets an embedded system that might not have an operating system at
all.  The only standard library headers that must be supported are the
ones that don't declare any functions.  A freestanding implementation
might provide some library functions, but it isn't required to.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */