Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100623 > unrolled thread
| Started by | Veek M <vek.m1234@gmail.com> |
|---|---|
| First post | 2016-12-30 11:35 +0530 |
| Last post | 2016-12-31 07:37 +0530 |
| Articles | 20 on this page of 102 — 18 participants |
Back to article view | Back to comp.lang.c
How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Veek M <vek.m1234@gmail.com> - 2016-12-30 11:35 +0530
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Veek M <vek.m1234@gmail.com> - 2016-12-30 11:39 +0530
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 22:24 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); raltbos@xs4all.nl (Richard Bos) - 2017-01-01 10:56 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:40 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); raltbos@xs4all.nl (Richard Bos) - 2017-01-03 21:09 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 16:30 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Keith Thompson <kst-u@mib.org> - 2016-12-29 23:35 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); jt@toerring.de (Jens Thoms Toerring) - 2016-12-30 09:59 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2016-12-30 10:43 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 12:55 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2016-12-30 13:12 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 14:37 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2016-12-30 16:06 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Keith Thompson <kst-u@mib.org> - 2016-12-30 08:41 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2016-12-30 17:31 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 19:20 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2016-12-30 19:41 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2016-12-30 12:46 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 00:31 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2016-12-30 11:50 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); raltbos@xs4all.nl (Richard Bos) - 2017-01-01 10:54 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-01 11:35 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 12:00 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-01 12:16 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 13:03 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-01 14:52 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 15:42 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-01 16:14 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 17:18 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Keith Thompson <kst-u@mib.org> - 2017-01-01 13:09 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-01 19:24 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); bart4858@gmail.com - 2017-01-01 11:24 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 20:05 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Keith Thompson <kst-u@mib.org> - 2017-01-01 13:11 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 22:25 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-02 02:00 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-01 13:51 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-01 21:59 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-01 14:34 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-02 02:09 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 05:44 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-02 15:18 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-02 15:21 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-02 17:07 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 09:53 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-02 23:37 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 15:07 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ian Collins <ian-news@hotmail.com> - 2017-01-03 12:11 +1300
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 15:46 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 00:54 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-03 00:33 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 11:11 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-03 11:32 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:05 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-03 14:23 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 16:04 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 16:09 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 17:23 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2017-01-03 09:00 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 20:33 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); luser droog <luser.droog@gmail.com> - 2017-01-03 11:40 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2017-01-03 12:23 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); luser droog <luser.droog@gmail.com> - 2017-01-03 12:39 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2017-01-03 13:51 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 22:58 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2017-01-16 10:24 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:36 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 00:53 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ian Collins <ian-news@hotmail.com> - 2017-01-03 13:13 +1300
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Keith Thompson <kst-u@mib.org> - 2017-01-02 15:51 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 00:51 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); jt@toerring.de (Jens Thoms Toerring) - 2017-01-02 23:32 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-02 23:46 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 01:00 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-03 00:42 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ian Collins <ian-news@hotmail.com> - 2017-01-03 21:47 +1300
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-03 01:31 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 10:34 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-03 11:19 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 16:19 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Thompson <dave.thompson2@verizon.net> - 2017-01-18 07:51 -0500
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Gareth Owen <gwowen@gmail.com> - 2017-01-18 21:30 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Richard Heathfield <rjh@cpax.org.uk> - 2017-01-18 21:45 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); raltbos@xs4all.nl (Richard Bos) - 2017-01-18 21:55 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Gareth Owen <gwowen@gmail.com> - 2017-01-19 22:25 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 00:08 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-02 02:05 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-01 09:45 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 19:20 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2017-01-01 15:26 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-01 23:48 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 00:25 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-01 16:44 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Philip Lantz <prl@canterey.us> - 2017-01-01 23:54 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Keith Thompson <kst-u@mib.org> - 2017-01-01 13:25 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 22:36 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2017-01-01 15:38 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2016-12-30 13:42 +0000
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2016-12-30 15:07 +0100
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2016-12-30 10:21 -0800
Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Veek M <vek.m1234@gmail.com> - 2016-12-31 07:37 +0530
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-30 11:50 -0800 |
| Message-ID | <2b87df80-d008-4fa9-8288-b68b7a7a102d@googlegroups.com> |
| In reply to | #100694 |
On Friday, December 30, 2016 at 1:20:24 PM UTC-6, Ben Bacarisse wrote: > Of course it does. You get the additive inverse, just like you usually > do when you negate a signed int. It's negating a signed int that's odd > because you *don't* always get the additive inverse. On implementations that use silent ones'-complement or two's-complement wraparound on overflow, the unary minus operator will always yield the additive inverse. The values -MAX_INT-1 and MAX_INT+1 will be additive inverses of each other, even though on two's-complement machines they will both be negative.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-01 10:54 +0000 |
| Message-ID | <5868defa.4980093@news.xs4all.nl> |
| In reply to | #100685 |
BartC <bc@freeuk.com> wrote: > On 30/12/2016 16:41, Keith Thompson wrote: > > Which exists because there is no unary "-" for pointers, and negating a > > pointer makes no sense. > > Neither does negating an unsigned int. There goes someone who has never studied group theory. Richard
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-01 11:35 +0000 |
| Message-ID | <o4apes$n3q$1@dont-email.me> |
| In reply to | #100759 |
On 01/01/2017 10:54, Richard Bos wrote: > BartC <bc@freeuk.com> wrote: > >> On 30/12/2016 16:41, Keith Thompson wrote: > >>> Which exists because there is no unary "-" for pointers, and negating a >>> pointer makes no sense. >> >> Neither does negating an unsigned int. > > There goes someone who has never studied group theory. What does group theory say about 32- and 64-bit pointers? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-01 12:00 +0000 |
| Message-ID | <87ful3q9bt.fsf@bsb.me.uk> |
| In reply to | #100761 |
BartC <bc@freeuk.com> writes: > On 01/01/2017 10:54, Richard Bos wrote: >> BartC <bc@freeuk.com> wrote: >> >>> On 30/12/2016 16:41, Keith Thompson wrote: >> >>>> Which exists because there is no unary "-" for pointers, and negating a >>>> pointer makes no sense. >>> >>> Neither does negating an unsigned int. >> >> There goes someone who has never studied group theory. > > What does group theory say about 32- and 64-bit pointers? Nothing as far as I can see. What's your point? There are lots of types in C that don't form a group. C's unsigned ints do. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-01 12:16 +0000 |
| Message-ID | <o4arsj$uqe$1@dont-email.me> |
| In reply to | #100764 |
On 01/01/2017 12:00, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 01/01/2017 10:54, Richard Bos wrote: >>> BartC <bc@freeuk.com> wrote: >>> >>>> On 30/12/2016 16:41, Keith Thompson wrote: >>> >>>>> Which exists because there is no unary "-" for pointers, and negating a >>>>> pointer makes no sense. >>>> >>>> Neither does negating an unsigned int. >>> >>> There goes someone who has never studied group theory. >> >> What does group theory say about 32- and 64-bit pointers? > > Nothing as far as I can see. What's your point? There are lots of > types in C that don't form a group. C's unsigned ints do. Where does it say that in the Standard? All I can find is something that says they can never overflow because the values wrap around. My original point was that commutative pointer arithmetic is neither useful nor sensible as it leads to the 2[a] of the subject line. You can bamboozle me with higher mathematics but that won't stop people being confused by i[A] when they come across it. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-01 13:03 +0000 |
| Message-ID | <87a8bbq6ef.fsf@bsb.me.uk> |
| In reply to | #100767 |
BartC <bc@freeuk.com> writes: > On 01/01/2017 12:00, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 01/01/2017 10:54, Richard Bos wrote: >>>> BartC <bc@freeuk.com> wrote: >>>> >>>>> On 30/12/2016 16:41, Keith Thompson wrote: >>>> >>>>>> Which exists because there is no unary "-" for pointers, and negating a >>>>>> pointer makes no sense. >>>>> >>>>> Neither does negating an unsigned int. >>>> >>>> There goes someone who has never studied group theory. >>> >>> What does group theory say about 32- and 64-bit pointers? >> >> Nothing as far as I can see. What's your point? There are lots of >> types in C that don't form a group. C's unsigned ints do. > > Where does it say that in the Standard? It doesn't. Not every true statement about C is contained in the standard. > All I can find is something > that says they can never overflow because the values wrap around. From which a set of very useful properties follow. > My original point was that commutative pointer arithmetic is neither > useful nor sensible as it leads to the 2[a] of the subject line. Yes, I know that was your point. As far as I'm concerned that topic is done with -- you think it's neither useful nor sensible and I disagree. I know enough not to try to persuade you otherwise. I was simply correcting a misconception that cropped as as you were trying to justify your position: that negating an unsigned int makes no sense. That's often how these threads go: one thing leads to another. > You can bamboozle me with higher mathematics but that won't stop > people being confused by i[A] when they come across it. I agree. And, for the record, I accept that had C made addition non-commutative where pointers were involved you would not be moaning about it as yet another oddity in the language. By the way, I prefer not to bamboolze people but it's tricky at times because I also don't like to appear patronising by explaining things to people who already know them. In this case I chose not to mention group theory but I did say "additive inverse". My bad. The additive inverse of a value v is simply a value u such that v + u = 0. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-01 14:52 +0000 |
| Message-ID | <o4b511$t2j$1@dont-email.me> |
| In reply to | #100771 |
On 01/01/2017 13:03, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> All I can find is something >> that says they can never overflow because the values wrap around. > > From which a set of very useful properties follow. Sure. But probably there are more instances in practice where they are not useful. You don't want a pixel value of +250, or near-white, to suddenly become black when you add 6. You don't want to have a size_t type to wrap around to a plausible in-bounds value when you add multiply its value. And you don't really want _Bool values to be anything other than 0 or 1. Yet if you negate a _Bool with a value of 1, you're liable to end up with 4294967295. >> My original point was that commutative pointer arithmetic is neither >> useful nor sensible as it leads to the 2[a] of the subject line. > > Yes, I know that was your point. As far as I'm concerned that topic is > done with -- you think it's neither useful nor sensible and I disagree. Until you have to explain it to someone for the umpteenth time. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-01 15:42 +0000 |
| Message-ID | <87r34mpz0g.fsf@bsb.me.uk> |
| In reply to | #100775 |
BartC <bc@freeuk.com> writes: > On 01/01/2017 13:03, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> All I can find is something >>> that says they can never overflow because the values wrap around. >> >> From which a set of very useful properties follow. > > Sure. But probably there are more instances in practice where they are > not useful. That may well be true. Do you want a language that is good for only the most common situations, or do you favour a whole new set of integer types: ones that saturate, ones that wrap and ones that signal overflow? > You don't want a pixel value of +250, or near-white, to suddenly > become black when you add 6. You don't want to have a size_t type to > wrap around to a plausible in-bounds value when you add multiply its > value. > > And you don't really want _Bool values to be anything other than 0 or > 1. A _Bool value can only be 0 or 1. > Yet if you negate a _Bool with a value of 1, you're liable to end > up with 4294967295. On what compiler? You need to report this as a bug. >>> My original point was that commutative pointer arithmetic is neither >>> useful nor sensible as it leads to the 2[a] of the subject line. >> >> Yes, I know that was your point. As far as I'm concerned that topic is >> done with -- you think it's neither useful nor sensible and I disagree. > > Until you have to explain it to someone for the umpteenth time. No, I disagree even in that case. I find your seemingly endless whinging about things that can't be changed much more irritating. The learners often learn, so there is a sense of progress being made there. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-01 16:14 +0000 |
| Message-ID | <o4b9qa$h8i$1@dont-email.me> |
| In reply to | #100782 |
On 01/01/2017 15:42, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 01/01/2017 13:03, Ben Bacarisse wrote:
>>> BartC <bc@freeuk.com> writes:
>>
>>>> All I can find is something
>>>> that says they can never overflow because the values wrap around.
>>>
>>> From which a set of very useful properties follow.
>>
>> Sure. But probably there are more instances in practice where they are
>> not useful.
>
> That may well be true. Do you want a language that is good for only the
> most common situations, or do you favour a whole new set of integer
> types: ones that saturate, ones that wrap and ones that signal overflow?
>
>> You don't want a pixel value of +250, or near-white, to suddenly
>> become black when you add 6. You don't want to have a size_t type to
>> wrap around to a plausible in-bounds value when you add multiply its
>> value.
>>
>> And you don't really want _Bool values to be anything other than 0 or
>> 1.
>
> A _Bool value can only be 0 or 1.
>
>> Yet if you negate a _Bool with a value of 1, you're liable to end
>> up with 4294967295.
>
> On what compiler? You need to report this as a bug.
Assigning to a bool is OK (the value is adjusted to be 0 or 1). But
anything else doesn't seem to be adjusted the same way:
_Bool a,b;
int i;
a = 1;
b = -a;
i = -a;
printf("a = %u\n",a);
printf("b = %u\n",b);
printf("-a = %u\n",-a);
printf("i = %d\n",i);
Output is the same on all compilers:
a = 1
b = 1
-a = 4294967295
i = -1
So it seems to hinge on what the type of '-a' is intended to be. It
doesn't look like it's _Bool.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-01 17:18 +0000 |
| Message-ID | <878tqupule.fsf@bsb.me.uk> |
| In reply to | #100785 |
BartC <bc@freeuk.com> writes:
> On 01/01/2017 15:42, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
<snip>
>>> Yet if you negate a _Bool with a value of 1, you're liable to end
>>> up with 4294967295.
>>
>> On what compiler? You need to report this as a bug.
>
> Assigning to a bool is OK (the value is adjusted to be 0 or 1). But
> anything else doesn't seem to be adjusted the same way:
>
> _Bool a,b;
<snip>
> a = 1;
<snip>
> printf("-a = %u\n",-a);
<snip>
> Output is the same on all compilers:
<snip>
> -a = 4294967295
What do you expect -1 to print as using the %u format? (Technically,
the code is undefined but I don't think any implementation takes
advantage of that permission.)
> So it seems to hinge on what the type of '-a' is intended to be. It
> doesn't look like it's _Bool.
When a is of type _Bool with value 1, -a has the value -1. It's not
rocket science, but it is C and you are constantly puzzled by C's rules.
The bottom line is that negating a _Bool with value 1 does not give you
4294967295. You are spreading more confusion by suggesting that you are
likely to get that value.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-01 13:09 -0800 |
| Message-ID | <lneg0mxzab.fsf@kst-u.example.com> |
| In reply to | #100791 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> BartC <bc@freeuk.com> writes:
>> On 01/01/2017 15:42, Ben Bacarisse wrote:
>>> BartC <bc@freeuk.com> writes:
> <snip>
>>>> Yet if you negate a _Bool with a value of 1, you're liable to end
>>>> up with 4294967295.
>>>
>>> On what compiler? You need to report this as a bug.
>>
>> Assigning to a bool is OK (the value is adjusted to be 0 or 1). But
>> anything else doesn't seem to be adjusted the same way:
>>
>> _Bool a,b;
> <snip>
>> a = 1;
> <snip>
>> printf("-a = %u\n",-a);
> <snip>
>> Output is the same on all compilers:
> <snip>
>> -a = 4294967295
>
> What do you expect -1 to print as using the %u format? (Technically,
> the code is undefined but I don't think any implementation takes
> advantage of that permission.)
>
>> So it seems to hinge on what the type of '-a' is intended to be. It
>> doesn't look like it's _Bool.
>
> When a is of type _Bool with value 1, -a has the value -1. It's not
> rocket science, but it is C and you are constantly puzzled by C's rules.
> The bottom line is that negating a _Bool with value 1 does not give you
> 4294967295. You are spreading more confusion by suggesting that you are
> likely to get that value.
Directly negating a _Bool is not possible; there is no unary "-"
operator that takes an operand of type _Bool (or of any integer type
narrower than int). Given:
_Bool a = 1;
the expression
-a
converts the value of a to type int, and then negates it, yielding a
result of type int with the value -1. Printing that int value with a
"%u" has undefined behavior, but will typically print an unsigned int
value whose representation is the same as the int value -1, often
4294967295.
The fact that C's arithmetic operators do not apply to narrow types,
requiring moderately complicated rules to promote the operands, can
cause some confusion. (Let me suggest yet again that the solution to
such confusion is to understand the rules.)
Why would you want to apply a unary "-" operator to a _Bool operand in
the first place?
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-01 19:24 +0100 |
| Message-ID | <o4bhea$dku$1@dont-email.me> |
| In reply to | #100785 |
On 01/01/17 17:14, BartC wrote:
> On 01/01/2017 15:42, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 01/01/2017 13:03, Ben Bacarisse wrote:
>>>> BartC <bc@freeuk.com> writes:
>>>
>>>>> All I can find is something
>>>>> that says they can never overflow because the values wrap around.
>>>>
>>>> From which a set of very useful properties follow.
>>>
>>> Sure. But probably there are more instances in practice where they are
>>> not useful.
>>
>> That may well be true. Do you want a language that is good for only the
>> most common situations, or do you favour a whole new set of integer
>> types: ones that saturate, ones that wrap and ones that signal overflow?
>>
>>> You don't want a pixel value of +250, or near-white, to suddenly
>>> become black when you add 6. You don't want to have a size_t type to
>>> wrap around to a plausible in-bounds value when you add multiply its
>>> value.
>>>
>>> And you don't really want _Bool values to be anything other than 0 or
>>> 1.
>>
>> A _Bool value can only be 0 or 1.
>>
>>> Yet if you negate a _Bool with a value of 1, you're liable to end
>>> up with 4294967295.
>>
>> On what compiler? You need to report this as a bug.
>
> Assigning to a bool is OK (the value is adjusted to be 0 or 1). But
> anything else doesn't seem to be adjusted the same way:
>
> _Bool a,b;
> int i;
>
> a = 1;
> b = -a;
a is "integer promoted" to int with value 1, negated to value -1
(section 6.3.1.1), then converted to 1 when stored in the _Bool (6.3.1.2).
> i = -a;
a is "integer promoted" to int with value 1, negated to value -1
(section 6.3.1.1), then stays as -1 when it is stored to the int as no
conversion is needed.
>
> printf("a = %u\n",a);
> printf("b = %u\n",b);
> printf("-a = %u\n",-a);
a is "integer promoted" to int with value 1, negated to value -1
(section 6.3.1.1), then stays as -1 when it is passed to printf. You
asked printf to interpret this as an unsigned int, so it is converted
modulo 2^32 (on your platform) to 4294967295.
> printf("i = %d\n",i);
>
>
> Output is the same on all compilers:
>
> a = 1
> b = 1
> -a = 4294967295
> i = -1
>
> So it seems to hinge on what the type of '-a' is intended to be. It
> doesn't look like it's _Bool.
>
There are three steps to the process. First, there is the integer
promotion. Then there is the conversion to the target type. Then, in
the case of printf, there is the interpretation of the type by printf.
This is very basic stuff. It is also stuff that has been explained to
you time and again in this newsgroup. And it is covered pretty clearly
in 6.3.1 of the standards. How can you claim to find this hard, or
surprising, or new to you? How can you be trying to write your own C
compiler and not understand this? It is like someone telling us they
design their own cars, but get really confused that for some turns you
have to use your indicators, and for some turns you don't.
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2017-01-01 11:24 -0800 |
| Message-ID | <373be98a-f121-4261-98f9-4fd36162d079@googlegroups.com> |
| In reply to | #100799 |
On Sunday, 1 January 2017 18:24:44 UTC, David Brown wrote: > On 01/01/17 17:14, BartC wrote: > > So it seems to hinge on what the type of '-a' is intended to be. It > > doesn't look like it's _Bool. > > > > There are three steps to the process. First, there is the integer > promotion. Signed or unsigned? > Then there is the conversion to the target type. Which is? > Then, in > the case of printf, there is the interpretation of the type by printf. A red herring. The bit pattern is all ones, it will be displayed as -1 or MAX_UINT [sp?] depending on the format code. Not 1 or 0 anyway. I don't think people use _Bool enough to know the rules precisely. Adding 12 to a will yield 13, until it is assigned or cast to _Bool then the conversion kicks in. But this is not obvious. (If _Bool was in one of my languages, it probably wouldn't allow any arithmetic on it at all.) But what we have is that in C, a number with a range of 0 to 255 can be negated to give a number also in the same range. OK, that's the additive inverse (IF the result is stored in a number of the same type and width). A _Bool with a value of 1 can be negated to give a number, which when stored in a the same type, is neither -1 nor the additive inverse. Does it matter? No, but when someone says that a negative pointer is meaningless then that doesn't make the above so sensible either! >How can you claim to find this hard, or > surprising, or new to you? How can you be trying to write your own C > compiler and not understand this? It is like someone telling us they > design their own cars, but get really confused that for some turns you > have to use your indicators, and for some turns you don't. That's not an issue. When I wrote applications, my users were always much more adept at using them than I was! In the case of C, you just have to look up the rules, implement them once, then forgot about them. For example, is the following legal: #define foo(foo) Apparently it is when I try it (not just gcc, which may have extensions to allow it, but generally). Fine, so I don't need to check a parameter name against the macro name. But the following isn't legal so needs checking for: #define foo(foo,foo) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-01 20:05 +0000 |
| Message-ID | <87lguuo8b7.fsf@bsb.me.uk> |
| In reply to | #100803 |
bart4858@gmail.com writes: > On Sunday, 1 January 2017 18:24:44 UTC, David Brown wrote: >> On 01/01/17 17:14, BartC wrote: > >> > So it seems to hinge on what the type of '-a' is intended to be. It >> > doesn't look like it's _Bool. >> > >> >> There are three steps to the process. First, there is the integer >> promotion. > > Signed or unsigned? Signed. >> Then there is the conversion to the target type. > > Which is? I think David is referring to your rather odd phrase "it seems to hinge on what the type of '-a' is intended to be". -a is if type int. If you intend it to be of some other type there would be a conversion. >> Then, in >> the case of printf, there is the interpretation of the type by printf. > > A red herring. The bit pattern is all ones, it will be displayed as -1 > or MAX_UINT [sp?] depending on the format code. Not 1 or 0 anyway. It's not a red herring at all. You seemed to think that "if you negate a _Bool with a value of 1, you're liable to end up with 4294967295". David is explaining how you might have got that odd idea. Does it not help to know? > I don't think people use _Bool enough to know the rules > precisely. It's a good idea to learn the rules even if you only use _Bool once or twice but that is, I think, an unfashionable approach to programming. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-01 13:11 -0800 |
| Message-ID | <lna8baxz6s.fsf@kst-u.example.com> |
| In reply to | #100808 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> bart4858@gmail.com writes:
>
>> On Sunday, 1 January 2017 18:24:44 UTC, David Brown wrote:
>>> On 01/01/17 17:14, BartC wrote:
>>
>>> > So it seems to hinge on what the type of '-a' is intended to be. It
>>> > doesn't look like it's _Bool.
>>> >
>>>
>>> There are three steps to the process. First, there is the integer
>>> promotion.
>>
>> Signed or unsigned?
>
> Signed.
>
>>> Then there is the conversion to the target type.
>>
>> Which is?
>
> I think David is referring to your rather odd phrase "it seems to hinge
> on what the type of '-a' is intended to be". -a is if type int. If you
> intend it to be of some other type there would be a conversion.
If you intend -a to be of some type other than int, the compiler will
quietly ignore your intent and treat it as an expression of type int.
[...]
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-01 22:25 +0000 |
| Message-ID | <87a8bao1sh.fsf@bsb.me.uk> |
| In reply to | #100815 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> bart4858@gmail.com writes: >> >>> On Sunday, 1 January 2017 18:24:44 UTC, David Brown wrote: >>>> On 01/01/17 17:14, BartC wrote: >>> >>>> > So it seems to hinge on what the type of '-a' is intended to be. It >>>> > doesn't look like it's _Bool. >>>> > >>>> >>>> There are three steps to the process. First, there is the integer >>>> promotion. >>> >>> Signed or unsigned? >> >> Signed. >> >>>> Then there is the conversion to the target type. >>> >>> Which is? >> >> I think David is referring to your rather odd phrase "it seems to hinge >> on what the type of '-a' is intended to be". -a is if type int. If you >> intend it to be of some other type there would be a conversion. > > If you intend -a to be of some type other than int, the compiler will > quietly ignore your intent and treat it as an expression of type int. I meant "... there would need to be a conversion". I.e. if the intent was to have an expression of type _Bool you would need a conversion to _Bool. But since I'm trying to attribute meaning to a vague phrase I did not write even that is a guess. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-02 02:00 +0100 |
| Message-ID | <o4c8l4$ups$1@dont-email.me> |
| In reply to | #100825 |
On 01/01/17 23:25, Ben Bacarisse wrote: > Keith Thompson <kst-u@mib.org> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>> bart4858@gmail.com writes: >>> >>>> On Sunday, 1 January 2017 18:24:44 UTC, David Brown wrote: >>>>> On 01/01/17 17:14, BartC wrote: >>>> >>>>>> So it seems to hinge on what the type of '-a' is intended to be. It >>>>>> doesn't look like it's _Bool. >>>>>> >>>>> >>>>> There are three steps to the process. First, there is the integer >>>>> promotion. >>>> >>>> Signed or unsigned? >>> >>> Signed. >>> >>>>> Then there is the conversion to the target type. >>>> >>>> Which is? >>> >>> I think David is referring to your rather odd phrase "it seems to hinge >>> on what the type of '-a' is intended to be". -a is if type int. If you >>> intend it to be of some other type there would be a conversion. >> >> If you intend -a to be of some type other than int, the compiler will >> quietly ignore your intent and treat it as an expression of type int. > > I meant "... there would need to be a conversion". I.e. if the intent > was to have an expression of type _Bool you would need a conversion to > _Bool. But since I'm trying to attribute meaning to a vague phrase I > did not write even that is a guess. > Your guess to my intent was perfectly reasonable. The possible conversion is when the "-a" (which is an "int") is stored in a variable, returned from a function, passed to a function, or in some other way turned into "what the type of '-a' is intended to be". I say "possible conversion", because if that "target type" is int, then no conversion is necessary.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-01 13:51 -0800 |
| Message-ID | <47e44ce2-afeb-428c-86ef-f600b0f92035@googlegroups.com> |
| In reply to | #100808 |
On Sunday, January 1, 2017 at 8:05:07 PM UTC, Ben Bacarisse wrote: > bart4858@gmail.com writes: > > > I don't think people use _Bool enough to know the rules > > precisely. > > It's a good idea to learn the rules even if you only use _Bool once or > twice but that is, I think, an unfashionable approach to programming. > The problem is there is far too much of this garbage in programming. A type which holds a flag that is set or unset, but with some sort of difficulty or complexity about it which means you really need to dig out the manual. Just use an int and set it to 1 or 0, the fancy types give no additional functionality, just complications.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-01 21:59 +0000 |
| Message-ID | <o4bu1i$rtl$1@dont-email.me> |
| In reply to | #100819 |
On 01/01/2017 21:51, Malcolm McLean wrote: > On Sunday, January 1, 2017 at 8:05:07 PM UTC, Ben Bacarisse wrote: >> bart4858@gmail.com writes: >> >>> I don't think people use _Bool enough to know the rules >>> precisely. >> >> It's a good idea to learn the rules even if you only use _Bool once or >> twice but that is, I think, an unfashionable approach to programming. >> > The problem is there is far too much of this garbage in programming. > > A type which holds a flag that is set or unset, but with some sort of > difficulty or complexity about it which means you really need to > dig out the manual. Just use an int and set it to 1 or 0, the fancy > types give no additional functionality, just complications. Exactly. I've never bothered much with bool [implementing it elsewhere] for these reasons. To do it properly, you'd have to implement half of Ada. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-01 14:34 -0800 |
| Message-ID | <e15cb280-09f9-4f5a-8728-ec175d472966@googlegroups.com> |
| In reply to | #100821 |
On Sunday, January 1, 2017 at 9:59:47 PM UTC, Bart wrote:
> On 01/01/2017 21:51, Malcolm McLean wrote:
> > On Sunday, January 1, 2017 at 8:05:07 PM UTC, Ben Bacarisse wrote:
> >> bart4858@gmail.com writes:
> >>
> >>> I don't think people use _Bool enough to know the rules
> >>> precisely.
> >>
> >> It's a good idea to learn the rules even if you only use _Bool once or
> >> twice but that is, I think, an unfashionable approach to programming.
> >>
> > The problem is there is far too much of this garbage in programming.
> >
> > A type which holds a flag that is set or unset, but with some sort of
> > difficulty or complexity about it which means you really need to
> > dig out the manual. Just use an int and set it to 1 or 0, the fancy
> > types give no additional functionality, just complications.
>
>
> Exactly. I've never bothered much with bool [implementing it elsewhere]
> for these reasons.
>
> To do it properly, you'd have to implement half of Ada.
>
The other thing is that boolean parameters are a bad idea. Let's
say we're created an "imagebutton" and maintainer sees this code
reset_but = imagebutton("reset_but.gif", 32, 32, do_reset, true);
nothing odd there. 32 and 32 are probably with width and height
in pixels, do_reset will be a function pointer Except what exactly
is the boolean parameter?
if we pass
reset_but = imagebutton("reset_but.gif", 32, 32, do_reset, ALLOW_TRANSPARENT);
it's obvious. The button is a gif, and it has transparency associated
with it.
So it makes a lot more sense to make the parameter an enumerated type
or an integer, even if in fact it is logically bi-valued.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web