Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: C pointer semantics with dynamically allocated struct Date: Fri, 16 Oct 2015 08:50:18 -0700 Organization: None to speak of Lines: 71 Message-ID: References: <87h9m9qd67.fsf@bsb.me.uk> <39591d0f-05c8-4aaa-99e9-283fade3d012@googlegroups.com> <878u7jpwwv.fsf@bsb.me.uk> <878u7jo9xi.fsf@bsb.me.uk> <1cb437ed-216b-439b-b892-60d5c8decf33@googlegroups.com> <87wpv2n74q.fsf@bsb.me.uk> <5611447c.6325171@news.xs4all.nl> <561e2e49.3744281@news.xs4all.nl> <537dc231-7dc2-4ecb-8d55-4d847c9e8e0c@googlegroups.com> <29db6d81-16ae-4f18-9a3a-ac290b823144@googlegroups.com> <839bc0ff-6090-4171-956b-10cd0db49129@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="12463"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/eYki3U7NwousSDbX1KHGP" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:gyCN3P/6Ft3JdC0LM66Nbh/8oA0= sha1:EgksB9BVimNq6K//csAPEqw8FOI= Xref: csiph.com comp.lang.c:73038 supercat@casperkitty.com writes: > On Thursday, October 15, 2015 at 5:51:56 PM UTC-5, Keith Thompson wrote: >> If char is unsigned, then it has exactly the same range and >> representation as unsigned char. If char is signed, then negative >> values have no representation as unsigned char, and unsigned char values >> greater than CHAR_MAX hae no representation as char, so it's not >> possible for char and unsigned char to have "equivalent >> >> representations". (Unless you have your own definition of the phrase >> "equivalent representations", which I suspect you do.) > > In all systems, conversion of a negative value to an unsigined value of the > same type yields the value which, when adding the inverse of that negative > value, yields the original. In other words, signed-to-unsigned conversions > are specified in a fashion independent of representation. > > In a two's-complement system, this conversion is representation-preserving. > In other systems, it is not. Just look at how much reasoning you have to do, and how many assumptions you have to make, to determine (not entirely accurately) that sequences of plain char are the best way to talk about object representations. Is it *really* just to avoid having to type "unsigned "? > In C as envisioned by K&R, there was no question but that every object > had a unique representation in "char" because there *was* no "unsigned > char". C89 relaxed this by allowing for the possibility of implementations > where "char" as a signed type with a non-two's-complement representation > but I don't know whether any such platforms existed. If none have ever > existed, I don't see much point in continuing to allow for them. When K&R1 was written, there were more 1's-complement machines in production use than there are now. I don't remember whether the book mentions any such machines; I'll check later today. In any case, unsigned char exists, and has existed for at least 26 years. The language has changed since 1978, and at least some of the changes were made for good reasons. The fact that pre-ANSI C didn't have unsigned char is no reason not to use it now. >> Hmm? I certainly don't avoid typing "unsigned char". I'm not aware >> that other programmers do either. I'll use uint8_t if I want to >> explicitly assume 8-bit bytes; otherwise I'll use unsigned char to refer >> to raw memory. > > I see a lot of code using "uint8_t". I've seen some code that uses uint8_t where, in my opinion, unsigned char would be more appropriate. Perhaps some such code is meant to emphasize that it's only meant to deal with CHAR_BIT==8. I don't think that C programmers in general avoid typing unsigned char, which was the specific claim you made. I certainly don't. Regardless of what the standard does or doesn't say, isn't it easier to reason about object representations if you don't have to worry about signed values? Each byte of an object's representation is a sequence of 8 (more generally CHAR_BIT) bits, which can be viewed as a number in the range 0 to 255 (more generally 2**CHAR_BIT-1). What conceptual benefit do you see in using a type that, even assuming 2's-complement, can have a range of *either* 0.255 *or* -128..+127? Why waste time worrying about signed values when it's completely unnecessary, and when using an unsigned type is conceptually simpler? Would your position be the same if C had made "byte" a keyword equivalent to or replacing "unsigned char"? -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"