Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: "undefined behavior"? Date: Wed, 12 Jun 2024 15:18:34 -0700 Organization: None to speak of Lines: 26 Message-ID: <877cet7qkl.fsf@nosuchdomain.example.com> References: <666a095a$0$952$882e4bbb@reader.netnews.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Thu, 13 Jun 2024 00:18:34 +0200 (CEST) Injection-Info: dont-email.me; posting-host="32c0f168ad8ff54df06981ba253a92e6"; logging-data="1935800"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19hUpd5MqJy8/IuQmrW5Org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:OAQ7+zrtnpzGMMbL11NsO21CJ1Y= sha1:q8Ho1nDX0HDQiceZpjQXNt4D44c= Bytes: 2158 David Brown writes: [...] > I recommend never using "char" as a type unless you really mean a > character, limited to 7-bit ASCII. So if your "outliers" array really > is an array of such characters, "char" is fine. If it is intended to > be numbers and for some reason you specifically want 8-bit values, use > "uint8_t" or "int8_t", and initialise with { 0 }. [...] The implementation-definedness of plain char is awkward, but char arrays generally work just fine for UTF-8 strings. If char is signed, byte values greater than 127 will be stored as negative values, but it will almost certainly just work (if your system is configured to handle UTF-8). Likewise for Latin-1 and similar 8-bit character sets. The standard string functions operate on arrays of plain char, so storing UTF-8 strings in arrays of uint8_t or unsigned char will seriously restrict what you can do with them. (I'd like to a future standard require plain char to be unsigned, but I don't know how likely that is.) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */