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 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-18 11:46 -0400 |
| Message-ID | <5623BEDE.400@verizon.net> |
| In reply to | #73170 |
On 10/17/2015 07:17 PM, Keith Thompson wrote: > 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. No, I just got confused. Reviewing the logic again, I see that UCHAR_MAX > INT_MAX is both necessary and sufficient for a successful call fputc(EOF) to a binary stream to cause a corresponding successful call to fgetc() to return EOF.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-10-17 19:44 -0400 |
| Message-ID | <c3BUx.54255$756.52863@fx20.iad> |
| In reply to | #73167 |
On 10/17/15 6:56 PM, James Kuyper wrote: > 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(). > You need UCHAR_MAX > INT_MAX. If UCHAR_MAX == INT_MAX then every char value will return a positive value, so EOF being negative is unique. Now, UCHAR_MAX == INT_MAX would be a strange setup. Something like a 16 bit character, and int uses the the 16 value bits, plus a 16 bit 'byte' for the sign 'bit'.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-17 16:48 -0700 |
| Message-ID | <c226aca3-d787-446c-a2c7-64858196b90b@googlegroups.com> |
| In reply to | #73174 |
On Saturday, October 17, 2015 at 6:44:16 PM UTC-5, Richard Damon wrote:
> Now, UCHAR_MAX == INT_MAX would be a strange setup. Something like a 16
> bit character, and int uses the the 16 value bits, plus a 16 bit 'byte'
> for the sign 'bit'.
As I've noted elsewhere, such a platform would have the fun property that
the code:
unsigned char ch=-1;
ch++;
would invoke Undefined Behavior on the increment.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-18 01:14 +0100 |
| Message-ID | <mvuo4s$b9q$1@dont-email.me> |
| In reply to | #73176 |
On 18/10/15 00:48, supercat@casperkitty.com wrote: > On Saturday, October 17, 2015 at 6:44:16 PM UTC-5, Richard Damon wrote: >> Now, UCHAR_MAX == INT_MAX would be a strange setup. Something like a 16 >> bit character, and int uses the the 16 value bits, plus a 16 bit 'byte' >> for the sign 'bit'. > > As I've noted elsewhere, such a platform would have the fun property that > the code: > > unsigned char ch=-1; > ch++; > > would invoke Undefined Behavior on the increment. Could you please explain why you think this? I ask because I believe that you're mistaken, but I'm prepared to be proved wrong. Here's why I believe you're mistaken: 6.2.5(9): A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type. If I'm wrong to believe you're mistaken, presumably it has to do with integer promotions, but having taken a quick look at the rather recondite rules for such promotions I am left none the wiser. (Slightly better-informed, but still none the wiser.) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-10-17 20:22 -0400 |
| Message-ID | <OCBUx.68268$5N3.52032@fx17.iad> |
| In reply to | #73177 |
On 10/17/15 8:14 PM, Richard Heathfield wrote: > On 18/10/15 00:48, supercat@casperkitty.com wrote: >> On Saturday, October 17, 2015 at 6:44:16 PM UTC-5, Richard Damon wrote: >>> Now, UCHAR_MAX == INT_MAX would be a strange setup. Something like a 16 >>> bit character, and int uses the the 16 value bits, plus a 16 bit 'byte' >>> for the sign 'bit'. >> >> As I've noted elsewhere, such a platform would have the fun property that >> the code: >> >> unsigned char ch=-1; >> ch++; >> >> would invoke Undefined Behavior on the increment. > > Could you please explain why you think this? I ask because I believe > that you're mistaken, but I'm prepared to be proved wrong. > > Here's why I believe you're mistaken: > > 6.2.5(9): A computation involving unsigned operands can never overflow, > because a result that cannot be represented by the resulting unsigned > integer type is reduced modulo the number that is one greater than the > largest value that can be represented by the resulting type. > > If I'm wrong to believe you're mistaken, presumably it has to do with > integer promotions, but having taken a quick look at the rather > recondite rules for such promotions I am left none the wiser. (Slightly > better-informed, but still none the wiser.) > I can see the argument that ch = -1 is the same as ch = 65535 (since ch is unsigned) ch++ is the same as ch = ch + 1 and ch being unsigned in this case would promote to int, and int 65535+1 overflows. The weakness is that I am not sure that ++ does the usual arithmetic conversions for the increment operation (it would for the value returned for the expression).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-17 17:26 -0700 |
| Message-ID | <473cd3ca-4387-482f-b8f7-7a9e094b2468@googlegroups.com> |
| In reply to | #73177 |
On Saturday, October 17, 2015 at 7:14:33 PM UTC-5, Richard Heathfield wrote: > On 18/10/15 00:48, supercat wrote: > > As I've noted elsewhere, such a platform would have the fun property that > > the code: > > > > unsigned char ch=-1; > > ch++; > > > > would invoke Undefined Behavior on the increment. > > Could you please explain why you think this? I ask because I believe > that you're mistaken, but I'm prepared to be proved wrong. ... > If I'm wrong to believe you're mistaken, presumably it has to do with > integer promotions, but having taken a quick look at the rather > recondite rules for such promotions I am left none the wiser. (Slightly > better-informed, but still none the wiser.) On systems where UCHAR_MAX is less than or equal to INT_MAX, unsigned char will promote to signed int. Setting ch to -1 will store the value UCHAR_MAX to it. If that is in turn equal to INT_MAX, then the increment will act upon INT_MAX, thus invoking Undefined Behavior.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-18 01:44 +0100 |
| Message-ID | <mvupso$flj$1@dont-email.me> |
| In reply to | #73179 |
On 18/10/15 01:26, supercat@casperkitty.com wrote: > On Saturday, October 17, 2015 at 7:14:33 PM UTC-5, Richard Heathfield wrote: >> On 18/10/15 00:48, supercat wrote: >>> As I've noted elsewhere, such a platform would have the fun property that >>> the code: >>> >>> unsigned char ch=-1; >>> ch++; >>> >>> would invoke Undefined Behavior on the increment. >> >> Could you please explain why you think this? I ask because I believe >> that you're mistaken, but I'm prepared to be proved wrong. > ... >> If I'm wrong to believe you're mistaken, presumably it has to do with >> integer promotions, but having taken a quick look at the rather >> recondite rules for such promotions I am left none the wiser. (Slightly >> better-informed, but still none the wiser.) > > On systems where UCHAR_MAX is less than or equal to INT_MAX, unsigned > char will promote to signed int. Setting ch to -1 will store the > value UCHAR_MAX to it. If that is in turn equal to INT_MAX, then > the increment will act upon INT_MAX, thus invoking Undefined Behavior. The semantics of the postfix++ operator: "The result of the postfix ++ operator is the value of the operand. As a side effect, the value of the operand object is incremented (that is, the value 1 of the appropriate type is added to it)." Since we have a very strong guarantee against overflow for unsigned integer types, it seems quite bizarre that there could be overflow. Indeed, the Standard forbids it. So we would appear to have a situation where overflow is both mandatory and prohibited. Does this constitute a defect in the Standard? I don't know. I am yet to be convinced by your claim. That doesn't mean I am sure you are wrong. It means I would like to see a more rigorous analysis of the code with reference to the Standard. Specifically, by what licence (chapter and verse, please) do the integer promotions trump the guarantee we are given about unsigned integer types? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-17 20:09 -0700 |
| Message-ID | <lnd1wc27p5.fsf@kst-u.example.com> |
| In reply to | #73180 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 18/10/15 01:26, supercat@casperkitty.com wrote:
>> On Saturday, October 17, 2015 at 7:14:33 PM UTC-5, Richard Heathfield wrote:
>>> On 18/10/15 00:48, supercat wrote:
>>>> As I've noted elsewhere, such a platform would have the fun property that
>>>> the code:
>>>>
>>>> unsigned char ch=-1;
>>>> ch++;
>>>>
>>>> would invoke Undefined Behavior on the increment.
>>>
>>> Could you please explain why you think this? I ask because I believe
>>> that you're mistaken, but I'm prepared to be proved wrong.
>> ...
>>> If I'm wrong to believe you're mistaken, presumably it has to do with
>>> integer promotions, but having taken a quick look at the rather
>>> recondite rules for such promotions I am left none the wiser. (Slightly
>>> better-informed, but still none the wiser.)
>>
>> On systems where UCHAR_MAX is less than or equal to INT_MAX, unsigned
>> char will promote to signed int. Setting ch to -1 will store the
>> value UCHAR_MAX to it. If that is in turn equal to INT_MAX, then
>> the increment will act upon INT_MAX, thus invoking Undefined Behavior.
>
> The semantics of the postfix++ operator:
>
> "The result of the postfix ++ operator is the value of the operand. As a
> side effect, the value of the operand object is incremented (that is,
> the value 1 of the appropriate type is added to it)."
>
> Since we have a very strong guarantee against overflow for unsigned
> integer types, it seems quite bizarre that there could be overflow.
> Indeed, the Standard forbids it. So we would appear to have a situation
> where overflow is both mandatory and prohibited.
>
> Does this constitute a defect in the Standard? I don't know. I am yet to
> be convinced by your claim. That doesn't mean I am sure you are wrong.
> It means I would like to see a more rigorous analysis of the code with
> reference to the Standard. Specifically, by what licence (chapter and
> verse, please) do the integer promotions trump the guarantee we are
> given about unsigned integer types?
By specifying that the postfix ++ operator adds 1 to its operand, the
standard in effect says that
ch++
does the equivalent of
ch = ch + 1
(plus whatever else it needs to do to yield the original value of ch).
It also says, "See the discussions of additive operators and compound
assignment for information on constraints, types, and conversions and
the effects of operations on pointers."
The case for ++ch is perhaps a bit clearer, since the standard
explicitly says that
The expression ++E is equivalent to (E+=1).
I agree that it's bizarre, but it's not inconsistent.
--
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-18 11:24 -0700 |
| Message-ID | <5f9b205b-a13a-43b7-b9b7-b91995426386@googlegroups.com> |
| In reply to | #73180 |
On Saturday, October 17, 2015 at 7:44:16 PM UTC-5, Richard Heathfield wrote:
> Does this constitute a defect in the Standard? I don't know. I am yet to
> be convinced by your claim. That doesn't mean I am sure you are wrong.
> It means I would like to see a more rigorous analysis of the code with
> reference to the Standard. Specifically, by what licence (chapter and
> verse, please) do the integer promotions trump the guarantee we are
> given about unsigned integer types?
The Standard does not recognize the concept of applying operators to types
smaller than "int". As such, although operators applied to unsigned operands
will behave in the indicated fashion, unsigned values shorter than "int" get
promoted before the operators are applied.
I would regard as a defect in the Standard the fact that code like:
unsigned short mul_mod_65536(unsigned short a, unsigned short b)
{
return a*b;
}
has no defined behaviors which on any platform which differ from those where
UINT_MAX==USHRT_MAX, and has fully-defined behaviors on all platforms where
either UINT_MAX==USHRT_MAX or UINT_MAX/USHRT_MAX > 2u*USHRT_MAX, but will
invoke Undefined Behavior on platforms where UINT_MAX is larger than
USHRT_MAX but not large enough to prevent overflow.
I suspect that the issue was ignored because until recently even compilers
which were not required to yield the same behavior in all cases would almost
never have had any reason to do otherwise. Indeed, I'm curious if there have
ever been ANY compilers within the first 25 years of C's invention, given
the function:
int foo(a,b)
int a,b;
{
unsigned short aa,bb,cc;
aa=a; bb=b; cc=aa*bb;
return cc;
}
calling foo(-3,-3) would have done anything other than yield 9.
A simple resolution would be to require that if the result of a bitwise,
additive, multiplicative, or left-shift operator is cast or coerced to an
unsigned type shorter than "int", the result must be as though operands
were likewise coerced and the operation performed on that type. A
compiler could honor such a requirement either by passing type information
into expressions, or by simply performing arithmetic in a fashion that
would always yield a result which, when cast or coerced to the smaller
type, would yield the same value as would have been achieved by performing
the operation on that type.
An alternative approach would be to have the language define a family of
unsigned types which are specified as never implicitly promoting to any
signed type which does not rank strictly above "unsigned int" [while it
would be semantically better to have a type which would not implicitly
promote to any larger type, period, allowing promotion to types larger
than "int" would mean that on a platform where "int" is 32 bits or smaller,
"uwrap32_t" could legitimately be aliased to "uint32_t", thus allowing
code to use that type on existing 32-bit compilers while ensuring that
the code won't be misinterpreted if moved to a compiler where "int" is
64 bits.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-19 04:42 +0000 |
| Message-ID | <n01sc0$om0$1@speranza.aioe.org> |
| In reply to | #73222 |
supercat@casperkitty.com wrote:
(snip)
> The Standard does not recognize the concept of applying operators to types
> smaller than "int". As such, although operators applied to unsigned operands
> will behave in the indicated fashion, unsigned values shorter than "int" get
> promoted before the operators are applied.
> I would regard as a defect in the Standard the fact that code like:
> unsigned short mul_mod_65536(unsigned short a, unsigned short b)
> {
> return a*b;
> }
> has no defined behaviors which on any platform which differ from those where
> UINT_MAX==USHRT_MAX, and has fully-defined behaviors on all platforms where
> either UINT_MAX==USHRT_MAX or UINT_MAX/USHRT_MAX > 2u*USHRT_MAX, but will
> invoke Undefined Behavior on platforms where UINT_MAX is larger than
> USHRT_MAX but not large enough to prevent overflow.
I would say don't do that.
For one, you are assuming short is 16 bits.
> I suspect that the issue was ignored because until recently even compilers
> which were not required to yield the same behavior in all cases would almost
> never have had any reason to do otherwise. Indeed, I'm curious if there have
> ever been ANY compilers within the first 25 years of C's invention, given
> the function:
> int foo(a,b)
> int a,b;
> {
> unsigned short aa,bb,cc;
> aa=a; bb=b; cc=aa*bb;
> return cc;
> }
> calling foo(-3,-3) would have done anything other than yield 9.
But why would you want to do that?
But if you did, you should well understant the C promotion rules
and the effect of them in the case of overflow.
> A simple resolution would be to require that if the result of a bitwise,
> additive, multiplicative, or left-shift operator is cast or coerced to an
> unsigned type shorter than "int", the result must be as though operands
> were likewise coerced and the operation performed on that type. A
> compiler could honor such a requirement either by passing type information
> into expressions, or by simply performing arithmetic in a fashion that
> would always yield a result which, when cast or coerced to the smaller
> type, would yield the same value as would have been achieved by performing
> the operation on that type.
Personally, I believe that the promotion rules more often give the
desired answer than not, but otherwise they are something that C
programmers need to learn.
> An alternative approach would be to have the language define a family of
> unsigned types which are specified as never implicitly promoting to any
> signed type which does not rank strictly above "unsigned int" [while it
> would be semantically better to have a type which would not implicitly
> promote to any larger type, period, allowing promotion to types larger
> than "int" would mean that on a platform where "int" is 32 bits or smaller,
> "uwrap32_t" could legitimately be aliased to "uint32_t", thus allowing
> code to use that type on existing 32-bit compilers while ensuring that
> the code won't be misinterpreted if moved to a compiler where "int" is
> 64 bits.
OK, but as in other discussions, is there enough reason to add such a
feature? How often is it that someone would want to do this, and how
hard is it to do within the current C rules?
-- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-19 16:24 -0700 |
| Message-ID | <43be31fe-5669-4d5a-86d9-e491f1f27f94@googlegroups.com> |
| In reply to | #73263 |
On Sunday, October 18, 2015 at 11:42:57 PM UTC-5, glen herrmannsfeldt wrote:
> > I would regard as a defect in the Standard the fact that code like:
>
> > unsigned short mul_mod_65536(unsigned short a, unsigned short b)
> > {
> > return a*b;
> > }
>
> > has no defined behaviors which on any platform which differ from those where
> > UINT_MAX==USHRT_MAX, and has fully-defined behaviors on all platforms where
> > either UINT_MAX==USHRT_MAX or UINT_MAX/USHRT_MAX > 2u*USHRT_MAX, but will
> > invoke Undefined Behavior on platforms where UINT_MAX is larger than
> > USHRT_MAX but not large enough to prevent overflow.
>
> I would say don't do that.
>
> For one, you are assuming short is 16 bits.
Poorly named function. Originally I'd written the code using uint16_t, but
the issue goes back to C89 while those types only go back to C99, so I
changed the code to use "unsigned short" rather than "uint16_t" but didn't
change the function name suitably.
> But why would you want to do that?
Unsigned values are often used for quantities which should logically "wrap
around"; it is because of such usage that the C Standard requires that
implementations must not trap the wrap-around behavior. An example of a
usage case where the situation might arise, consider a function that is
supposed to output N copies of a 16-bit word and update a 16-bit ones'
complement checksum. A reasonable approach which will work perfectly on
any system where "int" is 16 bits or 64 bits, but may fail on systems
where "int" is 32 bits, would be:
void update_checksum_for_write_multiple(
uint16_t dat, uint16_t n, uint16_t *checksum)
{
*checksum -= dat*n;
}
Nice and simple, but to ensure defined behavior on 32-bit systems would
require that the function be written as "*checksum -= (0u+dat)*n;" or some
variation thereof. The promotion is needed not because code needs a
32-bit result, but merely to ensure that the system will compute the bottom
16 bits without invoking Undefined Behavior.
> But if you did, you should well understant the C promotion rules
> and the effect of them in the case of overflow.
The above code would work perfectly on a 16-bit system (and many compilers
for vintage 8-bit and 16-bit CPU platforms don't have brilliant optimizers,
and thus may waste time on adding 0 to the indicated value). How likely
would somebody porting a code base from a vintage system to a more modern
be to notice the need to coerce the values before performing the multiply?
> Personally, I believe that the promotion rules more often give the
> desired answer than not, but otherwise they are something that C
> programmers need to learn.
A major problem with the promotion rules is that the so-called "fixed-size
types" have semantics which vary depending upon the size of "int". This
can often have the effect that code which works perfectly on the platform
for which it was written may malfunction in bizarre ways when ported to a
different platform. While the effects of many of the rules are rather
entrenched, most of them will yield behavior which, when wrong, will be
deterministically so. The Undefined Behavior at issue here is far more
insidious because while it is very unlikely to result in the value being
miscalculated, it's actually more likely to result in other bizarre and
seemingly-unrelated problems. For example, given the code:
if (rom_expansion_installed) // 128Kbyte instead of 32Kbyte option
update_checksum_for_write_multiple(0xFFFF, 0xC000, *csum);
which is supposed to calculate the effect of adding 49152 blank words
to the checksum (Most programmable ROM devices are all 1's when erased)
may instead cause some compilers to infer that "rom_expansion_installed"
cannot be true, and thus nullify the effect of all code which is supposed
to be applicable to 128K-expanded units.
> OK, but as in other discussions, is there enough reason to add such a
> feature? How often is it that someone would want to do this, and how
> hard is it to do within the current C rules?
There exists a huge variety of code which requires a wrapping 32-bit integer
type. Porting such code to platforms where "int" is 64 bits is often
a major task fraught with danger, since there are lots of subtleties which
may be hard to catch in a code inspection.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-20 02:20 +0000 |
| Message-ID | <n048e9$6v6$1@speranza.aioe.org> |
| In reply to | #73360 |
supercat@casperkitty.com wrote:
>> > I would regard as a defect in the Standard the fact that code like:
>> > unsigned short mul_mod_65536(unsigned short a, unsigned short b)
>> > {
>> > return a*b;
>> > }
>> > has no defined behaviors which on any platform which differ from those where
>> > UINT_MAX==USHRT_MAX, and has fully-defined behaviors on all platforms where
>> > either UINT_MAX==USHRT_MAX or UINT_MAX/USHRT_MAX > 2u*USHRT_MAX, but will
>> > invoke Undefined Behavior on platforms where UINT_MAX is larger than
>> > USHRT_MAX but not large enough to prevent overflow.
(snip, then I wrote)
>> I would say don't do that.
>> For one, you are assuming short is 16 bits.
> Poorly named function. Originally I'd written the code using uint16_t, but
> the issue goes back to C89 while those types only go back to C99, so I
> changed the code to use "unsigned short" rather than "uint16_t" but didn't
> change the function name suitably.
I suppose, but it seems to me that you should write independent of the
actual widths when possible. If you really need a modulo 65536, you
should code for that, maybe with an &0xffff.
>> But why would you want to do that?
> Unsigned values are often used for quantities which should logically "wrap
> around"; it is because of such usage that the C Standard requires that
> implementations must not trap the wrap-around behavior. An example of a
> usage case where the situation might arise, consider a function that is
> supposed to output N copies of a 16-bit word and update a 16-bit ones'
> complement checksum. A reasonable approach which will work perfectly on
> any system where "int" is 16 bits or 64 bits, but may fail on systems
> where "int" is 32 bits, would be:
Does it work right if you cast to (unsigned int) before the multiply?
Then the question relates the optimization, and if the compiler can
figure out how to do it right.
> void update_checksum_for_write_multiple(
> uint16_t dat, uint16_t n, uint16_t *checksum)
> {
> *checksum -= dat*n;
> }
> Nice and simple, but to ensure defined behavior on 32-bit systems would
> require that the function be written as "*checksum -= (0u+dat)*n;" or some
> variation thereof. The promotion is needed not because code needs a
> 32-bit result, but merely to ensure that the system will compute the bottom
> 16 bits without invoking Undefined Behavior.
It would be nice to have a high-level language with an operator of
function to do multipication giving the double width product.
As well as I know, given
int i, j;
long long k; /* double the size of int */
k=(long long)i*j;
compilers figure out not to do three multiplies by zero.
(I was doing this some years ago on IA32 processors.)
>> But if you did, you should well understant the C promotion rules
>> and the effect of them in the case of overflow.
> The above code would work perfectly on a 16-bit system (and many compilers
> for vintage 8-bit and 16-bit CPU platforms don't have brilliant optimizers,
> and thus may waste time on adding 0 to the indicated value). How likely
> would somebody porting a code base from a vintage system to a more modern
> be to notice the need to coerce the values before performing the multiply?
Yes, but that is true for many other reasons, and others would appear if
you changed the promotion rules.
>> Personally, I believe that the promotion rules more often give the
>> desired answer than not, but otherwise they are something that C
>> programmers need to learn.
> A major problem with the promotion rules is that the so-called "fixed-size
> types" have semantics which vary depending upon the size of "int". This
> can often have the effect that code which works perfectly on the platform
> for which it was written may malfunction in bizarre ways when ported to a
> different platform. While the effects of many of the rules are rather
> entrenched, most of them will yield behavior which, when wrong, will be
> deterministically so. The Undefined Behavior at issue here is far more
> insidious because while it is very unlikely to result in the value being
> miscalculated, it's actually more likely to result in other bizarre and
> seemingly-unrelated problems. For example, given the code:
> if (rom_expansion_installed) // 128Kbyte instead of 32Kbyte option
> update_checksum_for_write_multiple(0xFFFF, 0xC000, *csum);
> which is supposed to calculate the effect of adding 49152 blank words
> to the checksum (Most programmable ROM devices are all 1's when erased)
That is true for the 2708 and descendants. I believe the pMOS 1702
erased to zeros.
I am not sure about 28xx chips, which are more common now than EPROMs.
> may instead cause some compilers to infer that "rom_expansion_installed"
> cannot be true, and thus nullify the effect of all code which is supposed
> to be applicable to 128K-expanded units.
>> OK, but as in other discussions, is there enough reason to add such a
>> feature? How often is it that someone would want to do this, and how
>> hard is it to do within the current C rules?
> There exists a huge variety of code which requires a wrapping 32-bit integer
> type. Porting such code to platforms where "int" is 64 bits is often
> a major task fraught with danger, since there are lots of subtleties which
> may be hard to catch in a code inspection.
Seems to me that code that is wrapping 32 bit integers is likely to
fail for other reason when int gets to 64 bits. That is, assuming
that larger values also have meaning.
I do remember lots of programs failing when reading files >=2GB,
even if they didn't do any fseek() or ftell().
-- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-19 19:53 -0700 |
| Message-ID | <8a834b26-aa65-4648-8c7e-a5e4c1d64740@googlegroups.com> |
| In reply to | #73368 |
On Monday, October 19, 2015 at 9:21:09 PM UTC-5, glen herrmannsfeldt wrote: > supercat wrote: > > ................ A reasonable approach which will work perfectly on > > any system where "int" is 16 bits or 64 bits, but may fail on systems > > where "int" is 32 bits, would be: > > Does it work right if you cast to (unsigned int) before the multiply? For the case where code needs a strictly-wrapping 16-bit math that would work; for code which needs a strictly-wrapping 32-bit math that would not necessarily work, since "int" could be smaller than 32 bits. Adding 0u will coerce something to "unsigned int" if it's not already bigger but otherwise leave the type unchanged, but that' seems a bit icky if what one really wants is modular arithmetic in the smaller type. Note that casting an operand to the unsigned type one actually *wants* won't help if it's smaller than integer. > > Nice and simple, but to ensure defined behavior on 32-bit systems would > > require that the function be written as "*checksum -= (0u+dat)*n;" or some > > variation thereof. The promotion is needed not because code needs a > > 32-bit result, but merely to ensure that the system will compute the bottom > > 16 bits without invoking Undefined Behavior. > > It would be nice to have a high-level language with an operator of > function to do multipication giving the double width product. Indeed. As well as one with types for modular arithmetic. > > The above code would work perfectly on a 16-bit system (and many compilers > > for vintage 8-bit and 16-bit CPU platforms don't have brilliant optimizers, > > and thus may waste time on adding 0 to the indicated value). How likely > > would somebody porting a code base from a vintage system to a more modern > > be to notice the need to coerce the values before performing the multiply? > > Yes, but that is true for many other reasons, and others would appear if > you changed the promotion rules. The specific change I described would not change any behaviors which are presently defined by the Standard, and I doubt it would change any behaviors which are presently being used in any implementation; it would merely mandate that all implementations must conform to the behavior which I would guess more than 99% of implementations (if not 100%) conformed to for the first 25 or so years of the C Standard. > That is true for the 2708 and descendants. I believe the pMOS 1702 > erased to zeros. > > I am not sure about 28xx chips, which are more common now than EPROMs. Bipolar PROMs erased to zeros; I wouldn't be surprised if PMOS chips did so as well. I've also seen a few modern microcontrollers whose code flash erases to all zeroes as well, which I found somewhat curious. > > There exists a huge variety of code which requires a wrapping 32-bit integer > > type. Porting such code to platforms where "int" is 64 bits is often > > a major task fraught with danger, since there are lots of subtleties which > > may be hard to catch in a code inspection. > > Seems to me that code that is wrapping 32 bit integers is likely to > fail for other reason when int gets to 64 bits. That is, assuming > that larger values also have meaning. There's a lot of code for things like checksums, hash codes, TCP windowing, etc. which expects the 32-bit wrapping behavior. Finding places where the code is just plain wrong probably won't be too hard, but finding places where it triggers UB may be harder, especially given that compiled code is likely to yield the proper mod-2^n result except when an optimizer sees a chance to declare some code "dead" that really shouldn't be. > I do remember lots of programs failing when reading files >=2GB, > even if they didn't do any fseek() or ftell(). Migrating to 64-bit "int" would be good for fixing code like that, but only if there's a way to ensure that what's supposed to be modular arithmetic, stays modular arithmetic.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-20 09:41 +0000 |
| Message-ID | <n05296$r3p$1@speranza.aioe.org> |
| In reply to | #73370 |
supercat@casperkitty.com wrote: >> supercat wrote: >> > ................ A reasonable approach which will work perfectly on >> > any system where "int" is 16 bits or 64 bits, but may fail on systems >> > where "int" is 32 bits, would be: (snip, I wrote) >> Does it work right if you cast to (unsigned int) before the multiply? > For the case where code needs a strictly-wrapping 16-bit math that would > work; for code which needs a strictly-wrapping 32-bit math that would > not necessarily work, since "int" could be smaller than 32 bits. Adding > 0u will coerce something to "unsigned int" if it's not already bigger but > otherwise leave the type unchanged, but that' seems a bit icky if what > one really wants is modular arithmetic in the smaller type. Note that > casting an operand to the unsigned type one actually *wants* won't help > if it's smaller than integer. As far as I know, compilers are pretty good at figuring that out. That is, if you cast uint16_t to uint32_t for the multiply, the compiler will figure out if a 16 bit multiply instruction is good enough, assuming the processor has one. Note that it will promote to int in any case, which is likely 32 bits, but again the compiler likely will figure it out. The origininal TeX, written in Pascal, needed a way to multiply a 32 bit integer by another one, then divide the full product by another 32 bit integer. Doing that in Pascal while avoiding overflow isn't easy, but Knuth did it. He then recommends that those two routines be rewritten in assembler if possible, where it might be two instructions. But it might not be all that hard to do a modulo 65536 mutliply using shifts, ands, and two or three multiply operations, where each wouldn't overflow int. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-17 19:53 -0700 |
| Message-ID | <lnh9lo28g3.fsf@kst-u.example.com> |
| In reply to | #73174 |
Richard Damon <Richard@Damon-Family.org> writes:
[...]
> Now, UCHAR_MAX == INT_MAX would be a strange setup. Something like a 16
> bit character, and int uses the the 16 value bits, plus a 16 bit 'byte'
> for the sign 'bit'.
The sign bit is by definition exactly 1 bit. int would have 16 value
bits, 1 sign bit, and 15 padding bits.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-17 16:07 -0700 |
| Message-ID | <lnwpul14cp.fsf@kst-u.example.com> |
| In reply to | #73164 |
Richard Damon <Richard@Damon-Family.org> writes:
[...]
> 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).
The problem doesn't occur as long as all unsigned char values and
EOF can be represented as distinct values within the range of int.
Of course there's a problem for code that stores the result of
getchar() in a char object, but as the Rationale says in another
context, "such dubious possibilities need not be allowed for".
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-17 14:55 -0700 |
| Message-ID | <lneggt2m9e.fsf@kst-u.example.com> |
| In reply to | #73111 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
> I wonder why signed char exists at all.
If you mean the type "signed char", it's just a small signed integer
type. In spite of the name, it's not commonly used for character data.
In fact it's probably not used much at all. But if plain char is
unsigned and CHAR_BIT==8, it's probably the only type available for
defining int8_t.
If you mean why is plain char allowed to be signed ...
[...]
> 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.
Don't some modern systems also do sign-extension by default?
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-18 04:28 +0000 |
| Message-ID | <mvv75h$dtf$1@speranza.aioe.org> |
| In reply to | #73159 |
Keith Thompson <kst-u@mib.org> wrote: (snip, I wrote, regarding signed char) >> 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. > Don't some modern systems also do sign-extension by default? If modern means IA32 or descendants, then it looks like both are there. There is MOVSX and MOVZX, move sign extended and move zero extended. But those might be newer, since the 8086. It might be that CBW and CWD trace back farther, and those sign extend. Though I am not so sure what you mean by default. If both instructions are provided, then neither one is default. I have the book for Itanium, but it isn't so easy to figure out which instruction it would be. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-15 12:49 -0700 |
| Message-ID | <kfnvba7j4iu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #72849 |
Keith Thompson <kst-u@mib.org> writes:
> [regarding storing of objects whose representations have
> padding bits]
>
> I seem to recall that an assignment can normalize the
> representation of the assigned value. For example, if float
> has two representations for 0.0, then
>
> x = 0.0;
>
> can store either of them. The standard's description of
> assignment discusses values; it doesn't mention representations.
But it does refer to them indirectly, because of the rule for
assignment:
the value of the right operand is _converted to the type of
the assignment expression_ [my emphasis] and replaces the
value stored in the object designated by the left operand.
Because of the rule for converting to a compatible type the
question of representation enters into the discussion. That
isn't relevant in the example above, because the two types
involved (float and double) are not compatible; but if 'x'
were of type double then this aspect needs consideration.
> But if that's the case, then I'm not sure that the requirement
> that conversion between compatible types doesn't change the
> representation is meaningful.
IMO this seeming conflict indicates a broken process somewhere
along the way that the semantics was being thrashed out. In any
case it seems clear the Standard comes up short here, and is in
need of some sort of clarification; beyond that I don't think
there is much point in trying to resolve the question further.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-15 12:26 -0700 |
| Message-ID | <kfnzizkhr1l.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #72817 |
raltbos@xs4all.nl (Richard Bos) writes:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>
>> raltbos@xs4all.nl (Richard Bos) writes:
>>
>>> It is, then, equally legal for both of them to be four-byte-aligned,
>>> with the padding bytes for int to be at the rear end of the object and
>>> those for float to be at the start; or, in fact, on the Mynah, the other
>>> way 'round! If you declare this:
>>>
>>> union zibble {
>>> float alpha;
>>> int beta;
>>> }
>>>
>>> the memory layout will be AABB, where the whole union will take four
>>> bytes, all these unions will be aligned on four-byte boundaries (as will
>>> individual ints and floats), _but_ bytes AA will be used for alpha, and
>>> BB for beta. Assigning anything to alpha will either clobber beta into
>>> random bits _or_ leave it alone, depending on optimisation settings, and
>>> /vice versa/.
>>
>> The last part here isn't right. Assigning to alpha must store
>> all four bytes of alpha. It's true that if an operation is done,
>> what values any padding bits take on may be determined more or
>> less arbitrarily. If, however, it's just a straight assignment,
>> eg
>>
>> union zibble z;
>> float f = 0;
>> z.alpha = f;
>>
>> then what goes into z.alpha must be the same bits as are
>> contained in f. This result follows from the rules of
>> type conversion, in particular, converting to a compatible
>> type causes no change to the value _or the representation_
>> (my emphasis).
>
> That would imply that all padding bits are required to be trap bits,
> which I really don't think is the case. I think the mistake is in the
> final clause; I don't think padding bits count as part of "the
> representation", in this case at least.
The comments from Keith Thompson said pretty much what I
was going to say. The semantics of storing an int or
float require storing all the bytes of the object in
question, regardless of whether they are padding bits.
Maybe you're thinking of padding _bytes_ in structs or unions,
which explicitly do not have to take part in the storing.
Even in this case though there cannot be any padding bytes
at the start of a struct or union.
[toc] | [prev] | [next] | [standalone]
Page 7 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