Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Beginner....Decimal/Octal converter help
Date: Thu, 15 Sep 2022 08:07:45 -0700
Organization: A noiseless patient Spider
Lines: 24
Message-ID: <864jx8n0am.fsf@linuxsc.com>
References: <8ffd982c-2e82-4caa-9256-ec17be2efe56n@googlegroups.com> <tfl0im$1vu1b$1@dont-email.me> <87r10hzn19.fsf@bsb.me.uk> <tfnh5k$29dcu$1@dont-email.me> <87mtb4wq4f.fsf@bsb.me.uk> <tfnnob$1d8r$1@gioia.aioe.org> <875yhswfiv.fsf@bsb.me.uk> <tfpm5j$2idls$1@dont-email.me> <8735cvtryu.fsf@bsb.me.uk> <tfpvun$tdk$1@gioia.aioe.org> <87tu5bs282.fsf@bsb.me.uk> <tfqhcm$2l21g$1@dont-email.me> <20220913131411.121@kylheku.com> <tfqsa1$bb0$1@gioia.aioe.org> <875yhrhs5o.fsf@nosuchdomain.example.com> <tfqvf2$1f88$1@gioia.aioe.org> <20220913224818.803@kylheku.com> <tfs291$2rt4s$1@dont-email.me> <87sfkugg5e.fsf@nosuchdomain.example.com> <tft3jt$1ie2$1@gioia.aioe.org> <20220914180404.544@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader01.eternal-september.org; posting-host="376a9b3ff63bd0e2e5a5853723368b8e"; logging-data="3539359"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX183f6U6QA/W2r6hfnaRucfJEW+GrUOKB30="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:n0B8V8UpFie4NHuMljwUcxc6eBw= sha1:9GvL1jyg7b8VIWF/sKLatvQIy+A=
Xref: csiph.com comp.lang.c:167735

Kaz Kylheku <480-992-1380@kylheku.com> writes:

> On 2022-09-14, Bart <bc@freeuk.com> wrote:
>
>> And, because even those int8_t types are so hackish, C already suffers
>> from poor support for those types for:
>
> These hapless {u}int8 types are a pitfall.
>
> In C there are certain requirements that an object may be accessed
> through an lvalue of character type.  That's more or less the basis for
> the validity of being able to memcpy an object to a compatible object
> (that topic is a whole can of worms, and I won't comment on it
> further).
>
> I'm getting to the point that these requirements do not extend to the
> "int8" family of types, even if they are de facto the same thing on a
> given imlementation.
>
> If you use uint8_t as a substitute for unsigned char, you could
> be bringing in undefined behavior.  It's not worth it;
> just stay away.

My sentiments exactly.