Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #148634 > unrolled thread
| Started by | T <T@invalid.invalid> |
|---|---|
| First post | 2019-12-31 20:08 -0800 |
| Last post | 2020-01-21 16:44 +0100 |
| Articles | 20 on this page of 193 — 20 participants |
Back to article view | Back to comp.lang.c
Do "C" arrays start a 0 or 1? T <T@invalid.invalid> - 2019-12-31 20:08 -0800
Re: Do "C" arrays start a 0 or 1? Paul <nospam@needed.invalid> - 2019-12-31 23:50 -0500
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-01 03:28 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-01 03:49 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 13:26 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-01 04:34 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 13:56 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-01 05:04 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 14:18 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-01 13:21 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 14:26 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-01 13:19 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 14:24 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-01 14:56 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 16:06 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-01 15:44 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 16:54 +0100
Re: Do "C" arrays start a 0 or 1? chad <cdalten@gmail.com> - 2020-01-01 08:07 -0800
Re: Do "C" arrays start a 0 or 1? Dan Purgert <dan@djph.net> - 2020-01-01 14:19 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 15:28 +0100
Re: Do "C" arrays start a 0 or 1? Dan Purgert <dan@djph.net> - 2020-01-02 11:06 +0000
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-02 10:19 +0100
Re: Do "C" arrays start a 0 or 1? gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-02 13:33 +0000
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-02 13:55 +0000
Raku (Was: Do "C" arrays start a 0 or 1?) gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-02 14:48 +0000
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-02 15:03 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-02 06:18 -0800
Re: Do "C" arrays start a 0 or 1? m.nasim85@gmail.com - 2020-01-02 01:26 -0800
Re: Do "C" arrays start a 0 or 1? F Russell <fr@random.info> - 2020-01-05 19:32 +0000
Re: Do "C" arrays start a 0 or 1? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-05 12:25 -0800
Re: Do "C" arrays start a 0 or 1? F Russell <fr@random.info> - 2020-01-07 00:33 +0000
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 01:11 +0000
Re: Do "C" arrays start a 0 or 1? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-06 22:32 -0800
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 10:08 +0000
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 06:24 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 06:30 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 06:42 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 12:47 -0800
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 21:20 +0000
Re: Do "C" arrays start a 0 or 1? gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-07 21:53 +0000
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 14:01 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 14:22 -0800
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 22:31 +0000
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-08 00:27 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-08 08:13 -0800
Re: Do "C" arrays start a 0 or 1? chad <cdalten@gmail.com> - 2020-01-07 06:33 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 06:38 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 06:49 -0800
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 16:38 +0000
Re: Do "C" arrays start a 0 or 1? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-07 10:31 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 10:44 -0800
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-07 19:54 +0100
Re: Do "C" arrays start a 0 or 1? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 10:24 -0800
Re: Do "C" arrays start a 0 or 1? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-11 14:23 -0800
Re: Do "C" arrays start a 0 or 1? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 04:21 -0800
Re: Do "C" arrays start a 0 or 1? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 05:06 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 10:59 -0800
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 19:21 +0000
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-07 11:36 -0800
Re: Do "C" arrays start a 0 or 1? Barry Schwarz <schwarzb@delq.com> - 2020-01-06 18:02 -0800
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-07 10:55 +0100
Re: Do "C" arrays start a 0 or 1? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-06 23:34 -0500
Re: Do "C" arrays start a 0 or 1? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-06 22:30 -0800
Re: Do "C" arrays start a 0 or 1? Richard Damon <Richard@Damon-Family.org> - 2020-01-05 16:30 -0500
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-06 02:07 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-06 07:57 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 08:03 +0100
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 08:11 +0100
Re: Do "C" arrays start a 0 or 1? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-07 10:09 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 11:12 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 11:09 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 13:45 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 13:06 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 14:14 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-07 16:27 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 17:53 +0100
Re: Do "C" arrays start a 0 or 1? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-07 08:55 -0800
Re: Do "C" arrays start a 0 or 1? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-07 05:19 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-11 19:11 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-11 19:09 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-11 20:18 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-11 20:00 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 07:02 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 00:32 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 09:38 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 01:09 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 10:48 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 01:57 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 11:02 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 02:09 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 12:45 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 03:54 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 13:13 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 04:35 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 13:38 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 04:44 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 13:49 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 04:59 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 14:03 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 05:21 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 14:35 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 05:46 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 15:11 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 06:41 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 16:15 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 08:11 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 08:19 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 17:42 +0100
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 17:40 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 09:04 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 18:05 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 09:13 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 18:16 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 09:25 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 18:26 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 09:21 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 18:25 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 09:31 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 18:33 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-12 13:21 +0000
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-13 09:16 +0100
Re: Do "C" arrays start a 0 or 1? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-13 04:28 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 13:36 +0100
Re: Do "C" arrays start a 0 or 1? Öö Tiib <ootiib@hot.ee> - 2020-01-13 04:39 -0800
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-13 15:22 +0100
Re: Do "C" arrays start a 0 or 1? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-13 05:10 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 15:10 +0100
Re: Do "C" arrays start a 0 or 1? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-13 07:31 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 16:34 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 06:59 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 16:32 +0100
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 17:17 +0100
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 18:13 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 09:19 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 18:22 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 09:29 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 18:34 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 09:40 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 18:42 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 09:56 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 19:19 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 10:21 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-13 19:25 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 10:46 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 08:02 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-15 01:04 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-15 01:25 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-15 06:37 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-15 10:49 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-02-04 01:15 -0800
Re: Do "C" arrays start a 0 or 1? Siri Cruise <chine.bleu@yahoo.com> - 2020-02-04 01:48 -0800
Re: Do "C" arrays start a 0 or 1? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-04 02:29 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-02-04 03:05 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-02-04 04:07 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-02-04 04:59 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 08:51 -0800
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-13 15:19 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 06:47 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 06:51 -0800
Re: Do "C" arrays start a 0 or 1? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-13 09:35 -0800
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-13 21:48 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 12:54 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-13 13:38 -0800
Re: Do "C" arrays start a 0 or 1? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-14 02:30 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-14 02:40 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-14 02:47 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-14 03:52 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-14 04:00 -0800
Re: Do "C" arrays start a 0 or 1? David Brown <david.brown@hesbynett.no> - 2020-01-14 14:20 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 02:21 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 12:50 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 04:14 -0800
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-12 14:23 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 16:16 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 08:13 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 17:43 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-12 17:42 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 18:43 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-12 18:04 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 19:31 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-12 21:18 +0000
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 13:53 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 19:36 +0100
Re: Do "C" arrays start a 0 or 1? Bart <bc@freeuk.com> - 2020-01-12 20:56 +0000
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 10:04 -0800
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 02:05 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 12:43 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 03:46 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 12:51 +0100
Re: Do "C" arrays start a 0 or 1? fir <profesor.fir@gmail.com> - 2020-01-12 03:58 -0800
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-12 13:14 +0100
Re: Do "C" arrays start a 0 or 1? gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-07 13:03 +0000
Re: Do "C" arrays start a 0 or 1? Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-21 16:44 +0100
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-07 14:01 -0800 |
| Message-ID | <ea8a1a46-326f-42f4-b8cf-aee7f3031679@googlegroups.com> |
| In reply to | #148865 |
W dniu wtorek, 7 stycznia 2020 22:53:20 UTC+1 użytkownik Kenny McCormack napisał: > In article <7C6RF.2207$4c1.1692@fx31.am4>, Bart <bc@freeuk.com> wrote: > >On 07/01/2020 20:47, fir wrote: > > > >> some of my conclusions/hypothesis afair was pointers ale generaly much overused > >in c language, that probably double (**) and triple (***) etc pointers have no > >sense > > > >Plenty of uses for those. Eg: > > A pretty good inductive proof for the utility of pointers with any number > of *s is this: > > 1) If you have a pointer P of X *s, and you want to pass it into a > function and have the function modify that pointer, then you need > to pass the address of P (i.e., &P) to the function. The function > will declare the received paramter to be a pointer of (X+1) *s. > > Therefore, if pointers of X *s are useful, then so are pointers of > (X+1) *s. > > 2) Pointers of 1 * are useful (I leave it to the reader to convince > themselves of this). > > Therefore, pointers of any number of *s are useful. > the fact is hovever that a pointer to pointer to pointer to pointer to pointer is simply a pointer (that carries soem typisation) and as to my eye giving the * ** *** **** ***** etc all for * looks like some exagerration to me hovever this type info seem to be useful as normal type safety guard so i dont know
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-07 14:22 -0800 |
| Message-ID | <e2cc6f19-981b-4e0a-8812-c41129c03ac0@googlegroups.com> |
| In reply to | #148866 |
W dniu wtorek, 7 stycznia 2020 23:01:21 UTC+1 użytkownik fir napisał:
> W dniu wtorek, 7 stycznia 2020 22:53:20 UTC+1 użytkownik Kenny McCormack napisał:
> > In article <7C6RF.2207$4c1.1692@fx31.am4>, Bart <bc@freeuk.com> wrote:
> > >On 07/01/2020 20:47, fir wrote:
> > >
> > >> some of my conclusions/hypothesis afair was pointers ale generaly much overused
> > >in c language, that probably double (**) and triple (***) etc pointers have no
> > >sense
> > >
> > >Plenty of uses for those. Eg:
> >
> > A pretty good inductive proof for the utility of pointers with any number
> > of *s is this:
> >
> > 1) If you have a pointer P of X *s, and you want to pass it into a
> > function and have the function modify that pointer, then you need
> > to pass the address of P (i.e., &P) to the function. The function
> > will declare the received paramter to be a pointer of (X+1) *s.
> >
> > Therefore, if pointers of X *s are useful, then so are pointers of
> > (X+1) *s.
> >
> > 2) Pointers of 1 * are useful (I leave it to the reader to convince
> > themselves of this).
> >
> > Therefore, pointers of any number of *s are useful.
> >
>
> the fact is hovever that a pointer to pointer to pointer to pointer to pointer is simply a pointer (that carries soem typisation) and as to my eye giving the * ** *** **** ***** etc all for * looks like some exagerration to me
>
> hovever this type info seem to be useful as normal type safety guard so i dont know
there are also more subtle and contextual things as to this (that suggests me something is wrong here, for example if i look on things like that
char** zz = {"ala","ma","kota"};
foo(char** zz)
but this is more subtle and i dont quite remember the details (of what i really think on this, those pointers are kinda mess)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-07 22:31 +0000 |
| Message-ID | <oF7RF.3775$GFe.2271@fx12.am4> |
| In reply to | #148867 |
On 07/01/2020 22:22, fir wrote:
> W dniu wtorek, 7 stycznia 2020 23:01:21 UTC+1 użytkownik fir napisał:
>> W dniu wtorek, 7 stycznia 2020 22:53:20 UTC+1 użytkownik Kenny McCormack napisał:
>>> In article <7C6RF.2207$4c1.1692@fx31.am4>, Bart <bc@freeuk.com> wrote:
>>>> On 07/01/2020 20:47, fir wrote:
>>>>
>>>>> some of my conclusions/hypothesis afair was pointers ale generaly much overused
>>>> in c language, that probably double (**) and triple (***) etc pointers have no
>>>> sense
>>>>
>>>> Plenty of uses for those. Eg:
>>>
>>> A pretty good inductive proof for the utility of pointers with any number
>>> of *s is this:
>>>
>>> 1) If you have a pointer P of X *s, and you want to pass it into a
>>> function and have the function modify that pointer, then you need
>>> to pass the address of P (i.e., &P) to the function. The function
>>> will declare the received paramter to be a pointer of (X+1) *s.
>>>
>>> Therefore, if pointers of X *s are useful, then so are pointers of
>>> (X+1) *s.
>>>
>>> 2) Pointers of 1 * are useful (I leave it to the reader to convince
>>> themselves of this).
>>>
>>> Therefore, pointers of any number of *s are useful.
>>>
>>
>> the fact is hovever that a pointer to pointer to pointer to pointer to pointer is simply a pointer (that carries soem typisation) and as to my eye giving the * ** *** **** ***** etc all for * looks like some exagerration to me
>>
>> hovever this type info seem to be useful as normal type safety guard so i dont know
>
> there are also more subtle and contextual things as to this (that suggests me something is wrong here, for example if i look on things like that
>
> char** zz = {"ala","ma","kota"};
>
> foo(char** zz)
> but this is more subtle and i dont quite remember the details (of what i really think on this, those pointers are kinda mess)
>
C uses * where it could be using []. Your {"ala","ma","kota"} example
can also be considered to be an array of arrays:
char zz[][5]={"ala","ma","kota"};
That's another reason there are more * around because people prefer * to
[], even before you need * to get an actual pointer, and before you need
yet another * to pass a pointer by reference.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-08 00:27 -0800 |
| Message-ID | <eca60500-a159-49e1-ab07-4f41f3236173@googlegroups.com> |
| In reply to | #148868 |
W dniu wtorek, 7 stycznia 2020 23:31:57 UTC+1 użytkownik Bart napisał:
> On 07/01/2020 22:22, fir wrote:
> > W dniu wtorek, 7 stycznia 2020 23:01:21 UTC+1 użytkownik fir napisał:
> >> W dniu wtorek, 7 stycznia 2020 22:53:20 UTC+1 użytkownik Kenny McCormack napisał:
> >>> In article <7C6RF.2207$4c1.1692@fx31.am4>, Bart <bc@freeuk.com> wrote:
> >>>> On 07/01/2020 20:47, fir wrote:
> >>>>
> >>>>> some of my conclusions/hypothesis afair was pointers ale generaly much overused
> >>>> in c language, that probably double (**) and triple (***) etc pointers have no
> >>>> sense
> >>>>
> >>>> Plenty of uses for those. Eg:
> >>>
> >>> A pretty good inductive proof for the utility of pointers with any number
> >>> of *s is this:
> >>>
> >>> 1) If you have a pointer P of X *s, and you want to pass it into a
> >>> function and have the function modify that pointer, then you need
> >>> to pass the address of P (i.e., &P) to the function. The function
> >>> will declare the received paramter to be a pointer of (X+1) *s.
> >>>
> >>> Therefore, if pointers of X *s are useful, then so are pointers of
> >>> (X+1) *s.
> >>>
> >>> 2) Pointers of 1 * are useful (I leave it to the reader to convince
> >>> themselves of this).
> >>>
> >>> Therefore, pointers of any number of *s are useful.
> >>>
> >>
> >> the fact is hovever that a pointer to pointer to pointer to pointer to pointer is simply a pointer (that carries soem typisation) and as to my eye giving the * ** *** **** ***** etc all for * looks like some exagerration to me
> >>
> >> hovever this type info seem to be useful as normal type safety guard so i dont know
> >
> > there are also more subtle and contextual things as to this (that suggests me something is wrong here, for example if i look on things like that
> >
> > char** zz = {"ala","ma","kota"};
> >
> > foo(char** zz)
> > but this is more subtle and i dont quite remember the details (of what i really think on this, those pointers are kinda mess)
> >
>
> C uses * where it could be using []. Your {"ala","ma","kota"} example
> can also be considered to be an array of arrays:
>
> char zz[][5]={"ala","ma","kota"};
>
> That's another reason there are more * around because people prefer * to
> [], even before you need * to get an actual pointer, and before you need
> yet another * to pass a pointer by reference.
ye i know, i mean it seems top me there is something wrong here (or even very wrong) but its hard to say what as for the moment
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-08 08:13 -0800 |
| Message-ID | <eee8c626-2554-46eb-bc53-c660a2ffcc8c@googlegroups.com> |
| In reply to | #148868 |
W dniu wtorek, 7 stycznia 2020 23:31:57 UTC+1 użytkownik Bart napisał:
> On 07/01/2020 22:22, fir wrote:
> > W dniu wtorek, 7 stycznia 2020 23:01:21 UTC+1 użytkownik fir napisał:
> >> W dniu wtorek, 7 stycznia 2020 22:53:20 UTC+1 użytkownik Kenny McCormack napisał:
> >>> In article <7C6RF.2207$4c1.1692@fx31.am4>, Bart <bc@freeuk.com> wrote:
> >>>> On 07/01/2020 20:47, fir wrote:
> >>>>
> >>>>> some of my conclusions/hypothesis afair was pointers ale generaly much overused
> >>>> in c language, that probably double (**) and triple (***) etc pointers have no
> >>>> sense
> >>>>
> >>>> Plenty of uses for those. Eg:
> >>>
> >>> A pretty good inductive proof for the utility of pointers with any number
> >>> of *s is this:
> >>>
> >>> 1) If you have a pointer P of X *s, and you want to pass it into a
> >>> function and have the function modify that pointer, then you need
> >>> to pass the address of P (i.e., &P) to the function. The function
> >>> will declare the received paramter to be a pointer of (X+1) *s.
> >>>
> >>> Therefore, if pointers of X *s are useful, then so are pointers of
> >>> (X+1) *s.
> >>>
> >>> 2) Pointers of 1 * are useful (I leave it to the reader to convince
> >>> themselves of this).
> >>>
> >>> Therefore, pointers of any number of *s are useful.
> >>>
> >>
> >> the fact is hovever that a pointer to pointer to pointer to pointer to pointer is simply a pointer (that carries soem typisation) and as to my eye giving the * ** *** **** ***** etc all for * looks like some exagerration to me
> >>
> >> hovever this type info seem to be useful as normal type safety guard so i dont know
> >
> > there are also more subtle and contextual things as to this (that suggests me something is wrong here, for example if i look on things like that
> >
> > char** zz = {"ala","ma","kota"};
> >
> > foo(char** zz)
> > but this is more subtle and i dont quite remember the details (of what i really think on this, those pointers are kinda mess)
> >
>
> C uses * where it could be using []. Your {"ala","ma","kota"} example
> can also be considered to be an array of arrays:
>
> char zz[][5]={"ala","ma","kota"};
>
> That's another reason there are more * around because people prefer * to
> [], even before you need * to get an actual pointer, and before you need
> yet another * to pass a pointer by reference.
ye i know what i typed could maybe even nopt compile (not bother to check), i only wanted to ilustrate what i mean is probably wrong in c
obviously when people pass things they more like mean array not pointer and as pointer is radically different thing than array this mean this is generally wrong
for example here {"ala","ma","kota"};
is an array of arrays having its sizes
so reducing it to the pointer is a sin
also if you pass to function some internal element of an array the whole type information on thi is not only tthat this elemant is say pointer to pointer to double but also which exactly element it is in what container
maybe most often that upper part of type info is not needed but im not sure if those are all cases, (and even if so this is good to rethink that things)
oereally this is damn mess, but it is so much mess its hard to say what exactly should be done to improve/repair it
[toc] | [prev] | [next] | [standalone]
| From | chad <cdalten@gmail.com> |
|---|---|
| Date | 2020-01-07 06:33 -0800 |
| Message-ID | <1cc05a7b-0f43-42f0-b913-90c7773d73a6@googlegroups.com> |
| In reply to | #148840 |
On Tuesday, January 7, 2020 at 6:24:37 AM UTC-8, fir wrote: > W dniu wtorek, 7 stycznia 2020 11:08:25 UTC+1 użytkownik Bart napisał: > > On 07/01/2020 06:32, Keith Thompson wrote: > > > Bart <bc@freeuk.com> writes: > > >> On 07/01/2020 00:33, F Russell wrote: > > >>> On Sun, 05 Jan 2020 12:25:33 -0800, Keith Thompson wrote: > > >>>> No, arrays are not pointers. An array variable holds an array object. > > >>>> The name of an array variable, in most but not all contexts, is treated > > >>>> as an array expression. > > >>> > > >>> That may be so, but for practical purposes they sure do act > > >>> exactly like pointers. > > >> > > >> C doesn't like treating arrays as actual arrays, eg. an int[10] as a > > >> block of 10 ints or 40 bytes. So at the faintest hint of that > > >> happening in an expression (a proper expression not those special > > >> sizeof(A) and &A operators), then it will instead yield a pointer to > > >> the first element: > > >> > > >> int A[10]; // A is an actual array of 10 ints > > >> int *B; // B is a pointer to the first of multiple ints > > >> int (*C)[10]; // C is a pointer to an array of 10 ints > > >> > > >> Now try and evaluate the whole array: > > >> > > >> A; // The whole array > > >> B; // A int pointer so can't access whole array > > >> (*C); // The whole array > > >> > > >> But this is the code generated in each case (evaluation just loads the > > >> result into a register then ignores it); A, B, C are all static: > > >> > > > [snip] > > >> > > >> So here, for A, it just loads the address of that array. For B, it > > >> just loads the pointer. But for C, it also loads the pointer, ignoring > > >> your instruction to dereference that pointer. > > >> > > >> As you can see however, array A actually exists as a > > >> 40-byte/10-element sequence. B and C are actually pointers which your > > >> code needs to initialise to point to a space that can contain a > > >> 40-byte/10-element array. > > > > > > As usual, you describe the semantics in a way designed to make it look > > > confusing rather than trying to help anyone understand it. > > > > Less confusing that your explanation. > > > > I said that C will resort to deriving a pointer as soon as any attempt > > is made to load a full array value. > > > > (and mostly code tjhat uses arrays need only an edresses not pointers) > My stupid polish friend, I think you should attempt to do 85% of the coding problems on codingbat.com After that, you will realize how so wrong you are. And I say attempt, because some of those programming problems that involve arrays are hard. Really hard. You might not think so when you look at them. But attempting to get the solution to the problem for *every* test case, using the set of constraints set out by the author makes you really think hard about the solution to problem.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-07 06:38 -0800 |
| Message-ID | <b730ba6f-e47f-457a-89a8-b3952eca735c@googlegroups.com> |
| In reply to | #148843 |
W dniu wtorek, 7 stycznia 2020 15:33:31 UTC+1 użytkownik chad napisał: > On Tuesday, January 7, 2020 at 6:24:37 AM UTC-8, fir wrote: > > W dniu wtorek, 7 stycznia 2020 11:08:25 UTC+1 użytkownik Bart napisał: > > > On 07/01/2020 06:32, Keith Thompson wrote: > > > > Bart <bc@freeuk.com> writes: > > > >> On 07/01/2020 00:33, F Russell wrote: > > > >>> On Sun, 05 Jan 2020 12:25:33 -0800, Keith Thompson wrote: > > > >>>> No, arrays are not pointers. An array variable holds an array object. > > > >>>> The name of an array variable, in most but not all contexts, is treated > > > >>>> as an array expression. > > > >>> > > > >>> That may be so, but for practical purposes they sure do act > > > >>> exactly like pointers. > > > >> > > > >> C doesn't like treating arrays as actual arrays, eg. an int[10] as a > > > >> block of 10 ints or 40 bytes. So at the faintest hint of that > > > >> happening in an expression (a proper expression not those special > > > >> sizeof(A) and &A operators), then it will instead yield a pointer to > > > >> the first element: > > > >> > > > >> int A[10]; // A is an actual array of 10 ints > > > >> int *B; // B is a pointer to the first of multiple ints > > > >> int (*C)[10]; // C is a pointer to an array of 10 ints > > > >> > > > >> Now try and evaluate the whole array: > > > >> > > > >> A; // The whole array > > > >> B; // A int pointer so can't access whole array > > > >> (*C); // The whole array > > > >> > > > >> But this is the code generated in each case (evaluation just loads the > > > >> result into a register then ignores it); A, B, C are all static: > > > >> > > > > [snip] > > > >> > > > >> So here, for A, it just loads the address of that array. For B, it > > > >> just loads the pointer. But for C, it also loads the pointer, ignoring > > > >> your instruction to dereference that pointer. > > > >> > > > >> As you can see however, array A actually exists as a > > > >> 40-byte/10-element sequence. B and C are actually pointers which your > > > >> code needs to initialise to point to a space that can contain a > > > >> 40-byte/10-element array. > > > > > > > > As usual, you describe the semantics in a way designed to make it look > > > > confusing rather than trying to help anyone understand it. > > > > > > Less confusing that your explanation. > > > > > > I said that C will resort to deriving a pointer as soon as any attempt > > > is made to load a full array value. > > > > > > > > > (and mostly code tjhat uses arrays need only an edresses not pointers) > > > > My stupid polish friend, I think you you got no friends here deeply pathological moron..rather people who find you quite properly as a disgustuing piece of living moron &&
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-07 06:49 -0800 |
| Message-ID | <26947900-df40-4f8d-8d02-abd6b4f2df1a@googlegroups.com> |
| In reply to | #148844 |
W dniu wtorek, 7 stycznia 2020 15:38:37 UTC+1 użytkownik fir napisał: > W dniu wtorek, 7 stycznia 2020 15:33:31 UTC+1 użytkownik chad napisał: > > On Tuesday, January 7, 2020 at 6:24:37 AM UTC-8, fir wrote: > > > W dniu wtorek, 7 stycznia 2020 11:08:25 UTC+1 użytkownik Bart napisał: > > > > On 07/01/2020 06:32, Keith Thompson wrote: > > > > > Bart <bc@freeuk.com> writes: > > > > >> On 07/01/2020 00:33, F Russell wrote: > > > > >>> On Sun, 05 Jan 2020 12:25:33 -0800, Keith Thompson wrote: > > > > >>>> No, arrays are not pointers. An array variable holds an array object. > > > > >>>> The name of an array variable, in most but not all contexts, is treated > > > > >>>> as an array expression. > > > > >>> > > > > >>> That may be so, but for practical purposes they sure do act > > > > >>> exactly like pointers. > > > > >> > > > > >> C doesn't like treating arrays as actual arrays, eg. an int[10] as a > > > > >> block of 10 ints or 40 bytes. So at the faintest hint of that > > > > >> happening in an expression (a proper expression not those special > > > > >> sizeof(A) and &A operators), then it will instead yield a pointer to > > > > >> the first element: > > > > >> > > > > >> int A[10]; // A is an actual array of 10 ints > > > > >> int *B; // B is a pointer to the first of multiple ints > > > > >> int (*C)[10]; // C is a pointer to an array of 10 ints > > > > >> > > > > >> Now try and evaluate the whole array: > > > > >> > > > > >> A; // The whole array > > > > >> B; // A int pointer so can't access whole array > > > > >> (*C); // The whole array > > > > >> > > > > >> But this is the code generated in each case (evaluation just loads the > > > > >> result into a register then ignores it); A, B, C are all static: > > > > >> > > > > > [snip] > > > > >> > > > > >> So here, for A, it just loads the address of that array. For B, it > > > > >> just loads the pointer. But for C, it also loads the pointer, ignoring > > > > >> your instruction to dereference that pointer. > > > > >> > > > > >> As you can see however, array A actually exists as a > > > > >> 40-byte/10-element sequence. B and C are actually pointers which your > > > > >> code needs to initialise to point to a space that can contain a > > > > >> 40-byte/10-element array. > > > > > > > > > > As usual, you describe the semantics in a way designed to make it look > > > > > confusing rather than trying to help anyone understand it. > > > > > > > > Less confusing that your explanation. > > > > > > > > I said that C will resort to deriving a pointer as soon as any attempt > > > > is made to load a full array value. > > > > > > > > > > > > > > (and mostly code tjhat uses arrays need only an edresses not pointers) > > > > > > > My stupid polish friend, I think you > > you got no friends here deeply pathological moron..rather people who find you quite properly as a disgustuing piece of living moron && btw people dont like living and walking morons like you or dik hodgin who walk and infect people with yours deep animal level of stupidity (this is one of the rare thing that can be said good about people) from the same reason they like those who learn them to be a bit more wiser (thats why i got so numerous and so strong fans)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-07 16:38 +0000 |
| Message-ID | <Xt2RF.167043$382.86803@fx01.am4> |
| In reply to | #148840 |
On 07/01/2020 14:24, fir wrote: > W dniu wtorek, 7 stycznia 2020 11:08:25 UTC+1 użytkownik Bart napisał: >> I said that C will resort to deriving a pointer as soon as any attempt >> is made to load a full array value. >> > > > youre wrong here in close or the seme type of being wrong as people who say array is a pointer > > what c will 'derive' (if use this word ) > is nota pointer, it is and adress > > adress is quite different thing than pointer, adres for example may be only as immediate value in code section of assembly , or being crafted from some arithmetic and being calculete in register as final results, or some simply also may thing that it is something in a head of a programmer (though if you would like to use value it will need to be provided physically etc), but adress is nota a pointer, same as array is not a pointer ;c (and mostly code tjhat uses arrays need only an edresses not pointers) For this purpose, address and pointer may be used interchangeably. Technically, in C a pointer is an address with type information. Whether it appears in machine code as an immediate address or is loaded from memory, is not relevant. In my example, as far as C is concerned, A, B and *C all end up with type int* - /pointer/ to int. It's not called /address/ of int.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-07 10:31 -0800 |
| Message-ID | <87v9pnktim.fsf@nosuchdomain.example.com> |
| In reply to | #148848 |
Bart <bc@freeuk.com> writes:
[...]
> For this purpose, address and pointer may be used
> interchangeably. Technically, in C a pointer is an address with type
> information.
Technically, in C an address has type information. The standard
doesn't have a formal definition of "address", and some of its uses
are a little ambiguous, but in most cases it refers to a value of
pointer type.
For example, the unary & operator "yields the address of its
operand". That's a typed value of pointer type.
Informally, an address is a value of pointer type (probably excluding
null pointer, invalid pointers, and pointers just past the end of
an object).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-07 10:44 -0800 |
| Message-ID | <20025457-e45c-4e24-ac0b-402ce946889f@googlegroups.com> |
| In reply to | #148855 |
W dniu wtorek, 7 stycznia 2020 19:31:55 UTC+1 użytkownik Keith Thompson napisał: > Bart <bc@freeuk.com> writes: > [...] > > For this purpose, address and pointer may be used > > interchangeably. Technically, in C a pointer is an address with type > > information. > > Technically, in C an address has type information. The standard > doesn't have a formal definition of "address", and some of its uses > are a little ambiguous, but in most cases it refers to a value of > pointer type. > > For example, the unary & operator "yields the address of its > operand". That's a typed value of pointer type. > > Informally, an address is a value of pointer type (probably excluding > null pointer, invalid pointers, and pointers just past the end of > an object). > adress is an adress (nomen omen) value describing where this or that thing is placed in RAM (adress is extremally fundamental thing in computing as ram is adresses and values) pointer is far far les fundamental thing i didint seen at pointer as a adress that has type information (this is somewhat right as at least some pointers hae a type information and carry adresses) imo what defines pointer more is that it is "adress located in ram" (most if not all pointers are, there may be a bit of doubt what if pointer is located in register, imo if this is 'legal' formal c pointer that is declared register register int* pi; this is also a pointer, but if this is some informal adress generated and carried by compiler under the hood of c code where it is not seen as a pointer i probably wouldnt all that thisng as pointer, maybe some distinct name would be more proper on that thing
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-07 19:54 +0100 |
| Message-ID | <qv2k5p$mkq$1@dont-email.me> |
| In reply to | #148855 |
On 07/01/2020 19:31, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> For this purpose, address and pointer may be used >> interchangeably. Technically, in C a pointer is an address with type >> information. > > Technically, in C an address has type information. The standard > doesn't have a formal definition of "address", and some of its uses > are a little ambiguous, but in most cases it refers to a value of > pointer type. > > For example, the unary & operator "yields the address of its > operand". That's a typed value of pointer type. > > Informally, an address is a value of pointer type (probably excluding > null pointer, invalid pointers, and pointers just past the end of > an object). > Also note that in C, use of & does not necessarily imply that the object in question has a "memory location" (or an address in memory). Since the standard doesn't define this sort of thing, compilers are free to handle them however they want. Given "int x, y;" a compiler can treat "x = *&y;" exactly like "x = y;" - evaluating "&y" as "the address of y" does not imply that "y" must reside in memory somewhere, rather than a register.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-11 10:24 -0800 |
| Message-ID | <86lfqd26mc.fsf@linuxsc.com> |
| In reply to | #148855 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Bart <bc@freeuk.com> writes: > [...] > >> For this purpose, address and pointer may be used >> interchangeably. Technically, in C a pointer is an address with type >> information. > > Technically, in C an address has type information. The standard > doesn't have a formal definition of "address", and some of its uses > are a little ambiguous, but in most cases it refers to a value of > pointer type. > > For example, the unary & operator "yields the address of its > operand". That's a typed value of pointer type. > > Informally, an address is a value of pointer type (probably excluding > null pointer, invalid pointers, and pointers just past the end of > an object). I don't agree with this interpretation. If we look at all the places the word "address" is used in the C standard, it doesn't fit many of them (and I think it doesn't fit most of them but I haven't checked that carefully). Furthermore I strongly suspect the term "address" is defined in one of the C standard's normative references. If it is, then the normative reference surely would not include any information about a type in C. A better interpretation IMO is that "address" just means an address as the term is usually used when talking about computer hardware, and a pointer value includes an address (in some representation) but isn't necessarily just an address. Note also that pointer _values_ don't have any type information. A pointer-valued _expression_ has some type information, but that information exists only at compile time. Addresses are a run-time construct, not a compile-time construct -- even though in some cases some address values may be known at compile time, addresses are still a run-time construct. This means they do not have type information, which exists only at compile time.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-11 14:23 -0800 |
| Message-ID | <87h811k4yo.fsf@nosuchdomain.example.com> |
| In reply to | #148941 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>
>>> For this purpose, address and pointer may be used
>>> interchangeably. Technically, in C a pointer is an address with type
>>> information.
>>
>> Technically, in C an address has type information. The standard
>> doesn't have a formal definition of "address", and some of its uses
>> are a little ambiguous, but in most cases it refers to a value of
>> pointer type.
>>
>> For example, the unary & operator "yields the address of its
>> operand". That's a typed value of pointer type.
>>
>> Informally, an address is a value of pointer type (probably excluding
>> null pointer, invalid pointers, and pointers just past the end of
>> an object).
>
> I don't agree with this interpretation. If we look at all the
> places the word "address" is used in the C standard, it doesn't
> fit many of them (and I think it doesn't fit most of them but I
> haven't checked that carefully).
>
> Furthermore I strongly suspect the term "address" is defined in
> one of the C standard's normative references. If it is, then the
> normative reference surely would not include any information
> about a type in C.
>
> A better interpretation IMO is that "address" just means an address
> as the term is usually used when talking about computer hardware,
> and a pointer value includes an address (in some representation)
> but isn't necessarily just an address. Note also that pointer
> _values_ don't have any type information. A pointer-valued
> _expression_ has some type information, but that information exists
> only at compile time. Addresses are a run-time construct, not a
> compile-time construct -- even though in some cases some address
> values may be known at compile time, addresses are still a run-time
> construct. This means they do not have type information, which
> exists only at compile time.
In a quick scan through N1570 (not including section 7), I don't see
*any* uses of the term address that are inconsistent with my
interpretation, except perhaps in uses of the phrase "address space".
Some uses could be consistent with either your interpretation or mine.
The definition of the unary "&" operator certainly seems consistent with
my interpretation:
The unary & operator yields the address of its operand. If the
operand has type "type", the result has type "pointer to type.
I'm assuming that what it "yields" and "the result" refer to the same
thing.
In terms of the implementation, type *information* exists only at
compile time, but I think it's perfectly reasonable to talk about the
types of things that exist only at run time -- such as a "pointer
value".
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-21 04:21 -0800 |
| Message-ID | <86wo9lhuel.fsf@linuxsc.com> |
| In reply to | #148945 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Bart <bc@freeuk.com> writes: >>> [...] >>> >>>> For this purpose, address and pointer may be used >>>> interchangeably. Technically, in C a pointer is an address with type >>>> information. >>> >>> Technically, in C an address has type information. The standard >>> doesn't have a formal definition of "address", and some of its uses >>> are a little ambiguous, but in most cases it refers to a value of >>> pointer type. >>> >>> For example, the unary & operator "yields the address of its >>> operand". That's a typed value of pointer type. >>> >>> Informally, an address is a value of pointer type (probably excluding >>> null pointer, invalid pointers, and pointers just past the end of >>> an object). >> >> I don't agree with this interpretation. If we look at all the >> places the word "address" is used in the C standard, it doesn't >> fit many of them (and I think it doesn't fit most of them but I >> haven't checked that carefully). >> >> Furthermore I strongly suspect the term "address" is defined in >> one of the C standard's normative references. If it is, then the >> normative reference surely would not include any information >> about a type in C. >> >> A better interpretation IMO is that "address" just means an address >> as the term is usually used when talking about computer hardware, >> and a pointer value includes an address (in some representation) >> but isn't necessarily just an address. Note also that pointer >> _values_ don't have any type information. A pointer-valued >> _expression_ has some type information, but that information exists >> only at compile time. Addresses are a run-time construct, not a >> compile-time construct -- even though in some cases some address >> values may be known at compile time, addresses are still a run-time >> construct. This means they do not have type information, which >> exists only at compile time. > > In a quick scan through N1570 (not including section 7), I don't see > *any* uses of the term address that are inconsistent with my > interpretation, except perhaps in uses of the phrase "address space". > Some uses could be consistent with either your interpretation or mine. What I did is bring up a copy of the Standard in Adobe Reader, and use the search feature to find all occurrences of the word "address", including as part of another word and with no case differentiation. I went through the search results, looking carefully at each usage and its surrounding context. What I saw was consistent in every case with my reading but was in some cases was not consistent with your reading. If you go through a similar procedure and look carefully at every occurrence of searching for the string "address" I suspect you will find some that don't really fit with the idea that "address" is associated with type information.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-21 05:06 -0800 |
| Message-ID | <8211a10d-cb1e-43a6-ab50-d1293a8d5644@googlegroups.com> |
| In reply to | #149304 |
On Tuesday, January 21, 2020 at 7:21:46 AM UTC-5, Tim Rentsch wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: ... > > In a quick scan through N1570 (not including section 7), I don't see > > *any* uses of the term address that are inconsistent with my > > interpretation, except perhaps in uses of the phrase "address space". > > Some uses could be consistent with either your interpretation or mine. > > What I did is bring up a copy of the Standard in Adobe Reader, > and use the search feature to find all occurrences of the word > "address", including as part of another word and with no case > differentiation. I went through the search results, looking > carefully at each usage and its surrounding context. What I saw > was consistent in every case with my reading but was in some > cases was not consistent with your reading. If you go through a > similar procedure and look carefully at every occurrence of > searching for the string "address" I suspect you will find some > that don't really fit with the idea that "address" is associated > with type information. I think it's safe to assume that Keith has already carried out a very similar process, and his previous statements describe the results of doing so. A much more useful response would have been to identify specific examples of cases not consistent with Keith's reading. That way, if Keith disagrees with you about that inconsistency, he can explain why. With the approach you recommend, he'll read right past those same clauses without realizing that they're the ones you're talking about.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-07 10:59 -0800 |
| Message-ID | <173b1adc-198e-4dad-a805-b553a7ce17cc@googlegroups.com> |
| In reply to | #148848 |
W dniu wtorek, 7 stycznia 2020 17:38:25 UTC+1 użytkownik Bart napisał: > On 07/01/2020 14:24, fir wrote: > > W dniu wtorek, 7 stycznia 2020 11:08:25 UTC+1 użytkownik Bart napisał: > > >> I said that C will resort to deriving a pointer as soon as any attempt > >> is made to load a full array value. > >> > > > > > > youre wrong here in close or the seme type of being wrong as people who say array is a pointer > > > > what c will 'derive' (if use this word ) > > is nota pointer, it is and adress > > > > adress is quite different thing than pointer, adres for example may be only as immediate value in code section of assembly , or being crafted from some arithmetic and being calculete in register as final results, or some simply also may thing that it is something in a head of a programmer (though if you would like to use value it will need to be provided physically etc), but adress is nota a pointer, same as array is not a pointer ;c (and mostly code tjhat uses arrays need only an edresses not pointers) > > For this purpose, address and pointer may be used interchangeably. > Technically, in C a pointer is an address with type information. > > Whether it appears in machine code as an immediate address or is loaded > from memory, is not relevant. > > In my example, as far as C is concerned, A, B and *C all end up with > type int* - /pointer/ to int. It's not called /address/ of int. damn no, i think youre very wrong here, as i said saying this adres and pointer may be used interchangebly you say like array and pointer are like the same pointer is what you declare and place in ram, (generally), adress is something that is floating thru code (almost every thing in c has adress, each function, each variable, each label etc - but you mostly dont use pointers to all that) i suggest you should accept this great difference as this clears things a lot ..imo there is no way to defend a view that adress and pointers are like the same, (note for example pointer has usually like two adresses, one is the addres its carries, second is his own adress where it is placed, normal adresses are only one, ts hyst the adres of some thing - there is that case when you get a pointer in register, but it is a special case of pointer, it also carries the destination adress like normal pointer and has its own adress (so it is this case of 2 adresses), but this own adres is eax, ebx, esi , edi or something so this is kinda special case (maybe name it volatile pointer (?)) (and yet there are thing of this volatile pointers that are not formally declared in c source, this is yet some other case, as this is not suited to be managed by c coder in normal way i wouldnt name it as pointers on normal rights i think..eventually i should take closer look at that)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-07 19:21 +0000 |
| Message-ID | <9T4RF.3600$CO7.2973@fx36.am4> |
| In reply to | #148858 |
On 07/01/2020 18:59, fir wrote:
> damn no,
> i think youre very wrong here, as i said saying this adres and pointer may be used interchangebly you say like array and pointer are like the same
>
> pointer is what you declare and place in ram, (generally), adress is something that is floating thru code (almost every thing in c has adress, each function, each variable, each label etc - but you mostly dont use pointers to all that)
>
> i suggest you should accept this great difference as this clears things a lot ..imo there is no way to defend a view that adress and pointers are like the same, (note for example pointer has usually like two adresses, one is the addres its carries, second is his own adress where it is placed, normal adresses are only one, ts hyst the adres of some thing
>
> - there is that case when you get a pointer in register, but it is a special case of pointer, it also carries the destination adress like normal pointer and has its own adress (so it is this case of 2 adresses), but this own adres is eax, ebx, esi , edi or something so this is kinda special case (maybe name it volatile pointer (?)) (and yet there are thing of this volatile pointers that are not formally declared in c source, this is yet some other case, as this is not suited to be managed by c coder in normal way i wouldnt name it as pointers on normal rights i think..eventually i should take closer look at that)
>
I think you're getting tied up in knots here.
Is the value 00E3FF48 an address, or the value of a pointer, or can it
be both, or either?
Here:
int A
int *P = &A;
You seem to be saying &A is an address (say with value 00E3FF48 when it
runs), but it becomes a pointer as soon as store that value into P?
If the program hasn't been run, is it still meaningful to talk about an
address, when it doesn't yet exist?
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-07 11:36 -0800 |
| Message-ID | <fb287734-9387-4380-becd-45107340bad2@googlegroups.com> |
| In reply to | #148860 |
W dniu wtorek, 7 stycznia 2020 20:21:51 UTC+1 użytkownik Bart napisał:
> On 07/01/2020 18:59, fir wrote:
>
> > damn no,
> > i think youre very wrong here, as i said saying this adres and pointer may be used interchangebly you say like array and pointer are like the same
> >
> > pointer is what you declare and place in ram, (generally), adress is something that is floating thru code (almost every thing in c has adress, each function, each variable, each label etc - but you mostly dont use pointers to all that)
> >
> > i suggest you should accept this great difference as this clears things a lot ..imo there is no way to defend a view that adress and pointers are like the same, (note for example pointer has usually like two adresses, one is the addres its carries, second is his own adress where it is placed, normal adresses are only one, ts hyst the adres of some thing
> >
> > - there is that case when you get a pointer in register, but it is a special case of pointer, it also carries the destination adress like normal pointer and has its own adress (so it is this case of 2 adresses), but this own adres is eax, ebx, esi , edi or something so this is kinda special case (maybe name it volatile pointer (?)) (and yet there are thing of this volatile pointers that are not formally declared in c source, this is yet some other case, as this is not suited to be managed by c coder in normal way i wouldnt name it as pointers on normal rights i think..eventually i should take closer look at that)
> >
>
>
> I think you're getting tied up in knots here.
>
> Is the value 00E3FF48 an address, or the value of a pointer, or can it
> be both, or either?
>
> Here:
>
> int A
> int *P = &A;
>
> You seem to be saying &A is an address (say with value 00E3FF48 when it
> runs), but it becomes a pointer as soon as store that value into P?
>
> If the program hasn't been run, is it still meaningful to talk about an
> address, when it doesn't yet exist?
normally the adres is just an adres in ram where that thing is placed, so the adres is more like your head or fact on reality
&a is some expression used to pass and adres or assign it to pointer
i personally see that things like a, foo, label as adresses (i mean identifiers are generally adresses) so in that examples
void foo()
{
int A
int *P = &A;
}
foo, A and p cover adresses though P also a pointer (three adresses and one pointer)
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@delq.com> |
|---|---|
| Date | 2020-01-06 18:02 -0800 |
| Message-ID | <hho71flajr8m0gbvileb48masi2dmf2a1n@4ax.com> |
| In reply to | #148813 |
On 7 Jan 2020 00:33:41 GMT, F Russell <fr@random.info> wrote: >On Sun, 05 Jan 2020 12:25:33 -0800, Keith Thompson wrote: > >> >> No, arrays are not pointers. An array variable holds an array object. >> The name of an array variable, in most but not all contexts, is treated >> as an array expression. >> > >That may be so, but for practical purposes they sure do act >exactly like pointers. Many of us consider the use of the sizeof, assignment, and & operators to be extremely practical and "they" certainly don't act like pointers in those cases. -- Remove del for email
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web