Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #34668 > unrolled thread
| Started by | "James Harris \(es\)" <james.harris.1@gmail.com> |
|---|---|
| First post | 2013-07-30 11:02 +0100 |
| Last post | 2013-08-13 07:00 -0400 |
| Articles | 20 on this page of 281 — 28 participants |
Back to article view | Back to comp.lang.c
Sizes of pointers "James Harris \(es\)" <james.harris.1@gmail.com> - 2013-07-30 11:02 +0100
Re: Sizes of pointers Kleuske <kleuske@nowhere.net> - 2013-07-30 11:04 +0000
Re: Sizes of pointers Noob <root@127.0.0.1> - 2013-07-30 14:14 +0200
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-07-30 14:38 -0700
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-07-30 17:01 -0500
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-07-30 16:03 -0700
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-01 12:25 -0500
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-02 18:37 -0500
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-03 00:42 -0500
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-03 13:36 -0500
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-04 01:57 -0500
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-03 21:04 -0700
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-04 00:43 -0500
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-08 03:41 -0700
Re: Sizes of pointers Noob <root@127.0.0.1> - 2013-07-31 13:29 +0200
Re: Sizes of pointers Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-01 15:47 +0300
Re: Sizes of pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-07-30 13:09 +0100
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-07-30 08:11 -0400
Re: Sizes of pointers Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-30 08:33 -0400
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-07-30 08:38 -0500
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-07-30 11:54 -0700
Re: Sizes of pointers Bart van Ingen Schenau <bart@ingen.ddns.info.invalid> - 2013-08-01 15:45 +0000
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-01 12:16 -0400
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-01 18:37 +0000
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-01 21:29 -0500
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-01 22:43 -0500
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-02 00:48 -0500
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-02 10:44 -0700
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-02 13:33 -0500
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-02 14:46 -0400
Re: Sizes of pointers gazelle@shell.xmission.com (Kenny McCormack) - 2013-08-02 19:55 +0000
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-03 09:46 +0200
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-03 11:22 -0700
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-03 13:39 -0500
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-02 18:37 +0000
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-03 09:35 -0700
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-04 02:07 -0500
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-08 03:00 -0700
Re: Sizes of pointers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-08 05:39 -0700
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-08 16:00 -0700
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-08 13:27 +0000
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-08 16:06 -0700
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-09 00:49 -0500
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-18 19:49 -0700
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-19 13:02 -0500
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-03 09:30 -0700
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-03 08:59 -0700
Re: Sizes of pointers Bart van Ingen Schenau <bart@ingen.ddns.info.invalid> - 2013-08-04 17:55 +0000
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-08 02:41 -0700
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-07-30 14:52 -0700
Re: Sizes of pointers "James Harris \(es\)" <james.harris.1@gmail.com> - 2013-07-31 10:43 +0100
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-07-31 07:34 -0400
Re: Sizes of pointers Richard Damon <Richard@Damon-Family.org> - 2013-07-31 08:28 -0400
Re: Sizes of pointers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-07-31 16:54 -0700
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-07-31 19:30 +0200
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-01 12:29 -0500
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-01 13:54 -0400
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-01 19:01 +0000
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-01 21:50 -0500
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-02 03:22 +0000
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-02 01:35 -0500
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-04 01:24 -0500
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-01 23:31 -0400
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-02 01:04 -0500
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-02 16:25 +0000
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-02 09:29 +0200
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-02 10:51 -0700
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-02 14:43 -0400
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-02 14:39 -0700
Re: Sizes of pointers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-02 17:22 -0700
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-02 20:00 -0700
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-03 05:40 +0000
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-03 09:38 -0400
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-02 18:47 +0000
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-02 18:28 -0500
Re: Sizes of pointers christian.bau@cbau.wanadoo.co.uk - 2013-08-06 13:05 -0700
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-06 16:36 -0400
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-06 17:44 -0700
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-06 20:40 +0000
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-01 20:19 +0200
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-01 21:32 -0500
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-01 17:43 -0500
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-01 19:10 -0400
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-01 22:32 -0500
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-03 11:50 -0700
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-03 14:48 -0500
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-03 16:53 -0400
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-03 23:31 -0500
Re: Sizes of pointers Philip Lantz <prl@canterey.us> - 2013-08-03 23:56 -0700
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-09 20:53 +0200
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-09 21:18 +0200
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-08 10:39 -0700
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-08 11:29 -0700
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-08 17:09 -0700
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-09 00:33 +0000
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-19 01:08 -0700
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-13 11:58 -0500
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-20 17:16 -0700
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-09 19:50 +0000
[OT] Re: Sizes of pointers Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-09 16:28 -0400
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-10 09:51 +0200
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-10 10:46 +0200
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-02 09:24 +0200
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-02 16:35 +0000
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-02 17:47 -0500
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-04 03:58 -0700
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-04 09:17 -0500
Re: Sizes of pointers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-04 07:43 -0700
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-05 04:47 +0000
[OT] gravity James Kuyper <jameskuyper@verizon.net> - 2013-08-05 06:52 -0400
Re: [OT] gravity Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-05 11:29 -0700
Re: [OT] gravity James Kuyper <jameskuyper@verizon.net> - 2013-08-05 15:02 -0400
Re: [OT] gravity glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-05 18:42 +0000
Re: [OT] gravity Robert Wessel <robertwessel2@yahoo.com> - 2013-08-05 20:01 -0500
Re: [OT] gravity James Kuyper <jameskuyper@verizon.net> - 2013-08-05 23:34 -0400
Hidden Assumptions Re: [OT] gravity Siri Cruise <chine.bleu@yahoo.com> - 2013-08-05 22:12 -0700
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-04 19:40 +0200
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-04 15:18 -0500
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-04 15:02 -0700
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-04 18:47 -0500
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-04 19:40 -0700
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-05 04:53 +0000
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-04 22:44 -0700
Re: Sizes of pointers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-05 02:00 -0700
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-05 07:48 -0700
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-08 04:13 -0700
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-08 13:57 +0000
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-08 16:30 -0700
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-08 10:34 -0500
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-08 16:55 -0700
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-09 00:53 +0000
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-18 20:11 -0700
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-17 20:24 -0500
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-22 12:28 -0700
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-05 04:31 +0000
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-08 04:48 -0700
Re: Sizes of pointers Philip Lantz <prl@canterey.us> - 2013-08-17 14:41 -0700
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-21 13:04 -0700
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-05 23:16 -0500
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-06 01:01 -0500
Re: Sizes of pointers "James Harris" <james.harris.1@gmail.com> - 2013-08-06 10:11 +0100
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-06 07:20 -0500
Re: Sizes of pointers "James Harris" <james.harris.1@gmail.com> - 2013-08-06 15:33 +0100
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-06 14:23 -0500
Re: Sizes of pointers "James Harris" <james.harris.1@gmail.com> - 2013-08-06 23:18 +0100
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-06 23:45 +0000
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-07 05:59 -0500
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-07 16:44 +0000
Re: Sizes of pointers "James Harris \(es\)" <james.harris.1@gmail.com> - 2013-08-07 18:40 +0100
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-08 01:01 -0500
Re: Sizes of pointers "James Harris" <james.harris.1@gmail.com> - 2013-08-08 07:40 +0100
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-08 03:13 -0500
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-08 14:10 +0000
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-08 11:15 -0500
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-08 11:44 -0500
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-08 17:34 +0000
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-08 17:16 +0000
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-09 01:01 -0500
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-09 11:03 +0000
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-08 10:15 -0500
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-06 20:47 +0000
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-06 16:28 -0500
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-06 13:18 -0500
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-06 13:21 -0500
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-06 14:10 -0500
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-06 14:42 -0500
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-06 20:52 +0000
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-06 16:39 -0500
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-06 23:50 +0000
Re: Sizes of pointers Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-08 16:12 -0700
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-08 19:18 +0200
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-08 11:27 -0700
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-08 21:58 +0200
Re: Sizes of pointers Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2013-08-08 16:25 -0400
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-09 08:50 +0200
Re: Sizes of pointers Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2013-08-09 11:35 -0400
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-09 11:49 -0400
Re: Sizes of pointers Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2013-08-09 12:01 -0400
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-09 10:55 -0700
Re: Sizes of pointers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-09 09:04 -0700
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-09 19:23 +0200
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-09 18:42 +0000
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-09 15:12 -0400
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-09 19:56 +0000
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-09 16:28 -0400
Re: Sizes of pointers christian.bau@cbau.wanadoo.co.uk - 2013-08-10 18:26 -0700
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-08 13:40 -0700
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-08 21:30 -0400
Re: Sizes of pointers Ike Naar <ike@iceland.freeshell.org> - 2013-08-10 05:52 +0000
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-10 09:54 +0200
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-10 07:46 -0400
Re: Sizes of pointers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-10 04:54 -0700
Re: Sizes of pointers David Brown <david.brown@removethis.hesbynett.no> - 2013-08-10 14:51 +0200
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-10 11:12 -0700
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-10 19:14 +0000
Re: Sizes of pointers Richard Damon <Richard@Damon-Family.org> - 2013-08-10 20:39 -0400
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-10 20:29 -0700
Re: Sizes of pointers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-10 21:51 -0700
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-11 05:47 +0000
Re: Sizes of pointers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-10 23:15 -0700
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-11 02:20 -0700
Re: Sizes of pointers Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-11 18:53 -0600
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-09 16:46 +0200
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-09 08:12 +0200
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-09 14:04 -0700
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-10 10:45 +0200
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-10 11:14 -0700
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-02 10:34 +0200
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-02 18:12 -0500
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-03 07:04 +0200
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-03 07:07 +0200
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-03 09:46 +0200
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-03 11:25 -0700
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-03 00:50 -0500
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-03 09:57 +0200
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-04 01:38 -0500
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-03 13:12 -0500
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-04 19:40 +0200
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-04 14:40 -0500
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-04 14:24 -0700
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-05 19:31 +0200
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-05 19:51 +0200
Re: Sizes of pointers Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-05 14:20 -0400
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-05 21:57 +0200
Re: Sizes of pointers Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-05 16:21 -0400
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-05 16:39 -0500
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-06 07:00 +0200
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-06 01:18 -0500
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-06 09:23 +0200
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-06 09:54 +0200
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-06 12:40 -0500
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-06 06:44 -0500
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-06 08:06 -0700
Re: Sizes of pointers gazelle@shell.xmission.com (Kenny McCormack) - 2013-08-06 15:48 +0000
Re: Sizes of pointers "James Harris" <james.harris.1@gmail.com> - 2013-08-06 10:17 +0100
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-06 06:58 -0500
Re: Sizes of pointers "James Harris" <james.harris.1@gmail.com> - 2013-08-06 15:44 +0100
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-06 14:29 -0500
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-06 21:08 +0000
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-06 16:52 -0500
Re: Sizes of pointers "James Harris" <james.harris.1@gmail.com> - 2013-08-06 23:29 +0100
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-06 21:06 +0000
Re: Sizes of pointers Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-06 08:16 -0400
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-06 09:19 +0200
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-06 06:53 -0500
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-06 18:34 +0200
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-08 01:17 -0500
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-05 22:00 +0000
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-05 22:15 -0500
Re: Sizes of pointers Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-06 08:37 -0400
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-06 21:18 +0000
Re: Sizes of pointers Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-06 18:08 -0400
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-07 00:09 +0000
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-06 09:20 +0200
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-06 06:54 -0500
Re: Sizes of pointers "James Harris" <james.harris.1@gmail.com> - 2013-08-06 10:41 +0100
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-06 08:37 -0400
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-06 08:06 -0500
Re: Sizes of pointers Herbert Rosenau <os2guy@pc-rosenau.de> - 2013-08-12 14:26 +0200
Re: Sizes of pointers Keith Thompson <kst-u@mib.org> - 2013-08-12 09:13 -0700
Re: Sizes of pointers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-12 10:19 -0700
Re: Sizes of pointers Rosario1903 <Rosario@invalid.invalid> - 2013-08-12 18:39 +0200
Re: Sizes of pointers "James Harris" <james.harris.1@gmail.com> - 2013-08-06 15:52 +0100
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-06 11:38 -0400
Re: Sizes of pointers "James Harris" <james.harris.1@gmail.com> - 2013-08-06 17:17 +0100
Re: Sizes of pointers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-06 10:31 -0700
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-06 21:26 +0000
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-06 21:21 +0000
Re: Sizes of pointers Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-06 08:49 -0400
Re: Sizes of pointers "James Harris" <james.harris.1@gmail.com> - 2013-08-06 16:12 +0100
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-06 21:36 +0000
Re: Sizes of pointers Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-07 16:38 +0300
Re: Sizes of pointers Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-07 17:02 +0300
Re: Sizes of pointers Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2013-08-07 11:01 +0200
Re: Sizes of pointers "James Harris" <james.harris.1@gmail.com> - 2013-08-07 10:41 +0100
Re: Sizes of pointers Robert Wessel <robertwessel2@yahoo.com> - 2013-08-07 07:57 -0500
Re: Sizes of pointers glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-07 16:48 +0000
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-03 10:07 -0400
Re: Sizes of pointers Stephen Sprunk <stephen@sprunk.org> - 2013-08-03 13:47 -0500
Re: Sizes of pointers 赟 张 <cloud.poster@gmail.com> - 2013-08-13 00:16 -0700
Re: Sizes of pointers James Kuyper <jameskuyper@verizon.net> - 2013-08-13 07:00 -0400
Page 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
| From | Rosario1903 <Rosario@invalid.invalid> |
|---|---|
| Date | 2013-08-09 19:23 +0200 |
| Message-ID | <b99a099nid7r0f1cplrcp6g68pia2ku572@4ax.com> |
| In reply to | #35187 |
On Fri, 09 Aug 2013 11:35:44 -0400, Lew Pitcher wrote: >On Friday 09 August 2013 02:50, in comp.lang.c, Rosario@invalid.invalid >wrote: > >> On Thu, 08 Aug 2013 16:25:34 -0400, Lew Pitcher wrote: >> >> in other words you claim >> that mathematic is not the reason all run right, >> that mathematic is not more smart than each one of us > >No. YOU claim that I claimed the above. I said no such thing. Reread what I >wrote, and learn. excuse me, i would see or think something not exist... >> so what other model for aligned pointers? > >I don't understand your question. Perhaps you need to rephrase it.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-08-09 18:42 +0000 |
| Message-ID | <ku3d6d$2n8$1@speranza.aioe.org> |
| In reply to | #35187 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: > On Friday 09 August 2013 02:50, in comp.lang.c, Rosario@invalid.invalid (snip on modulo and pointers) >> in other words you claim >> that mathematic is not the reason all run right, >> that mathematic is not more smart than each one of us > No. YOU claim that I claimed the above. I said no such thing. > Reread what I wrote, and learn. >> so what other model for aligned pointers? > I don't understand your question. Perhaps you need to rephrase it. (snip) > If you are referring to how the C code of an application program can > establish proper alignment of pointers, then there's a simple > answer: A C application should not attempt to *explicitly* > determine alignment. > Instead, it should depend on the C language to do that for it. > malloc()ed memory is guaranteed (by the C standard) to be > allocated such that it suits any system/compiler/runtime-imposed > alignment requirements. As well as I understand it, it should satisfy the alignment requirements, but isn't necessarily optimal. A processor might slow down for some alignment, and the is no requirement that C avoid such slow alignments. I suppose that goes under quality of implementation, but some might be disapointed with the results. -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-09 15:12 -0400 |
| Message-ID | <52053F11.5010900@verizon.net> |
| In reply to | #35196 |
On 08/09/2013 02:42 PM, glen herrmannsfeldt wrote: > Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: ... >> If you are referring to how the C code of an application program can >> establish proper alignment of pointers, then there's a simple >> answer: A C application should not attempt to *explicitly* >> determine alignment. >> Instead, it should depend on the C language to do that for it. >> malloc()ed memory is guaranteed (by the C standard) to be >> allocated such that it suits any system/compiler/runtime-imposed >> alignment requirements. > > As well as I understand it, it should satisfy the alignment > requirements, but isn't necessarily optimal. A processor might > slow down for some alignment, and the is no requirement that C > avoid such slow alignments. The C standard imposes no such requirement; but market forces favor vendors who create C implementations that impose alignment requirements that reasonably reflect the impact of mis-aligned access. Impose a stricter alignment than necessary, and the generated code wastes memory; impose too lenient of an alignment, and the generated code wastes time on mis-aligned access. A vendor who doesn't pay attention to it's customer's preferences with regard to time vs. memory space trade-offs will lose business to one who does. That includes giving them optimization options to adjust those preferences.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-08-09 19:56 +0000 |
| Message-ID | <ku3hi4$eei$1@speranza.aioe.org> |
| In reply to | #35199 |
James Kuyper <jameskuyper@verizon.net> wrote: (snip on alignment requirements) >> As well as I understand it, it should satisfy the alignment >> requirements, but isn't necessarily optimal. A processor might >> slow down for some alignment, and the is no requirement that C >> avoid such slow alignments. > The C standard imposes no such requirement; but market forces favor > vendors who create C implementations that impose alignment requirements > that reasonably reflect the impact of mis-aligned access. Impose a > stricter alignment than necessary, and the generated code wastes memory; > impose too lenient of an alignment, and the generated code wastes time > on mis-aligned access. A vendor who doesn't pay attention to it's > customer's preferences with regard to time vs. memory space trade-offs > will lose business to one who does. That includes giving them > optimization options to adjust those preferences. And hardware can progress faster than software can keep up. For the 8087, only two byte alignment mattered for floating point, for the 80486, four byte alignment was faster, and, on the pentium and later eight byte alignment for double was significantly faster. Yet C implementations were doing four byte alignment well into the pentium and later days. (Hopefully fixed by now.) -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-09 16:28 -0400 |
| Message-ID | <520550D7.1080007@verizon.net> |
| In reply to | #35204 |
On 08/09/2013 03:56 PM, glen herrmannsfeldt wrote: > James Kuyper <jameskuyper@verizon.net> wrote: ... >> The C standard imposes no such requirement; but market forces favor >> vendors who create C implementations that impose alignment requirements >> that reasonably reflect the impact of mis-aligned access. Impose a >> stricter alignment than necessary, and the generated code wastes memory; >> impose too lenient of an alignment, and the generated code wastes time >> on mis-aligned access. A vendor who doesn't pay attention to it's >> customer's preferences with regard to time vs. memory space trade-offs >> will lose business to one who does. That includes giving them >> optimization options to adjust those preferences. > > And hardware can progress faster than software can keep up. > > For the 8087, only two byte alignment mattered for floating point, > for the 80486, four byte alignment was faster, and, on the pentium > and later eight byte alignment for double was significantly faster. > > Yet C implementations were doing four byte alignment well into > the pentium and later days. (Hopefully fixed by now.) If imposing stricter alignment requirements to achieve better processing speeds would have won an implementor enough new customers to cover the development costs, some implementor would have done so. A situation like that can exist only if users are sufficiently apathetic about the issue that they don't impose effective pressure on the implementors. And if the users are that apathetic about the issue, does it really matter?
[toc] | [prev] | [next] | [standalone]
| From | christian.bau@cbau.wanadoo.co.uk |
|---|---|
| Date | 2013-08-10 18:26 -0700 |
| Message-ID | <74618860-df55-4c9f-857a-6d9793bacec6@googlegroups.com> |
| In reply to | #35204 |
On Friday, August 9, 2013 8:56:53 PM UTC+1, glen herrmannsfeldt wrote: > And hardware can progress faster than software can keep up. > > For the 8087, only two byte alignment mattered for floating point, > for the 80486, four byte alignment was faster, and, on the pentium > and later eight byte alignment for double was significantly faster. > Yet C implementations were doing four byte alignment well into > the pentium and later days. (Hopefully fixed by now.) Last time I tested (on a Core 2 Duo) alignment didn't matter at all (I didn't check odd bytes, only even). The hardware instructions for loading and storing extended precision numbers read 10 bytes. But C compilers insist on sizeof (long double) = 16 which wastes space, and will often slow down things because memory bandwidth is wasted.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-08 13:40 -0700 |
| Message-ID | <ln38qjq5k8.fsf@nuthaus.mib.org> |
| In reply to | #35141 |
Rosario1903 <Rosario@invalid.invalid> writes:
> On Thu, 08 Aug 2013 11:27:57 -0700, Keith Thompson wrote:
>>Rosario1903 <Rosario@invalid.invalid> writes:
>>> On Fri, 2 Aug 2013 16:35:35 +0000 (UTC), glen herrmannsfeldt wrote:
>>> yes it seems here that all operation +-* are the same between unsigned
>>> and int
>>
>>Not exactly. An implementation that uses a 2's-complement
>>representation for signed integers *can* use the same instructions for
>>signed vs. unsigned addition, subtraction, and multiplication, because
>>the behavior of signed overflow is undefined.
> ...
>>> what change, it is the division, operation "/"
>>>
>>> but someone say it is not used in pointer aritmetic
>>> [i would use & or % for see if one address is short alighed, int
>>> aligned, double aligned etc]
>>
>>Would you really? And what do you think would happen if you tried to
>>apply the "%" operator to a pointer value?
>
> i would know what happen here: the result for example address%8
> would be
> 1 if mem is char aligned
> 2 if mem is short and char aligned
> 4 if mem is int, short, char aligned
> 0 if mem is double aligned etc
You are mistaken. The result would be an error message from the
compiler. C doesn't define the "%" operator for pointers.
If you're talking about something other than C, you're in the wrong
place.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-08 21:30 -0400 |
| Message-ID | <ku1gnk$h9q$1@dont-email.me> |
| In reply to | #35144 |
On 08/08/2013 04:40 PM, Keith Thompson wrote: > Rosario1903 <Rosario@invalid.invalid> writes: >> On Thu, 08 Aug 2013 11:27:57 -0700, Keith Thompson wrote: ... >>> Would you really? And what do you think would happen if you tried to >>> apply the "%" operator to a pointer value? >> >> i would know what happen here: the result for example address%8 >> would be >> 1 if mem is char aligned >> 2 if mem is short and char aligned >> 4 if mem is int, short, char aligned >> 0 if mem is double aligned etc > > You are mistaken. The result would be an error message from the > compiler. C doesn't define the "%" operator for pointers. It could be both - after diagnosing the code, the implementation is free to translate it into a program that, if executed, does precisely what he expects it to do. The implementation is also free to translate it into a program that plays "Killing Me Softly With His Song". Both possible results are, of course, equally relevant to the issue he's talking about. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-10 05:52 +0000 |
| Message-ID | <slrn3vfsl0bl9n.a0o.ike@iceland.freeshell.org> |
| In reply to | #35141 |
On 2013-08-08, Rosario1903 <Rosario@invalid.invalid> wrote:
> On Thu, 08 Aug 2013 11:27:57 -0700, Keith Thompson wrote:
>>Would you really? And what do you think would happen if you tried to
>>apply the "%" operator to a pointer value?
>
> i would know what happen here: the result for example address%8
> would be
> 1 if mem is char aligned
Any of {0,1,2,3,4,5,6,7} if mem is char aligned
> 2 if mem is short and char aligned
Any of {0,2,4,6} if mem is short and char aligned
> 4 if mem is int, short, char aligned
Any of {0,4} if mem is int,short,char aligned
[toc] | [prev] | [next] | [standalone]
| From | Rosario1903 <Rosario@invalid.invalid> |
|---|---|
| Date | 2013-08-10 09:54 +0200 |
| Message-ID | <obsb09p56a4n5kc8glcjpcnc3kmc7ehgm4@4ax.com> |
| In reply to | #35217 |
On Sat, 10 Aug 2013 05:52:55 +0000 (UTC), Ike Naar wrote:
>On 2013-08-08, Rosario1903 <Rosario@invalid.invalid> wrote:
>> On Thu, 08 Aug 2013 11:27:57 -0700, Keith Thompson wrote:
>>>Would you really? And what do you think would happen if you tried to
>>>apply the "%" operator to a pointer value?
>>
>> i would know what happen here: the result for example address%8
>> would be
>> 1 if mem is char aligned
>
>Any of {0,1,2,3,4,5,6,7} if mem is char aligned
>
>> 2 if mem is short and char aligned
>
>Any of {0,2,4,6} if mem is short and char aligned
>
>> 4 if mem is int, short, char aligned
>
>Any of {0,4} if mem is int,short,char aligned
i consider not all result but only 2^n i don't know why..
yes if result 3,5,7 can be only char aligned... etc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2013-08-10 07:46 -0400 |
| Message-ID | <ku596h$96k$1@dont-email.me> |
| In reply to | #35217 |
On 08/10/2013 01:52 AM, Ike Naar wrote:
> On 2013-08-08, Rosario1903 <Rosario@invalid.invalid> wrote:
>> On Thu, 08 Aug 2013 11:27:57 -0700, Keith Thompson wrote:
>>> Would you really? And what do you think would happen if you tried to
>>> apply the "%" operator to a pointer value?
>>
>> i would know what happen here: the result for example address%8
>> would be
>> 1 if mem is char aligned
>
> Any of {0,1,2,3,4,5,6,7} if mem is char aligned
>
>> 2 if mem is short and char aligned
>
> Any of {0,2,4,6} if mem is short and char aligned
>
>> 4 if mem is int, short, char aligned
>
> Any of {0,4} if mem is int,short,char aligned
I've got Rosario1903's nonsense killfiled, so I'm not sure what he's
said about what "address" is.
If "address" is a pointer, as seems consistent with the what I've seen
in responses to his messages, the only thing guaranteed for this code is
a diagnostic message about the constraint violation (6.5.5p2).
If "address" is the result of converting a pointer to uintptr_t, the
only thing guaranteed about the value of address%8 is that it is in the
range 0-7, and that's true regardless of how the pointer value is aligned.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-10 04:54 -0700 |
| Message-ID | <3b291c09-cc71-4b28-a02b-d45e56d2b4cd@googlegroups.com> |
| In reply to | #35223 |
On Saturday, August 10, 2013 12:46:24 PM UTC+1, James Kuyper wrote: > On 08/10/2013 01:52 AM, Ike Naar wrote: > > I've got Rosario1903's nonsense killfiled, so I'm not sure what he's > said about what "address" is. > A pointer is a specific C variable which can be dereferenced, and on any sane C implementation holds a memory address. An address is any representation which can be converted ultimately to impulses along the bus to read the memory. So it's meaningful to take modulus or do other operations on a address which are forbidden in pointers. It's also meaningful to talk about a "negative" address, though ultimately, like all computer values, it's just set bits and unset bits and any construction we put upon them is human.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@removethis.hesbynett.no> |
|---|---|
| Date | 2013-08-10 14:51 +0200 |
| Message-ID | <QtqdnYNb96ahqpvPnZ2dnUVZ8j-dnZ2d@lyse.net> |
| In reply to | #35224 |
On 10/08/13 13:54, Malcolm McLean wrote: > On Saturday, August 10, 2013 12:46:24 PM UTC+1, James Kuyper wrote: >> On 08/10/2013 01:52 AM, Ike Naar wrote: >> >> I've got Rosario1903's nonsense killfiled, so I'm not sure what he's >> said about what "address" is. >> > A pointer is a specific C variable which can be dereferenced, and on any > sane C implementation holds a memory address. There are C implementations where a pointer is more complex than just a memory address. For example, some microcontroller architectures have different "memory spaces", requiring different instructions to access flash memory or ram. This means you need "flash pointers" and "ram pointers" (which will just contain a memory address, but possibly of different sizes), and an implementation may also provide a "universal pointer" (containing an address space indicator as well as an address). I don't know exactly where such things are regarding the standards, but they are certainly "sane C implementations", and certainly useful. While it's a little off topic, it's worth mentioning that with C++ you can make "pointer classes" that can be dereferenced, but which hold a lot more than just a memory address. (In theory, they could also hold /less/ than a memory address - perhaps an index into an array, with the details sorted out by the dereferencing operation.) So saying a pointer is just a holder for a memory address is perhaps an over-simplification. I agree with the rest of your post, however. > An address is any representation which can be converted ultimately to > impulses along the bus to read the memory. So it's meaningful to take > modulus or do other operations on a address which are forbidden in > pointers. It's also meaningful to talk about a "negative" address, though > ultimately, like all computer values, it's just set bits and unset bits > and any construction we put upon them is human. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-10 11:12 -0700 |
| Message-ID | <lnfvuho1o7.fsf@nuthaus.mib.org> |
| In reply to | #35224 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, August 10, 2013 12:46:24 PM UTC+1, James Kuyper wrote:
>> On 08/10/2013 01:52 AM, Ike Naar wrote:
>> I've got Rosario1903's nonsense killfiled, so I'm not sure what he's
>> said about what "address" is.
>>
> A pointer is a specific C variable which can be dereferenced, and on
> any sane C implementation holds a memory address. An address is any
> representation which can be converted ultimately to impulses along the
> bus to read the memory. So it's meaningful to take modulus or do other
> operations on a address which are forbidden in pointers. It's also
> meaningful to talk about a "negative" address, though ultimately, like
> all computer values, it's just set bits and unset bits and any
> construction we put upon them is human.
If you're going to make this kind of distinction (which is a
perfectly valid one), I suggest not using terms that are synonyms
in the C standard. For example, the unary "&" operator yields
the *address* of its operand, which is a *pointer* value. Perhaps
"machine address" would be a better term for what you're calling
a memory address.
On the Cray T90 and related vector systems, a void* or char* value
consists of a 64-bit machine-level pointer to a 64-bit word, with
a 3-bit offset stored in the otherwise unused high-order 3 bits.
This is done entirely in software; there's no hardware support for
addressing anything smaller than a 64-bit word. Converting from
a pointer type to an integer type simply copies the bits. Given:
char arr[2];
both (unsigned)&arr[0] % 8 and (unsigned)&arr[1] % 8 would almost
certainly have the same value, which could be any value from 0 to 7.
(I'd use uintptr_t, but the C compiler didn't support C99.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-08-10 19:14 +0000 |
| Message-ID | <ku63f0$mqi$1@speranza.aioe.org> |
| In reply to | #35227 |
Keith Thompson <kst-u@mib.org> wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: (snip) >> A pointer is a specific C variable which can be dereferenced, and on >> any sane C implementation holds a memory address. An address is any >> representation which can be converted ultimately to impulses along the >> bus to read the memory. So it's meaningful to take modulus or do other >> operations on a address which are forbidden in pointers. It's also >> meaningful to talk about a "negative" address, though ultimately, like >> all computer values, it's just set bits and unset bits and any >> construction we put upon them is human. > If you're going to make this kind of distinction (which is a > perfectly valid one), I suggest not using terms that are synonyms > in the C standard. For example, the unary "&" operator yields > the *address* of its operand, which is a *pointer* value. Perhaps > "machine address" would be a better term for what you're calling > a memory address. I suppose, but maybe the standard shouldn't use some terms which might not be right. Since a "pointer" might not be just an "address", maybe there should be different wording for &. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2013-08-10 20:39 -0400 |
| Message-ID | <T2BNt.6817$4q1.380@en-nntp-12.dc1.easynews.com> |
| In reply to | #35231 |
On 8/10/13 3:14 PM, glen herrmannsfeldt wrote: > Keith Thompson <kst-u@mib.org> wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > (snip) >>> A pointer is a specific C variable which can be dereferenced, and on >>> any sane C implementation holds a memory address. An address is any >>> representation which can be converted ultimately to impulses along the >>> bus to read the memory. So it's meaningful to take modulus or do other >>> operations on a address which are forbidden in pointers. It's also >>> meaningful to talk about a "negative" address, though ultimately, like >>> all computer values, it's just set bits and unset bits and any >>> construction we put upon them is human. > >> If you're going to make this kind of distinction (which is a >> perfectly valid one), I suggest not using terms that are synonyms >> in the C standard. For example, the unary "&" operator yields >> the *address* of its operand, which is a *pointer* value. Perhaps >> "machine address" would be a better term for what you're calling >> a memory address. > > I suppose, but maybe the standard shouldn't use some terms which > might not be right. Since a "pointer" might not be just an > "address", maybe there should be different wording for &. > > -- glen > > Actually, a pointer holding a memory address plus additional bits somewhere for additional information like which byte/bits to access within the memory address does meet the traditional definition of an "Address". For example, the "Address" of an apartment withing a large building will contain both a "Street Address" and an apartment number. Both the "Apartment Address" and the "Street Address" are thought of as addresses. C defines its operations in terms of its "abstract machine", and this abstract machine is defined to be "char" addressable. If the real hardware has this ability, then the C pointer value will likely directly map into a hardware address. If the real hardware does not directly support addressing a char/byte, then the implementation may chose to implement this additional capability is software (or define a char to be the size that the machine can address). It is common for people today to (mistakenly) assume that all machines must support 8 bit bytes and linear byte addressable memory, because the common architectures today do, but the C standard grew up in a time where that wasn't as universal of an assumption, and defined things to allow for the support of C compilers for these "unusual" machines. If you are willing to restrict what machines your code will run on, then perhaps making some of these assumptions may be reasonable. You do have to be careful, as some assumptions that seem common may not hold in the future. Example of assumptions that did become common in some communities that caused porting problems as machines evolved: sizeof(long) == 2*sizeof(int) sizeof(char*) == sizeof(int) sizeof(char*) == sizeof(long) the signness of char note that the 2nd and 3rd happened at different times As to the conversion of a "address" to a "number", this normally includes an assumption of a linear address space, which is NOT universal even today (but I am not sure if you could build a fully conforming implementation on the processors I am thinking of, but they DO have freestanding implementations that are useful, even if they may not meet all of the limits, I would need to check if those are needed for a freestanding implementation).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-10 20:29 -0700 |
| Message-ID | <ln7gfsoqfq.fsf@nuthaus.mib.org> |
| In reply to | #35231 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> (snip)
>>> A pointer is a specific C variable which can be dereferenced, and on
>>> any sane C implementation holds a memory address. An address is any
>>> representation which can be converted ultimately to impulses along the
>>> bus to read the memory. So it's meaningful to take modulus or do other
>>> operations on a address which are forbidden in pointers. It's also
>>> meaningful to talk about a "negative" address, though ultimately, like
>>> all computer values, it's just set bits and unset bits and any
>>> construction we put upon them is human.
>
>> If you're going to make this kind of distinction (which is a
>> perfectly valid one), I suggest not using terms that are synonyms
>> in the C standard. For example, the unary "&" operator yields
>> the *address* of its operand, which is a *pointer* value. Perhaps
>> "machine address" would be a better term for what you're calling
>> a memory address.
>
> I suppose, but maybe the standard shouldn't use some terms which
> might not be right. Since a "pointer" might not be just an
> "address", maybe there should be different wording for &.
How can a "pointer" be anything other than an "address" (with
both terms used the way the C standard uses them)? I suppose you
could say that a null pointer isn't an address; is that what you're
referring to?
A C pointer / address might be something other than a machine-level
address, but there are plenty of cases where the standard uses terms
in more specific ways than they might be used in other contexts
("string", "byte", "object", etc.).
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-10 21:51 -0700 |
| Message-ID | <67ecdedb-0d4f-498a-9c66-b4b05484a125@googlegroups.com> |
| In reply to | #35238 |
On Sunday, August 11, 2013 4:29:45 AM UTC+1, Keith Thompson wrote: > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > > How can a "pointer" be anything other than an "address" (with > both terms used the way the C standard uses them)? I suppose you > could say that a null pointer isn't an address; is that what you're > referring to? > We could implement a weird and wonderful system where pointers were random words in a dictionary, then you looked them up in a hash table to resolve to disk writes for dynamic memory or variable names for automatic memory. So a pointer wouldn't be an address, in the sense I used the term (something which can map to electrical impulses on a bus attached to memory).
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-08-11 05:47 +0000 |
| Message-ID | <ku78h0$8ep$1@speranza.aioe.org> |
| In reply to | #35239 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Sunday, August 11, 2013 4:29:45 AM UTC+1, Keith Thompson wrote: (snip) >> How can a "pointer" be anything other than an "address" (with >> both terms used the way the C standard uses them)? I suppose you >> could say that a null pointer isn't an address; is that what you're >> referring to? > We could implement a weird and wonderful system where pointers > were random words in a dictionary, then you looked them up in > a hash table to resolve to disk writes for dynamic memory or > variable names for automatic memory. > So a pointer wouldn't be an address, in the sense I used the > term (something which can map to electrical impulses on a > bus attached to memory). Not so different from JVM object references. You aren't allowed to look at the bits. (There are no operations to do it.) If the reference is an array, the offset is supplied when it is dereferenced. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-10 23:15 -0700 |
| Message-ID | <617ce30b-3fc1-4c44-8a1a-dc4a6b141abe@googlegroups.com> |
| In reply to | #35241 |
On Sunday, August 11, 2013 6:47:12 AM UTC+1, glen herrmannsfeldt wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > Not so different from JVM object references. You aren't allowed > to look at the bits. (There are no operations to do it.) > If the reference is an array, the offset is supplied when it > is dereferenced. > You need to understand that a Java object reference is a pointer or you can't really understand how Java works. But it's hard for programmers who learn Java as a first language, because they can't manipulate the pointer. Also in C we can easily do memory management. If we've got flash pointers and ram pointers, we can read and write to both, but writing to flash is expensive, so we won't want the compiler producing code to erase the flash on a simple pointer dereference. But we can provide a function flash_write, then we can test that the destination pointer is in the flash area of memory, and correctly aligned. We can do pretty much everything in C, except maybe a few assembly instructions to actually start the erase cycle. In Java you can't. You've got to patch the JVM.
[toc] | [prev] | [next] | [standalone]
Page 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web