Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #71436 > unrolled thread
| Started by | supercat@casperkitty.com |
|---|---|
| First post | 2015-09-29 09:49 -0700 |
| Last post | 2015-10-04 22:16 -0700 |
| Articles | 20 on this page of 172 — 16 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-09-29 09:49 -0700
Re: C pointer semantics with dynamically allocated struct wssimms@gmail.com - 2015-09-30 21:18 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-01 09:35 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-01 09:41 -0700
Re: C pointer semantics with dynamically allocated struct gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-01 18:34 +0000
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-01 12:02 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-02 13:03 +0000
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-02 06:20 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 16:07 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-02 08:46 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 17:28 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-02 10:30 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 20:32 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-02 12:58 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 22:06 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 09:31 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-03 14:31 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 09:27 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-03 20:36 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 13:00 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-03 23:37 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 17:07 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-03 17:42 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 17:49 -0700
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-03 23:28 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-04 00:10 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-04 13:24 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-04 14:07 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-04 14:40 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-04 18:04 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-04 20:10 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-04 22:15 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-05 08:53 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-06 08:45 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-06 12:34 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-06 17:16 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-06 21:47 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 11:05 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-07 11:47 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 13:50 -0700
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-07 18:10 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-07 16:10 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 16:33 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 09:08 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 10:43 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 11:50 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 12:19 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-07 15:32 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 16:21 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 08:54 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 11:15 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 12:38 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 13:30 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 14:15 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 14:53 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 15:23 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 17:24 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-09 08:02 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-09 09:02 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-09 12:43 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-09 14:21 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-09 15:14 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-13 18:37 -0700
Re: C pointer semantics with dynamically allocated struct Martin Shobe <martin.shobe@yahoo.com> - 2015-10-07 20:56 -0500
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 19:41 -0700
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-07 23:15 -0400
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-14 10:05 +0000
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 11:23 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-14 08:24 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-16 11:12 +0000
Re: C pointer semantics with dynamically allocated struct Gareth Owen <gwowen@gmail.com> - 2015-10-16 21:55 +0100
Re: C pointer semantics with dynamically allocated struct Les Cargill <lcargill99@comcast.com> - 2015-10-16 22:08 -0500
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-14 11:44 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-14 11:12 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-07 10:34 +0000
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-07 07:23 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-07 09:53 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-14 10:13 +0000
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-14 11:36 -0400
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-04 13:35 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-04 06:23 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-04 15:34 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-04 08:07 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-04 14:42 +0000
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-04 15:37 +0000
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-05 00:33 +0100
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-14 10:20 +0000
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-14 13:55 +0100
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 22:06 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-14 10:30 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-14 08:39 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-14 23:47 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 10:20 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-15 11:10 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 12:11 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 12:35 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-15 13:52 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 14:35 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-15 15:51 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 06:48 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-16 08:50 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 10:06 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-16 12:45 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 13:56 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-16 14:29 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 14:52 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-16 15:32 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 15:59 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-17 00:03 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-17 00:08 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 15:26 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-17 16:38 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-16 23:43 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 23:57 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 14:50 -0700
Re: C pointer semantics with dynamically allocated struct Ian Collins <ian-news@hotmail.com> - 2015-10-18 10:55 +1300
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-17 18:24 -0400
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-17 18:39 -0400
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-17 18:56 -0400
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 16:17 -0700
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-18 11:46 -0400
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-17 19:44 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-17 16:48 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-10-18 01:14 +0100
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-17 20:22 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-17 17:26 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-10-18 01:44 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 20:09 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-18 11:24 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-19 04:42 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-19 16:24 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 02:20 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-19 19:53 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 09:41 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 19:53 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 16:07 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 14:55 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-18 04:28 +0000
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 12:49 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 12:26 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 12:48 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-17 08:21 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 22:23 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 09:10 -0700
Re: C pointer semantics with dynamically allocated struct Martin Shobe <martin.shobe@yahoo.com> - 2015-10-02 11:58 -0500
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 11:38 -0700
Re: C pointer semantics with dynamically allocated struct Martin Shobe <martin.shobe@yahoo.com> - 2015-10-05 09:36 -0500
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-12 09:47 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-13 02:51 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-12 23:45 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 13:54 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-16 01:07 +0000
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-19 15:33 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 19:21 +0100
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 12:10 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 21:24 +0100
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 14:32 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 23:43 +0100
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 16:49 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-03 02:01 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-03 00:38 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-02 16:10 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 21:54 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-05 08:19 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-02 15:16 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-02 22:52 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-03 00:48 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-03 08:22 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-03 12:05 -0700
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-03 16:38 -0400
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-03 00:00 +0100
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 22:16 -0700
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-16 08:50 -0700 |
| Message-ID | <lnvba66ced.fsf@kst-u.example.com> |
| In reply to | #73029 |
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 <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"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-16 10:06 -0700 |
| Message-ID | <8c2eb673-c0ec-4be0-a564-77ba5ac63d2c@googlegroups.com> |
| In reply to | #73038 |
On Friday, October 16, 2015 at 10:50:28 AM UTC-5, Keith Thompson wrote:
> 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 "?
I think certain things would be cleaner conceptually if C had a type which
represented underlying storage, with the following characteristics:
1. Conversion of the type to "int" or "long" and back is guaranteed to be a
round trip **if no arithmetic is done on the "int" or "long" value**.
2. Performing arithmetic on the "int" or "long" value would either turn it
into a number using rules an implementation may or may not opt to
specify, or trigger a trap whose *existence* would be Implementation-
Defined but whose consequences need not me. Further, even if further
arithmetic yields the same number as was first yielded by the conversion,
conversion of that number back to the original "raw byte" type could
yield a result different from the original provided the implementation
documents that possibility.
Most implementations would opt to specify the how the conversions work, but
it is not hard to imagine useful implementations which cannot support all of
the semantics required of "unsigned char" but could support the semantics of
a type as described above (among other things, consider the following
program (assuming "unsigned long long" is at least as large as uintptr_t)
void main(void)
{
int i;
long long l;
unsigned char *p;
for (i=0; i<100000000; i++)
{
p = malloc(1);
*p = getchar();
l = (long long)p;
printf("%llX ",l);
}
printf("\n\nNow type the pointer: "); flush(stdout);
scanf("%llX", &l);
p = (unsigned char*)(uintptr_t)l;
printf("The char was [%c]\n", *p);
}
It might be useful to have a garbage collector that could identify pointers
which were never going to be used again, but the defined semantics of the
"unsigned char" type make that impossible, it would have no way of knowing
whether any of the pointers that had previously existed might exist in
future.
There is usefulness to being able to copy a structure which contains
pointers via means that don't need to know or care about the pointers in the
structures. The ability to turn a structure into a series of *numbers* and
use those numbers to reconstitute it is definitely useful in some cases, and
many implementations should support that ability, but there are many useful
things that could be done in C without requiring that ability, and an
implementation that was not required to support that ability would be able
to do useful things which are not presently possible in C but could be very
useful in a "sandboxed" language.
> > 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 C as originally envisioned, memcpy() accepted arguments of type char*
and compared the memory locations identified thereby. Such a comparison
would be meaningful on a system where char is either unsigned or is a
two's-complement signed value. It would be pretty much meaningless on
any system where char is a one's-complement or sign-magnitude value.
Is there any evidence that ANSI ever intended to allow for machines where
performing the indicated operations on type "char*" would not be meaningful?
> 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.
There are some C programmers that do; there are some that don't. In some
fields, the fraction of C programmers doing so is much higher than in other
fields. My intention was to suggest that at least in some fields the number
of programmers who almost always use "uint8_t" instead of "unsigned char"
is sufficient that doing so could hardly be considered unusual. I did not
mean to imply that use of "uint8_t" is so prevalent that use of "unsigned
char" is unusual. Rather, I'd say that both usages are common.
I would suggest that when specifying a structure, something like:
struct foo {
uint16_t length;
uint8_t id[8];
uint32_t x,y;
}
seems a bit easier to read than:
struct foo {
uint16_t length;
unsigned char id[8];
uint32_t x,y;
}
How would you suggest the above should be formatted?
> Would your position be the same if C had made "byte" a keyword
> equivalent to or replacing "unsigned char"?
I think it would have been helpful for C to distinguish a type used for
holding memory values one used for holding numbers; see my note above.
Many of my complaints about aliasing would have been solved if C had
defined more types [which implementations may or may not distinguish]:
1. A memory-storage-unit type which works like the type defined above,
and may be used read or write data of any type when used as above.
2. Types which, if defined, would work like the above for suitably-
aligned groups of storage locations, but have the same constraints on
arithmetic.
3. Types which, if defined, could be used to read or write a pointer to...
a. Any kind of structure
b. Any kind of union
c. Any kind of structure or union
d. Any kind of data
e. Any kind of function
f. Any kind of data or function
Some implementations could easily support all types; some would be unable
to support any but the first. Systems in which all struct pointers and all
union pointers have the same representation would be expected to define
type 3c above; applications would only be expected to use 3a or 3b if they
had a particular need to run on implementations that were unable to support
type 3c.
I'd suggest that even today, C might benefit from having types such as
those defined above. What would you think?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-16 12:45 -0700 |
| Message-ID | <lnzizi4mxr.fsf@kst-u.example.com> |
| In reply to | #73044 |
supercat@casperkitty.com writes:
> On Friday, October 16, 2015 at 10:50:28 AM UTC-5, Keith Thompson wrote:
>> 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 "?
>
> I think certain things would be cleaner conceptually if C had a type which
> represented underlying storage, with the following characteristics:
>
> 1. Conversion of the type to "int" or "long" and back is guaranteed to be a
> round trip **if no arithmetic is done on the "int" or "long" value**.
What for? You can convert an unsigned char value to unsigned int if you
like.
> 2. Performing arithmetic on the "int" or "long" value would either turn it
> into a number using rules an implementation may or may not opt to
> specify, or trigger a trap whose *existence* would be Implementation-
> Defined but whose consequences need not me. Further, even if further
> arithmetic yields the same number as was first yielded by the conversion,
> conversion of that number back to the original "raw byte" type could
> yield a result different from the original provided the implementation
> documents that possibility.
I fail to see the purpose of these requirements.
> Most implementations would opt to specify the how the conversions work, but
> it is not hard to imagine useful implementations which cannot support all of
> the semantics required of "unsigned char" but could support the semantics of
> a type as described above (among other things, consider the following
> program (assuming "unsigned long long" is at least as large as uintptr_t)
You think there are implementations that cannot support all the semantic
required of unsigned char?
> void main(void)
Seriously??
> {
> int i;
> long long l;
> unsigned char *p;
> for (i=0; i<100000000; i++)
> {
> p = malloc(1);
> *p = getchar();
> l = (long long)p;
> printf("%llX ",l);
> }
> printf("\n\nNow type the pointer: "); flush(stdout);
> scanf("%llX", &l);
> p = (unsigned char*)(uintptr_t)l;
> printf("The char was [%c]\n", *p);
> }
Sorry, I don't see the point of this -- even if you were using
[u]intptr_t rather than long long.
[snip]
>> > 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 C as originally envisioned, memcpy() accepted arguments of type char*
> and compared the memory locations identified thereby. Such a comparison
> would be meaningful on a system where char is either unsigned or is a
> two's-complement signed value. It would be pretty much meaningless on
> any system where char is a one's-complement or sign-magnitude value.
Which is why memcpy() now takes arguments of type void* and treats
the copied memory as an array of unsigned char.
> Is there any evidence that ANSI ever intended to allow for machines where
> performing the indicated operations on type "char*" would not be meaningful?
Yes, there is. ANSI defined a language in which object representations
are described in terms of arrays of unsigned char *for exactly that
reason*.
[snip]
> I'd suggest that even today, C might benefit from having types such as
> those defined above. What would you think?
I think you're suggesting adding a lot of complexity to the language.
I was just making what was intended to be one simple point: C defines
object representations in terms of arrays of unsigned char, and using
plain char instead makes things conceptually more difficult with no
corresponding benefit. Sure, you could patch over those difficulties by
making changes to the language, but what's the point?
--
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"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-16 13:56 -0700 |
| Message-ID | <4a3b5611-82ad-42d5-9e2f-fe4dbd22dfb1@googlegroups.com> |
| In reply to | #73062 |
On Friday, October 16, 2015 at 2:45:47 PM UTC-5, Keith Thompson wrote: > You think there are implementations that cannot support all the semantic > required of unsigned char? I can imagine potentially useful (non-conforming) implementations where that would be the case. Suppose, for example, that one would like to have an implementation that will make it 100% impossible for code to create a pointer to an object via illegitimate means, even those which would require "getting lucky" [e.g. generating a random address and seeing if it hits anything useful], and which would offer 100%-reliable tracing garbage collection. Such a system requires that pointers/references be fundamentally different from numbers. One could work such a thing into the C language if each data type were capable of holding either a pointer or a number, but kept track of which it held. Such semantics are not achievable, however, if an implementation is required to allow numbers to be turned into pointers. > > void main(void) > > Seriously?? Sorry--brain glitch. I do a lot of embedded work where that's legal and where return from main is Undefined Behavior. > Sorry, I don't see the point of this -- even if you were using > [u]intptr_t rather than long long. The type uintptr_t is not guaranteed to exist even when a "long long" would be large enough to represent every pointer value. A VM like Java or .NET needs to be able to identify every reference that exists or will ever exist to every object. In the above code, the pointer to each allocated object immediately gets overwritten with the address of the next one, but if someone were to type in one of the addresses which had been printed a pointer to that object would get re-created. There is no means by which the compiler would be able to tell which pointer, if any, is going to spring back into existence. Under an implementation such as I described, it would be possible for the system to perform a tracing garbage collection, since once the last pointer to an object gets overwritten there is no means by which any live references to that object could ever come back into existence. But for that to work, the system must be able to know that it's impossible to create pointers from numbers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-16 14:29 -0700 |
| Message-ID | <ln7fmm4i46.fsf@kst-u.example.com> |
| In reply to | #73077 |
supercat@casperkitty.com writes:
> On Friday, October 16, 2015 at 2:45:47 PM UTC-5, Keith Thompson wrote:
[...]
>> Sorry, I don't see the point of this -- even if you were using
>> [u]intptr_t rather than long long.
>
> The type uintptr_t is not guaranteed to exist even when a "long long" would
> be large enough to represent every pointer value.
True, all the standard says beyond the requirements is "These types are
optional". But I can't think of any reason an implementation wouldn't
define uintptr_t if it could -- and I certainly can't think of a reason
to use long long when uintptr_t would be more appropriate (unless you
have to worry about pre-C99 compilers).
[...]
--
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"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-16 14:52 -0700 |
| Message-ID | <d0980808-4385-4d7f-bd9b-44e10e0976d1@googlegroups.com> |
| In reply to | #73086 |
On Friday, October 16, 2015 at 4:29:53 PM UTC-5, Keith Thompson wrote: > True, all the standard says beyond the requirements is "These types are > optional". But I can't think of any reason an implementation wouldn't > define uintptr_t if it could -- and I certainly can't think of a reason > to use long long when uintptr_t would be more appropriate (unless you > have to worry about pre-C99 compilers). I thought using "%lld" for printf/scanf specifiers would be more understandable than PRIXPTR and SCNxPTR. Besides, my main point is that both Java and .NET find very practical and useful a fundamental rule that forbids code from creating references out of thin air. The present rules of C require that implementations allow programmers to create pointers out of thin air. While there many situations, especially in the embedded systems world, where the ability to create pointers out of thin air is useful, there are many situations where it serves no legitimate purpose and where security would be enhanced by forbidding it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-16 15:32 -0700 |
| Message-ID | <lntwpq30nf.fsf@kst-u.example.com> |
| In reply to | #73095 |
supercat@casperkitty.com writes:
> On Friday, October 16, 2015 at 4:29:53 PM UTC-5, Keith Thompson wrote:
>> True, all the standard says beyond the requirements is "These types are
>> optional". But I can't think of any reason an implementation wouldn't
>> define uintptr_t if it could -- and I certainly can't think of a reason
>> to use long long when uintptr_t would be more appropriate (unless you
>> have to worry about pre-C99 compilers).
>
> I thought using "%lld" for printf/scanf specifiers would be more understandable
> than PRIXPTR and SCNxPTR.
I didn't know what was your motivation. It's not how I'd deal with the
issue, but ... whatever.
> Besides, my main point is that both Java and .NET find very practical and
> useful a fundamental rule that forbids code from creating references out
> of thin air. The present rules of C require that implementations allow
> programmers to create pointers out of thin air.
>
> While there many situations, especially in the embedded systems world,
> where the ability to create pointers out of thin air is useful, there are
> many situations where it serves no legitimate purpose and where security
> would be enhanced by forbidding it.
So you want the strict aliasing rules to be more stringent?
--
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"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-16 15:59 -0700 |
| Message-ID | <bd2056db-81e2-4e6b-bcd5-8553e73661f7@googlegroups.com> |
| In reply to | #73105 |
On Friday, October 16, 2015 at 5:32:27 PM UTC-5, Keith Thompson wrote: > So you want the strict aliasing rules to be more stringent? I would allow implementations to impose stricter rules than exist, but would require that implementations to define certain macros to indicate what rules they are applying, and would ensure that in cases where it would be possible for an implementation to allow code to make exceptions to its general rule, there should be standardized means of doing so. The rules of Java are more strict than I'd like, but they (and those of .NET) are in some important respects less strict than those of C89. For example, in Java or .NET, if one has a function that expects a parameter of type "Animal[]", one may pass it a "SiameseCat[]" (note that each item of the array is a reference [roughly equivalent to a pointer], rather than holding an actual instance]. The original specifications for C made clear an intention that it be possible to define structures with common initial field sequences and have code which only needs to use the common members use pointers of all such structure types interchangeably, and while the aliasing rules honor that intention with single-indirect pointers, they do not honor it with arrays of pointers.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-17 00:03 +0000 |
| Message-ID | <mvs393$rps$1@speranza.aioe.org> |
| In reply to | #73038 |
Keith Thompson <kst-u@mib.org> wrote: > supercat@casperkitty.com writes: (snip) >> 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. The four that I see are all twos complement, including the rare today Honeywell 6000. The CDC 60 bit machines were somewhat popular in the K&R years, and are ones complement. The usual character set uses six bits per character, though I believe that there is a set with mixed six and 12 bit characters. I have never used a C compiler on these machines. Unisys still builds and sells ones complement machines, and I believe has a C compiler. It might be that the compiler does not properly handle the unsigned types in C. > 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. (snip) > I don't > think that C programmers in general avoid typing unsigned char, > which was the specific claim you made. I certainly don't. When I am writing a program for one-time use, on a machine where I know it won't cause problems, I might forget to type unsigned. But when I want to cast for arguments to memcpy(), I always remember it. > 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"? By the way, Java has a signed 8 bit (byte), and unsigned 16 bit (char) type. I believe that some DEC Fortran compilers have a non-standard signed byte type. -- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-17 00:08 -0700 |
| Message-ID | <1ea1ff70-646b-4228-9cff-fac2b5548285@googlegroups.com> |
| In reply to | #73115 |
On Friday, October 16, 2015 at 7:03:55 PM UTC-5, glen herrmannsfeldt wrote: > Unisys still builds and sells ones complement machines, and I believe > has a C compiler. It might be that the compiler does not properly handle > the unsigned types in C. Unsigned types are allowed to have more padding than their signed equivalents, such that INT_MAX and UINT_MAX would be equal. I would expect that many one's-complement machines probably do that. > By the way, Java has a signed 8 bit (byte), and unsigned 16 bit > (char) type. Gosling decided against having any unsigned types [though he ended up making an exception for 'char'] because of the confusion they cause in C; he completely failed to notice that in Pascal, the Byte type is signed but Integer is unsigned, and that combination works really well. All of the quirkiness with unsigned types in C stems from the fact that unsigned types larger than "int" do not get promoted to a signed type, but that wouldn't have been an issue with types for 8-bit and 16-bit whole numbers (the 'char' type is aimed more at use for representing UCS-2 characters than whole numbers).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-17 15:26 -0700 |
| Message-ID | <lna8rh2kty.fsf@kst-u.example.com> |
| In reply to | #73141 |
supercat@casperkitty.com writes:
> On Friday, October 16, 2015 at 7:03:55 PM UTC-5, glen herrmannsfeldt wrote:
>> Unisys still builds and sells ones complement machines, and I believe
>> has a C compiler. It might be that the compiler does not properly handle
>> the unsigned types in C.
>
> Unsigned types are allowed to have more padding than their signed
> equivalents, such that INT_MAX and UINT_MAX would be equal.
Yes.
> I would
> expect that many one's-complement machines probably do that.
Why would you expect that? I wouldn't expect a one's-complement
implementation to waste a bit and sacrifice half the range of
a signed type. (Then again, I've never used a one's-complement
system.)
>> By the way, Java has a signed 8 bit (byte), and unsigned 16 bit
>> (char) type.
>
> Gosling decided against having any unsigned types [though he ended up
> making an exception for 'char'] because of the confusion they cause in C;
> he completely failed to notice that in Pascal, the Byte type is signed but
> Integer is unsigned, and that combination works really well.
I presume that was a typo. Integer is signed in Pascal. Standard
Pascal doesn't have a Byte type, though some dialects support it
(and Free Pascal appears to treat it as unsigned).
Assuming that Gosling "completely failed to notice" something is a bit
arrogant, don't you think? He merely reached a different conclusion
than you would have.
[...]
--
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"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-17 16:38 -0700 |
| Message-ID | <3aaa8f39-f681-4cc0-9cf5-36ef38350b98@googlegroups.com> |
| In reply to | #73162 |
On Saturday, October 17, 2015 at 5:26:30 PM UTC-5, Keith Thompson wrote: > supercat writes: > > Gosling decided against having any unsigned types [though he ended up > > making an exception for 'char'] because of the confusion they cause in C; > > he completely failed to notice that in Pascal, the Byte type is signed but > > Integer is unsigned, and that combination works really well. > > I presume that was a typo. Integer is signed in Pascal. Standard > Pascal doesn't have a Byte type, though some dialects support it > (and Free Pascal appears to treat it as unsigned). > > Assuming that Gosling "completely failed to notice" something is a bit > arrogant, don't you think? He merely reached a different conclusion > than you would have. I forget Gosling's exact statement when asked why he didn't include unsigned numeric types, but my interpretation was that he'd never seen them to be anything but trouble. It's possible I read into that more than Gosling intended to say, but I would think that if he was familiar with languages in which smaller unsigned types existed and did not pose any problem he would not have made the statement he did.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-16 23:43 +0000 |
| Message-ID | <mvs22t$osc$1@speranza.aioe.org> |
| In reply to | #73029 |
supercat@casperkitty.com wrote: > 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. I wonder why signed char exists at all. I suspect that there is some system that makes it hard to process unsigned char data. That is, where char at sign extended on promotion to larger types. With extra instructions, (presumably used for actual (unsigned char), it does do the conversion. That saves code space and execution time, for a rarely occuring (on ASCII systems) negative char values. > In a two's-complement system, this conversion is > representation-preserving. In other systems, it is not. > 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. Unlike the last time a K&R question came up, my K&R1 is nearby. K&R doesn't say all that much about char. "A single byte, capable of holding one character in the local character set." And a table of bit widths for four machines: PDP-11, Honeywell 6000, IBM 370, and Interdata 8/32, with bit width 8, 9, 8, 8, respectively. Finally, in appendix A: "Whether sign extension occurs for characters is machine dependent, but it is guaranteed that a member of the standard character set is non-negative. Of the machines treated in this manual, only the PDP-11 sign extends." Look like the PDP-11 is to blame. I is all DECs fault. >> 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". -- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-16 23:57 -0700 |
| Message-ID | <256ffb24-2a28-490d-88a3-07655412daa7@googlegroups.com> |
| In reply to | #73111 |
On Friday, October 16, 2015 at 6:43:38 PM UTC-5, glen herrmannsfeldt wrote: > I wonder why signed char exists at all. I suspect that there is some > system that makes it hard to process unsigned char data. That is, where > char at sign extended on promotion to larger types. With extra > instructions, (presumably used for actual (unsigned char), it does > do the conversion. That saves code space and execution time, for a > rarely occuring (on ASCII systems) negative char values. There are many situations where 8-bit signed values are useful. Further, I believe INT_MAX is supposed to be at least equal to CHAR_MAX, which would imply that on systems where sizeof (int) is 1, "char" would have to be signed.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-17 14:50 -0700 |
| Message-ID | <lnio652mid.fsf@kst-u.example.com> |
| In reply to | #73140 |
supercat@casperkitty.com writes:
> On Friday, October 16, 2015 at 6:43:38 PM UTC-5, glen herrmannsfeldt wrote:
>> I wonder why signed char exists at all. I suspect that there is some
>> system that makes it hard to process unsigned char data. That is, where
>> char at sign extended on promotion to larger types. With extra
>> instructions, (presumably used for actual (unsigned char), it does
>> do the conversion. That saves code space and execution time, for a
>> rarely occuring (on ASCII systems) negative char values.
>
> There are many situations where 8-bit signed values are useful. Further, I
> believe INT_MAX is supposed to be at least equal to CHAR_MAX, which would
> imply that on systems where sizeof (int) is 1, "char" would have to be
> signed.
There is no such requirement. Systems with CHAR_MAX > INT_MAX would
have some difficulties with stdio (in particular a program couldn't
distinguish between EOF and a valid character without checking the
results of feof() and ferror()), but they're not prohibited.
--
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"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-18 10:55 +1300 |
| Message-ID | <d8fufeFrihmU2@mid.individual.net> |
| In reply to | #73158 |
Keith Thompson wrote: > supercat@casperkitty.com writes: >> On Friday, October 16, 2015 at 6:43:38 PM UTC-5, glen herrmannsfeldt wrote: >>> I wonder why signed char exists at all. I suspect that there is some >>> system that makes it hard to process unsigned char data. That is, where >>> char at sign extended on promotion to larger types. With extra >>> instructions, (presumably used for actual (unsigned char), it does >>> do the conversion. That saves code space and execution time, for a >>> rarely occuring (on ASCII systems) negative char values. >> >> There are many situations where 8-bit signed values are useful. Further, I >> believe INT_MAX is supposed to be at least equal to CHAR_MAX, which would >> imply that on systems where sizeof (int) is 1, "char" would have to be >> signed. > > There is no such requirement. Systems with CHAR_MAX > INT_MAX would > have some difficulties with stdio (in particular a program couldn't > distinguish between EOF and a valid character without checking the > results of feof() and ferror()), but they're not prohibited. Given sizeof(char) is one, what would sizeof(int) be on such a system? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-17 18:24 -0400 |
| Message-ID | <5622CAAF.3030904@verizon.net> |
| In reply to | #73160 |
On 10/17/2015 05:55 PM, Ian Collins wrote: > Keith Thompson wrote: >> supercat@casperkitty.com writes: >>> On Friday, October 16, 2015 at 6:43:38 PM UTC-5, glen herrmannsfeldt wrote: >>>> I wonder why signed char exists at all. I suspect that there is some >>>> system that makes it hard to process unsigned char data. That is, where >>>> char at sign extended on promotion to larger types. With extra >>>> instructions, (presumably used for actual (unsigned char), it does >>>> do the conversion. That saves code space and execution time, for a >>>> rarely occuring (on ASCII systems) negative char values. >>> >>> There are many situations where 8-bit signed values are useful. Further, I >>> believe INT_MAX is supposed to be at least equal to CHAR_MAX, which would Note: INT_MAX >= SCHAR_MAX is mandatory (6.2.5p8 combined with 6.3.1.1p1). Therefore, if INT_MAX < CHAR_MAX, then CHAR_MAX == UCHAR_MAX, and CHAR_MIN == 0. >>> imply that on systems where sizeof (int) is 1, "char" would have to be >>> signed. >> >> There is no such requirement. Systems with CHAR_MAX > INT_MAX would >> have some difficulties with stdio (in particular a program couldn't >> distinguish between EOF and a valid character without checking the >> results of feof() and ferror()), but they're not prohibited. > > Given sizeof(char) is one, what would sizeof(int) be on such a system? sizeof(int) >=1, with sizeof(int)==1 being by far the most likely possibility, since otherwise it would have to contain at least (sizeof(int)-1)*CHAR_BIT padding bits. And on such a system, CHAR_BIT >=16, so that's a lot of padding bits.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-10-17 18:39 -0400 |
| Message-ID | <17AUx.54254$756.53725@fx20.iad> |
| In reply to | #73160 |
On 10/17/15 5:55 PM, Ian Collins wrote: > Keith Thompson wrote: >> supercat@casperkitty.com writes: >>> On Friday, October 16, 2015 at 6:43:38 PM UTC-5, glen herrmannsfeldt >>> wrote: >>>> I wonder why signed char exists at all. I suspect that there is some >>>> system that makes it hard to process unsigned char data. That is, where >>>> char at sign extended on promotion to larger types. With extra >>>> instructions, (presumably used for actual (unsigned char), it does >>>> do the conversion. That saves code space and execution time, for a >>>> rarely occuring (on ASCII systems) negative char values. >>> >>> There are many situations where 8-bit signed values are useful. >>> Further, I >>> believe INT_MAX is supposed to be at least equal to CHAR_MAX, which >>> would >>> imply that on systems where sizeof (int) is 1, "char" would have to be >>> signed. >> >> There is no such requirement. Systems with CHAR_MAX > INT_MAX would >> have some difficulties with stdio (in particular a program couldn't >> distinguish between EOF and a valid character without checking the >> results of feof() and ferror()), but they're not prohibited. > > Given sizeof(char) is one, what would sizeof(int) be on such a system? > 1 The case being described is char is unsigned, so CHAR_MAX == UINT_MAX. Note that the problem with distinguishing EOF and a valid character doesn't require CHAR_MAX > INT_MAX, as (as far as I know) there is no requirement that all valid characters be positive, only those characters in the basic character set be positive, others are allowed to be negative, which is why you need to cast char to unsigned char when calling the various isxxx classification functions with char values (unless you know char is unsigned).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-17 18:56 -0400 |
| Message-ID | <5622D211.4000902@verizon.net> |
| In reply to | #73164 |
On 10/17/2015 06:39 PM, Richard Damon wrote: ... > Note that the problem with distinguishing EOF and a valid character > doesn't require CHAR_MAX > INT_MAX, as (as far as I know) there is no > requirement that all valid characters be positive, only those characters > in the basic character set be positive, others are allowed to be > negative, which is why you need to cast char to unsigned char when > calling the various isxxx classification functions with char values > (unless you know char is unsigned). Correct. It's not the case that EOF being a value that could be returned by a successful call to fgetc() requires CHAR_MAX > INT_MAX; CHAR_MIN < 0 is sufficient to allow that. The inference goes the other way: UCHAR_MAX >= INT_MAX is the condition which guarantees that if fputc() is used to write EOF to a binary stream, fgetc() will necessarily return EOF if it successfully reads that byte. This follows from 7.21.2p3 combined with the definitions of the behavior of fputc() and fgetc().
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-17 16:17 -0700 |
| Message-ID | <lnsi5913wj.fsf@kst-u.example.com> |
| In reply to | #73167 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 10/17/2015 06:39 PM, Richard Damon wrote:
> ...
>> Note that the problem with distinguishing EOF and a valid character
>> doesn't require CHAR_MAX > INT_MAX, as (as far as I know) there is no
>> requirement that all valid characters be positive, only those characters
>> in the basic character set be positive, others are allowed to be
>> negative, which is why you need to cast char to unsigned char when
>> calling the various isxxx classification functions with char values
>> (unless you know char is unsigned).
>
> Correct. It's not the case that EOF being a value that could be returned
> by a successful call to fgetc() requires CHAR_MAX > INT_MAX; CHAR_MIN <
> 0 is sufficient to allow that.
The systems I use meet that requirement:
EOF == -1
CHAR_MIN == -128
CHAR_MAX == +127
INT_MIN == -2147483648
INT_MAX == +2147483647
fgetc() returns -1 on end-of-file or error, and distinct values from 0
to 255 for any possible valid input characters. No conflict is possible
as long as I don't discard information by converting the result to char
without checking it first.
I suspect that what you meant doesn't match my understanding of what you
wrote, but I don't know where the disconnect is.
[...]
--
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"
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web