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 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Veek M <vek.m1234@gmail.com> |
|---|---|
| Date | 2016-12-30 11:35 +0530 |
| Subject | How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); |
| Message-ID | <o44tcs$94c$1@dont-email.me> |
On Freenode ##C, candide is a bot.
<qwename> ,cc int a[2] = { 1, 2 }; printf("%d\n", 2[a]);
<candide> qwename: runtime error: index 2 out of bounds for type 'int
[2]' runtime error: load of address 0x7fffffffe558 with insufficient
space for an object of type 'int' -1444544000
<qwename> ,cc int a[2] = { 1, 2 }; printf("%d\n", 1[a]);
<candide> qwename: 2
How is he doing 2[a] or 1[a]? I know that's an array subscript
expression.. but shouldn't 1,2 be identifiers? I get:
deathstar> echo 'int main(void) { int a[2] = { 1, 2 }; printf("%d\n",
1[a]); }'|tcc -run -
2
man 3 printf - expects a ptr
[toc] | [next] | [standalone]
| From | Veek M <vek.m1234@gmail.com> |
|---|---|
| Date | 2016-12-30 11:39 +0530 |
| Message-ID | <o44tkb$94c$2@dont-email.me> |
| In reply to | #100623 |
Veek M wrote:
> On Freenode ##C, candide is a bot.
>
> <qwename> ,cc int a[2] = { 1, 2 }; printf("%d\n", 2[a]);
> <candide> qwename: runtime error: index 2 out of bounds for type 'int
> [2]' runtime error: load of address 0x7fffffffe558 with insufficient
> space for an object of type 'int' -1444544000
> <qwename> ,cc int a[2] = { 1, 2 }; printf("%d\n", 1[a]);
> <candide> qwename: 2
>
> How is he doing 2[a] or 1[a]? I know that's an array subscript
> expression.. but shouldn't 1,2 be identifiers? I get:
>
> deathstar> echo 'int main(void) { int a[2] = { 1, 2 }; printf("%d\n",
> 1[a]); }'|tcc -run -
> 2
>
> man 3 printf - expects a ptr
sorry, I posted prematurely (finger snafu).
printf expects a value (or an expr of suitable type). How is 1 an
integer constant acting as some kind of ptr?
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-12-29 22:24 -0800 |
| Message-ID | <62vb6c1hepqggkeueq71hilmd7h5r3sqv0@4ax.com> |
| In reply to | #100624 |
On Fri, 30 Dec 2016 11:39:41 +0530, Veek M <vek.m1234@gmail.com>
wrote:
>Veek M wrote:
>
>> On Freenode ##C, candide is a bot.
>>
>> <qwename> ,cc int a[2] = { 1, 2 }; printf("%d\n", 2[a]);
>> <candide> qwename: runtime error: index 2 out of bounds for type 'int
>> [2]' runtime error: load of address 0x7fffffffe558 with insufficient
>> space for an object of type 'int' -1444544000
>> <qwename> ,cc int a[2] = { 1, 2 }; printf("%d\n", 1[a]);
>> <candide> qwename: 2
>>
>> How is he doing 2[a] or 1[a]? I know that's an array subscript
>> expression.. but shouldn't 1,2 be identifiers? I get:
>>
>> deathstar> echo 'int main(void) { int a[2] = { 1, 2 }; printf("%d\n",
>> 1[a]); }'|tcc -run -
>> 2
>>
>> man 3 printf - expects a ptr
>sorry, I posted prematurely (finger snafu).
>
>printf expects a value (or an expr of suitable type). How is 1 an
>integer constant acting as some kind of ptr?
The expression a[b] is defined to mean *(a+b). Since a+b evaluates to
the same value as b+a, *(a+b) is the same as *(b+a) which can then be
expressed a b[a]. Thus the two expressions a[b] is equivalent to
b[a].
People write 1[a] for the shock value.
In the code you posted, a is an array of 2 int. The two elements of
that array are a[0] and a[1]. There is no a[2]. Therefore the
expression 2[a] attempts to access a non-existent element and the
first error message is quite correct. The second message appears to
be system specific and should disappear once the problem is corrected.
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-01 10:56 +0000 |
| Message-ID | <5868e00a.5252281@news.xs4all.nl> |
| In reply to | #100626 |
Barry Schwarz <schwarzb@dqel.com> wrote: > The expression a[b] is defined to mean *(a+b). Since a+b evaluates to > the same value as b+a, *(a+b) is the same as *(b+a) which can then be > expressed a b[a]. Thus the two expressions a[b] is equivalent to > b[a]. > > People write 1[a] for the shock value. I have seen _one_ semi-good use for it: parallel arrays as an alternative to structs. But that's marginal. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-02 02:40 -0800 |
| Message-ID | <kfnmvf9sq15.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100760 |
raltbos@xs4all.nl (Richard Bos) writes: > Barry Schwarz <schwarzb@dqel.com> wrote: > >> The expression a[b] is defined to mean *(a+b). Since a+b evaluates to >> the same value as b+a, *(a+b) is the same as *(b+a) which can then be >> expressed a b[a]. Thus the two expressions a[b] is equivalent to >> b[a]. >> >> People write 1[a] for the shock value. > > I have seen _one_ semi-good use for it: parallel arrays as an > alternative to structs. But that's marginal. I have run into another case where I thought it actually made sense. The pointer variable -- let me call it 'p' -- is being used as a stack pointer, moving up and down. If pushes are done by '*--p = value;', then '0[p]' is the top of the stack, '1[p]' is one below the top of the stack, and so forth. Putting the 'p' inside the brackets corresponds to how the address would be written in an assembly language if 'p' were an index register. Seen from that perspective I thought '1[p]' did a better job of expressing what's going on than 'p[1]' would.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-03 21:09 +0000 |
| Message-ID | <586c12eb.1501375@news.xs4all.nl> |
| In reply to | #100861 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > raltbos@xs4all.nl (Richard Bos) writes: > > > Barry Schwarz <schwarzb@dqel.com> wrote: > > > >> The expression a[b] is defined to mean *(a+b). Since a+b evaluates to > >> the same value as b+a, *(a+b) is the same as *(b+a) which can then be > >> expressed a b[a]. Thus the two expressions a[b] is equivalent to > >> b[a]. > >> > >> People write 1[a] for the shock value. > > > > I have seen _one_ semi-good use for it: parallel arrays as an > > alternative to structs. But that's marginal. > > I have run into another case where I thought it actually made > sense. The pointer variable -- let me call it 'p' -- is being > used as a stack pointer, moving up and down. If pushes are done > by '*--p = value;', then '0[p]' is the top of the stack, '1[p]' > is one below the top of the stack, and so forth. Putting the 'p' > inside the brackets corresponds to how the address would be > written in an assembly language if 'p' were an index register. > Seen from that perspective I thought '1[p]' did a better job of > expressing what's going on than 'p[1]' would. Hm. Matter of taste, but in that case I would explicitly write *stackpointer and *(stackpointer+index). Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-13 16:30 -0800 |
| Message-ID | <kfn60lipjnw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #101036 |
raltbos@xs4all.nl (Richard Bos) writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> raltbos@xs4all.nl (Richard Bos) writes: >> >>> Barry Schwarz <schwarzb@dqel.com> wrote: >>> >>>> The expression a[b] is defined to mean *(a+b). Since a+b evaluates to >>>> the same value as b+a, *(a+b) is the same as *(b+a) which can then be >>>> expressed a b[a]. Thus the two expressions a[b] is equivalent to >>>> b[a]. >>>> >>>> People write 1[a] for the shock value. >>> >>> I have seen _one_ semi-good use for it: parallel arrays as an >>> alternative to structs. But that's marginal. >> >> I have run into another case where I thought it actually made >> sense. The pointer variable -- let me call it 'p' -- is being >> used as a stack pointer, moving up and down. If pushes are done >> by '*--p = value;', then '0[p]' is the top of the stack, '1[p]' >> is one below the top of the stack, and so forth. Putting the 'p' >> inside the brackets corresponds to how the address would be >> written in an assembly language if 'p' were an index register. >> Seen from that perspective I thought '1[p]' did a better job of >> expressing what's going on than 'p[1]' would. > > Hm. Matter of taste, but in that case I would explicitly write > *stackpointer and *(stackpointer+index). Probably it depends on what you're used to. For me, I had long ago internalized an assembly language notation where X(Y) meant using register Y as an index register, much like C's notation for array indexing. In cases where the index register contained an address rather than an index (and these cases were fairly common), it was usual to see addresses like 0(P) or 1(P), so 0[p] or 1[p] isn't that much of a stretch. Conversely, if I saw an access like *(stackpointer+index) there would probably be a second or two of metaphorical head scratching while I figured out either what was being said or why it was written that way. Of course I am used to seeing expressions like pointer+offset, but it is much more rare to see those then dereferenced. Off the top of my head I don't remember ever writing *(pointer+offset), although I guess I must have at some point. Bottom line is that I understand your reaction (and I hope you now better understand mine) and see where you're coming from. My guess is that "taste" in this particular situation is determined largely by background and what one is used to, and we just have somewhat different backgrounds.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-29 23:35 -0800 |
| Message-ID | <lna8bdzx6i.fsf@kst-u.example.com> |
| In reply to | #100623 |
Veek M <vek.m1234@gmail.com> writes:
[...]
> How is he doing 2[a] or 1[a]? I know that's an array subscript
> expression.. but shouldn't 1,2 be identifiers? I get:
[...]
The comp.lang.c FAQ is at http://www.c-faq.com/
This is essentially question 6.11.
--
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 | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2016-12-30 09:59 +0000 |
| Message-ID | <ecmpgrFeqkaU1@mid.uni-berlin.de> |
| In reply to | #100623 |
Veek M <vek.m1234@gmail.com> wrote:
> On Freenode ##C, candide is a bot.
> <qwename> ,cc int a[2] = { 1, 2 }; printf("%d\n", 2[a]);
> <candide> qwename: runtime error: index 2 out of bounds for type 'int
> [2]' runtime error: load of address 0x7fffffffe558 with insufficient
> space for an object of type 'int' -1444544000
> <qwename> ,cc int a[2] = { 1, 2 }; printf("%d\n", 1[a]);
> <candide> qwename: 2
> How is he doing 2[a] or 1[a]? I know that's an array subscript
> expression.. but shouldn't 1,2 be identifiers? I get:
It's rather simple: an expression of the form 'X[Y]' must
always be replaced by the compiler by '*(X+Y)' before it
further evaluates it - the '[]' notation is just syntactic
sugar. And the converted versions of
a[1] -> *(a + 1)
1[a] -> *(1 + a)
are identical (because addition is commutative, i.e. the
order of the summands doesn't matter), so the result is
the same.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-30 10:43 +0000 |
| Message-ID | <o45dks$m6q$1@dont-email.me> |
| In reply to | #100642 |
On 30/12/2016 09:59, Jens Thoms Toerring wrote:
> Veek M <vek.m1234@gmail.com> wrote:
>> On Freenode ##C, candide is a bot.
>
>> <qwename> ,cc int a[2] = { 1, 2 }; printf("%d\n", 2[a]);
>> <candide> qwename: runtime error: index 2 out of bounds for type 'int
>> [2]' runtime error: load of address 0x7fffffffe558 with insufficient
>> space for an object of type 'int' -1444544000
>> <qwename> ,cc int a[2] = { 1, 2 }; printf("%d\n", 1[a]);
>> <candide> qwename: 2
>
>> How is he doing 2[a] or 1[a]? I know that's an array subscript
>> expression.. but shouldn't 1,2 be identifiers? I get:
>
> It's rather simple: an expression of the form 'X[Y]' must
> always be replaced by the compiler by '*(X+Y)' before it
> further evaluates it - the '[]' notation is just syntactic
> sugar. And the converted versions of
>
> a[1] -> *(a + 1)
> 1[a] -> *(1 + a)
>
> are identical (because addition is commutative, i.e. the
> order of the summands doesn't matter), so the result is
> the same.
Addition could trivially have been made non-commutative when one operand
is a pointer and the other an integer. Then this would never come up.
And IOCCC entries have to be slightly more imaginative.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-30 12:55 +0000 |
| Message-ID | <87y3yxinjl.fsf@bsb.me.uk> |
| In reply to | #100643 |
BartC <bc@freeuk.com> writes: > On 30/12/2016 09:59, Jens Thoms Toerring wrote: <snip> >> It's rather simple: an expression of the form 'X[Y]' must >> always be replaced by the compiler by '*(X+Y)' before it >> further evaluates it - the '[]' notation is just syntactic >> sugar. And the converted versions of >> >> a[1] -> *(a + 1) >> 1[a] -> *(1 + a) >> >> are identical (because addition is commutative, i.e. the >> order of the summands doesn't matter), so the result is >> the same. > > Addition could trivially have been made non-commutative when one > operand is a pointer and the other an integer. And I am certain you would then have moaned about *that* instead. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-30 13:12 +0000 |
| Message-ID | <o45mdq$j5p$1@dont-email.me> |
| In reply to | #100649 |
On 30/12/2016 12:55, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 30/12/2016 09:59, Jens Thoms Toerring wrote: > <snip> >>> It's rather simple: an expression of the form 'X[Y]' must >>> always be replaced by the compiler by '*(X+Y)' before it >>> further evaluates it - the '[]' notation is just syntactic >>> sugar. And the converted versions of >>> >>> a[1] -> *(a + 1) >>> 1[a] -> *(1 + a) >>> >>> are identical (because addition is commutative, i.e. the >>> order of the summands doesn't matter), so the result is >>> the same. >> >> Addition could trivially have been made non-commutative when one >> operand is a pointer and the other an integer. > > And I am certain you would then have moaned about *that* instead. You'd be wrong. Has anyone ever complained that they can't do 'offset-P'? Because that could simply have been defined as -(P-offset) (After all, you can rewrite A-B as B-A in most cases with no error; you just get minus the original result.) But offset-P seems unnatural, as does offset+P. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-30 14:37 +0000 |
| Message-ID | <871swpiiu8.fsf@bsb.me.uk> |
| In reply to | #100651 |
BartC <bc@freeuk.com> writes: > On 30/12/2016 12:55, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 30/12/2016 09:59, Jens Thoms Toerring wrote: >> <snip> >>>> It's rather simple: an expression of the form 'X[Y]' must >>>> always be replaced by the compiler by '*(X+Y)' before it >>>> further evaluates it - the '[]' notation is just syntactic >>>> sugar. And the converted versions of >>>> >>>> a[1] -> *(a + 1) >>>> 1[a] -> *(1 + a) >>>> >>>> are identical (because addition is commutative, i.e. the >>>> order of the summands doesn't matter), so the result is >>>> the same. >>> >>> Addition could trivially have been made non-commutative when one >>> operand is a pointer and the other an integer. >> >> And I am certain you would then have moaned about *that* instead. > > You'd be wrong. > > Has anyone ever complained that they can't do 'offset-P'? Subtraction is never commutative. It's a red-herring. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-30 16:06 +0000 |
| Message-ID | <o460jn$pho$1@dont-email.me> |
| In reply to | #100662 |
On 30/12/2016 14:37, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> Has anyone ever complained that they can't do 'offset-P'? > > Subtraction is never commutative. It's a red-herring. That doesn't matter, and not my point. With addition A+B and B+A are both allowed for all types that allow +. With subtraction, A-B and B-A are also both allowed for all types that allow -, *except* when one is a pointer and the other a number. That is the discrepancy. That + is commutative just means that A+B == B+A, with -, while A-B == -(B-A). But it is that commutativity that leads to being able to do 1[A]. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-30 08:41 -0800 |
| Message-ID | <ln60m1z7xc.fsf@kst-u.example.com> |
| In reply to | #100668 |
BartC <bc@freeuk.com> writes:
> On 30/12/2016 14:37, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> Has anyone ever complained that they can't do 'offset-P'?
>>
>> Subtraction is never commutative. It's a red-herring.
>
> That doesn't matter, and not my point.
>
> With addition A+B and B+A are both allowed for all types that allow +.
>
> With subtraction, A-B and B-A are also both allowed for all types that
> allow -, *except* when one is a pointer and the other a number.
>
> That is the discrepancy.
Which exists because there is no unary "-" for pointers, and negating a
pointer makes no sense. P-i yields a (possibly meaningful) pointer; i-P
does not.
> That + is commutative just means that A+B == B+A, with -, while A-B ==
> -(B-A). But it is that commutativity that leads to being able to do 1[A].
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-30 17:31 +0000 |
| Message-ID | <o465j7$f80$1@dont-email.me> |
| In reply to | #100679 |
On 30/12/2016 16:41, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 30/12/2016 14:37, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >> >>>> Has anyone ever complained that they can't do 'offset-P'? >>> >>> Subtraction is never commutative. It's a red-herring. >> >> That doesn't matter, and not my point. >> >> With addition A+B and B+A are both allowed for all types that allow +. >> >> With subtraction, A-B and B-A are also both allowed for all types that >> allow -, *except* when one is a pointer and the other a number. >> >> That is the discrepancy. > > Which exists because there is no unary "-" for pointers, and negating a > pointer makes no sense. Neither does negating an unsigned int. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-30 19:20 +0000 |
| Message-ID | <87lguxgr66.fsf@bsb.me.uk> |
| In reply to | #100685 |
BartC <bc@freeuk.com> writes: > On 30/12/2016 16:41, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: >>> On 30/12/2016 14:37, Ben Bacarisse wrote: >>>> BartC <bc@freeuk.com> writes: >>> >>>>> Has anyone ever complained that they can't do 'offset-P'? >>>> >>>> Subtraction is never commutative. It's a red-herring. >>> >>> That doesn't matter, and not my point. >>> >>> With addition A+B and B+A are both allowed for all types that allow +. >>> >>> With subtraction, A-B and B-A are also both allowed for all types that >>> allow -, *except* when one is a pointer and the other a number. >>> >>> That is the discrepancy. >> >> Which exists because there is no unary "-" for pointers, and negating a >> pointer makes no sense. > > Neither does negating an unsigned int. 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. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-30 19:41 +0000 |
| Message-ID | <o46d74$enp$1@dont-email.me> |
| In reply to | #100694 |
On 30/12/2016 19:20, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> 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.
>
> 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.
I don't really want to get into this again but not everyone is
interested in unsigned numbers as modular ones; they just want an extra
bit of precision. Then negating such a number gives a meaningless
result, just like a pointer (although ironically, pointers typically
behave like modular numbers).
That additive inverse is also intimately related to the width of the
number; that property can be lost just by copying the values as is shown
here by the second printf:
uint32_t a,b;
uint64_t aa,bb;
a=42;
b=-a;
printf("a=%u b=%u a+b=%u\n",a,b,a+b);
aa=a;
bb=b;
printf("aa=%llu bb=%llu aa+bb=%llu\n",aa,bb,aa+bb);
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-30 12:46 -0800 |
| Message-ID | <cb9e80ca-bb23-4ff1-9844-43100dd8d3ff@googlegroups.com> |
| In reply to | #100695 |
On Friday, December 30, 2016 at 1:41:57 PM UTC-6, Bart wrote: > I don't really want to get into this again but not everyone is > interested in unsigned numbers as modular ones; they just want an extra > bit of precision. Then negating such a number gives a meaningless > result, just like a pointer (although ironically, pointers typically > behave like modular numbers). It's unfortunate that C never provided any way for programmers to explicitly request whole-number types that behave like mathematical integers, versus types that behave like modular-arithmetic rings, since most programmers will know perfectly well which one they need in any given situation. What happens instead is that a type like uint32_t will behave one way on some implementations and the other way on others. If there were separate types wrap32_t and unum32_t, that would allow programmers to use the former knowing that a compiler would squawk if it couldn't obey the rules of modular arithmetic, while also allowing a compiler to optimize code using the latter in ways it couldn't optimize code using the existing unsigned types (e.g. if x is a unum32_t, a compiler could assume x+1>x is true without having to allow for the possibility that x might be 0xFFFFFFFF).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-31 00:31 +0000 |
| Message-ID | <87a8bdgcs2.fsf@bsb.me.uk> |
| In reply to | #100695 |
BartC <bc@freeuk.com> writes: > On 30/12/2016 19:20, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> 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. >> >> 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. > > I don't really want to get into this again but not everyone is > interested in unsigned numbers as modular ones; For negating an unsigned int to make no sense there would have to be no one interested in unsigned numbers as modular ones. All you mean is that it makes no sense to some people or in some situations. > they just want an > extra bit of precision. Then negating such a number gives a > meaningless result, Meaningless to them. The meaning remains the same even when it's not understood. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web