Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #4025 > unrolled thread
| Started by | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| First post | 2011-04-19 13:46 -0500 |
| Last post | 2011-05-12 13:31 +0100 |
| Articles | 20 on this page of 343 — 21 participants |
Back to article view | Back to comp.lang.c++
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-19 13:46 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-20 17:29 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-23 12:59 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-23 20:31 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-24 09:26 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 00:04 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-24 11:24 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 02:16 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-24 14:10 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 04:37 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-24 16:11 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 13:31 +0100
Re: Problem with array objects Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-24 17:57 +0200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 17:39 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-25 10:19 +1200
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-25 10:12 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-25 00:46 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-25 11:59 +1200
Re: Problem with array objects "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-25 05:01 +0200
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-25 14:56 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-25 10:57 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-26 12:36 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-26 22:42 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-27 12:53 -0500
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-04-27 19:06 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-27 20:09 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-29 12:57 -0500
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-04-29 19:10 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-29 19:56 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-02 13:20 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-02 22:43 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-05 14:13 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-05 22:21 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-06 10:49 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-06 12:29 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-07 11:34 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-08 04:05 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-10 12:31 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-10 22:10 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-12 12:19 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-13 09:54 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-14 11:20 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-14 23:59 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-17 12:59 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-18 19:36 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-19 13:20 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-20 14:29 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-23 13:53 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-23 22:53 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-23 23:04 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-23 23:19 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 02:26 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-24 13:16 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 14:58 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-24 15:05 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 17:39 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-24 17:58 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 21:04 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-24 21:11 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 00:12 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 00:33 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 11:39 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 12:04 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 12:56 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 13:15 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 16:36 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 16:47 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 17:15 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 17:39 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 21:09 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 22:24 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 01:28 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-25 09:57 -0400
Re: Problem with array objects "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-05-25 16:50 +0200
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-25 12:01 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 16:59 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-25 12:56 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 21:46 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-25 20:02 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 01:37 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-26 09:08 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 15:19 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-26 14:45 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 21:02 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-27 09:34 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 14:46 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-27 15:07 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 21:42 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-27 19:34 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 01:24 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-28 10:58 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 19:41 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-28 20:38 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 12:32 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-29 10:05 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 20:13 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-29 19:38 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-30 17:01 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-31 09:45 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:33 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-06-01 09:57 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 15:53 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 16:46 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 19:44 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 19:59 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 21:41 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 22:10 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:39 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 23:21 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:32 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-06-01 12:33 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 19:18 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 19:38 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 20:10 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 20:18 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:01 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 22:25 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:43 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-02 09:49 +1200
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 23:27 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 00:26 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-02 00:33 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 08:52 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-06-01 15:37 -0400
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-02 07:46 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 21:22 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 10:31 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:10 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-02 09:28 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:59 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 15:05 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:35 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-02 10:51 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 00:28 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 16:33 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 09:03 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-02 01:23 -0700
Re: Problem with array objects Miles Bader <miles@gnu.org> - 2011-06-02 17:31 +0900
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-02 01:39 -0700
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 11:28 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:54 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 12:08 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:41 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 14:56 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:17 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:17 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 15:32 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:58 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 16:31 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 08:50 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 21:05 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-06-01 16:38 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:20 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 14:42 -0700
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-27 17:44 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 03:11 +0100
Re: Problem with array objects Öö Tiib <ootiib@hot.ee> - 2011-05-28 19:21 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 12:50 +0100
Re: Problem with array objects Öö Tiib <ootiib@hot.ee> - 2011-05-29 07:21 -0700
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-29 15:30 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 20:43 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-29 21:51 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 03:08 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-05-30 17:39 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 06:05 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-05-31 09:38 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:50 +0100
Re: Problem with array objects SG <s.gesemann@gmail.com> - 2011-05-31 02:23 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 13:29 +0100
Re: Problem with array objects "Fred Zwarts \(KVI\)" <F.Zwarts@KVI.nl> - 2011-05-31 15:17 +0200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:43 +0100
Re: Problem with array objects Michael Doubez <michael.doubez@free.fr> - 2011-05-31 02:43 -0700
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-31 14:38 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:45 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-31 21:11 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 10:23 +0100
Re: Problem with array objects gwowen <gwowen@gmail.com> - 2011-06-01 03:08 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 15:59 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 13:45 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 14:23 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 16:02 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 16:33 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 19:52 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 20:02 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 09:16 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 21:00 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 10:09 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:31 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 11:58 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:21 +0100
Re: Problem with array objects crisgoogle <crisd@telus.net> - 2011-06-01 16:22 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 00:48 +0100
Re: Problem with array objects crisgoogle <crisd@telus.net> - 2011-06-02 11:06 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 19:58 +0100
Re: Problem with array objects crisgoogle <crisd@telus.net> - 2011-06-02 13:28 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 01:16 +0100
Re: Problem with array objects crisgoogle <crisd@telus.net> - 2011-06-02 18:51 -0700
Re: Problem with array objects PaulR <pchristor@yahoo.co.uk> - 2011-06-03 04:59 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:21 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 14:46 -0700
Re: Problem with array objects Michael Doubez <michael.doubez@free.fr> - 2011-06-01 00:46 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 20:29 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-29 23:11 -0700
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-25 08:15 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 22:23 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-24 17:01 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 11:48 +0100
Re: Problem with array objects gwowen <gwowen@gmail.com> - 2011-05-25 04:06 -0700
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-25 13:50 -0700
Re: Problem with array objects "io_x" <a@b.c.invalid> - 2011-05-25 19:03 +0200
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-25 12:44 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 21:04 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 22:20 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 11:00 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-26 12:07 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 13:09 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-26 09:32 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 11:10 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-26 23:07 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 13:22 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-26 14:14 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 15:27 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-26 15:52 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 16:45 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-26 17:04 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 17:41 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 07:44 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 21:10 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 09:05 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 00:15 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 11:32 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 01:39 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 01:56 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 13:18 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 11:06 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 22:28 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 12:51 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 13:58 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 14:34 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 15:14 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 15:18 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 15:24 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 15:31 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 15:53 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 16:18 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 20:35 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 21:23 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 22:04 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 22:15 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 00:40 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 00:53 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 01:32 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 01:49 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-28 13:17 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 03:29 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-28 15:35 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 12:24 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-29 08:21 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 22:04 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-29 09:17 +1200
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-29 09:32 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 22:58 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-29 10:06 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 23:51 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 03:20 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 12:34 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 12:56 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 13:49 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 14:48 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 15:10 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 19:35 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 19:59 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 20:17 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 20:44 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 21:00 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 22:07 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-26 14:38 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 21:15 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-27 12:43 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 20:20 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-28 11:41 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 19:10 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-31 12:26 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:49 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-01 12:46 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 20:26 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-02 12:36 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 20:23 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-02 10:34 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 01:41 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-02 16:06 -1000
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-02 16:12 -1000
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-02 16:21 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 14:17 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 10:34 -0700
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 10:45 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-04 21:02 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 14:11 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-04 22:35 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 15:43 -0700
Re: Problem with array objects "io_x" <a@b.c.invalid> - 2011-06-05 06:39 +0200
Re: Problem with array objects "io_x" <a@b.c.invalid> - 2011-06-05 07:55 +0200
Re: Problem with array objects "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-03 11:14 +0200
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-03 21:08 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 14:25 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 10:52 -0700
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-04 19:52 -0700
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-05 13:48 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-05 14:52 +0100
Re: Problem with array objects "Thomas J. Gritzan" <phygon_antispam@gmx.de> - 2011-06-05 18:03 +0200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-05 19:23 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-05 14:49 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-03 12:37 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 19:49 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-04 11:46 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-04 18:42 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-06 14:27 -0500
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-06 14:04 -0700
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-06 14:04 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-07 02:26 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-06 23:30 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-07 13:13 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-08 01:20 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-08 11:39 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-08 17:03 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-08 23:51 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-11 11:41 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-12 00:56 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-14 13:44 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-14 23:01 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-16 13:41 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-16 23:01 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-18 12:23 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-18 19:50 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-21 13:38 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-22 00:29 +0100
Re: Problem with array objects Keith H Duggar <duggar@alum.mit.edu> - 2011-06-18 12:58 -0700
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-21 13:40 -0500
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-10 15:56 -0700
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-11 12:25 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-11 10:56 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-11 14:09 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-12 13:31 +0100
Page 13 of 18 — ← Prev page 1 … 11 12 [13] 14 15 … 18 Next page →
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-27 15:18 +0100 |
| Message-ID | <YO-dnddDz9U3L0LQnZ2dnUVZ8n2dnZ2d@giganews.com> |
| In reply to | #5699 |
On 27/05/2011 15:14, Leigh Johnston wrote:
> On 27/05/2011 14:34, Paul wrote:
>>
>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
>> news:wuCdnfZkaex0AkLQnZ2dnUVZ8mydnZ2d@giganews.com...
>>> On 27/05/2011 01:39, Paul wrote:
>>>>
>>>> "Ian Collins" <ian-news@hotmail.com> wrote in message
>>>> news:948694Fmt0U1@mid.individual.net...
>>>>> On 05/27/11 11:15 AM, Paul wrote:
>>>>>> "Ian Collins"<ian-news@hotmail.com> wrote:
>>>>>>> On 05/27/11 08:10 AM, Paul wrote:
>>>>>>>> "Ian Collins"<ian-news@hotmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Man you really don't have a clue, do you? I'll ask again, How much
>>>>>>>>> x86
>>>>>>>>> assembly programming have you actually done?
>>>>>>>>>
>>>>>>>> It doesn't matter how much I claim to have done or how much you
>>>>>>>> claim to
>>>>>>>> have done. The fact of the matter is, apparently I know what a
>>>>>>>> pointer
>>>>>>>> is
>>>>>>>> and you don't.
>>>>>>>
>>>>>>> I'll take that as "none".
>>>>>>>
>>>>>>>> A variable whose value is an address(or an offset) to another
>>>>>>>> memory
>>>>>>>> location is a pointer in assembly language.
>>>>>>>
>>>>>>> The *number* -20 isn't a variable any more than arr in "#define
>>>>>>> arr 20"
>>>>>>> is.
>>>>>> Correct -20 is not a variable , it is the value of the variable.
>>>>>
>>>>> It is the value of a constant. By your definition, if I write
>>>>>
>>>>> #define arr -20
>>>>>
>>>>> arr is a variable.
>>>>>
>>>>>>> _arr$ = -20 ; size = 20
>>>>>>>
>>>>>>> is the MASM equivalent of
>>>>>>>
>>>>>>> #define arr = -20 // is arr a pointer?
>>>>>>>
>>>>>>> It is declared in the text segment, it is not an offset into the
>>>>>>> text
>>>>>>> segment.
>>>>>>>
>>>>>> _arr$ is a variable that stores the value -20.
>>>>>
>>>>> No, for the last time it is a constant. Please study a topic before
>>>>> posting about it. From the link I posted earlier:
>>>>>
>>>>> "A manifest constant is a symbol name that represents some fixed
>>>>> quantity during the assembly process. That is it is a symbolic name
>>>>> that represents some value. Equates are the mechanism MASM uses to
>>>>> declare symbolic constants."
>>>>>
>>>>> This is now way off topic. I suggest you find an assembly programming
>>>>> group and see how far you get there.
>>>>>
>>>> Its you that brought it up. And now you seem to be ruinning away from
>>>> the argument because you are maybe starting to realise that _arr$ is a
>>>> pointer.
>>>>
>>>>
>>>> Look at the following code:
>>>>
>>>> int main(){
>>>> int arr[3]={0};
>>>> int* px= arr;
>>>> px[1] = 7;
>>>> }
>>>>
>>>> ; Listing generated by Microsoft (R) Optimizing Compiler Version
>>>> 14.00.50727.762
>>>>
>>>> TITLE C:\cpp\public.cpp
>>>> .686P
>>>> .XMM
>>>> include listing.inc
>>>> .model flat
>>>>
>>>> INCLUDELIB LIBCMT
>>>> INCLUDELIB OLDNAMES
>>>>
>>>> PUBLIC _main
>>>> ; Function compile flags: /Odtp
>>>> _TEXT SEGMENT
>>>> _px$ = -16 ; size = 4
>>>> _arr$ = -12 ; size = 12
>>>> _main PROC
>>>> ; File c:\cpp\public.cpp
>>>> ; Line 5
>>>> push ebp
>>>> mov ebp, esp
>>>> sub esp, 16 ; 00000010H
>>>> ; Line 6
>>>> mov DWORD PTR _arr$[ebp], 0
>>>> xor eax, eax
>>>> mov DWORD PTR _arr$[ebp+4], eax
>>>> mov DWORD PTR _arr$[ebp+8], eax
>>>> ; Line 7
>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>> mov DWORD PTR _px$[ebp], ecx
>>>> ; Line 8
>>>> mov edx, DWORD PTR _px$[ebp]
>>>> mov DWORD PTR [edx+4], 7
>>>> ; Line 9
>>>> xor eax, eax
>>>> mov esp, ebp
>>>> pop ebp
>>>> ret 0
>>>> _main ENDP
>>>> _TEXT ENDS
>>>> END
>>>>
>>>> Line 5-6 Creates a stack frame similar to below. It preserves ebp on
>>>> the
>>>> stack, then assgins the esp value to ebp and then decrements esp by 16
>>>> bytes.
>>>> Line 6-7 Initialises the 3 integer objects , of the array, to 0.
>>>> Line 7-8 Stores the address of the first element at the location _px$
>>>> points to.
>>>> Line 8-9 Moves the literal value of 7 into the 2nd element of the
>>>> array.
>>>>
>>>>
>>>> 00001C [-------------]
>>>> 000018 [--orig ebp---]<- orig esp
>>>> 000014 [------0------] <-ebp
>>>> 000010 [------7------]
>>>> 00000C [------0------]
>>>> 000008 [---00000C---] <- esp
>>>> 000004 [-------------]
>>>> 000000 [-------------]
>>>>
>>>> After that ebp is popped and esp is back to its original value.
>>>> Face the facts about what a pointer is in assembly programming.
>>>> If you still do not accept these facts then I urge you to refer to the
>>>> link I posted about pointer data types by Randy Hyde.
>>>
>>> Now you are arguing with yourself: you have just shown that there is
>>> no special hidden object which containing the address of the array
>>> object; the only thing that contains the address of the array object
>>> above is the pointer 'px'.
>>>
>> No there is a pointer named _arr$, which happens to be in the text
>> segment, it is not on the stack.
>
> No, '_arr$' is not a pointer; '_arr$' is a constant used when emitting
> machine code in the text segment. If does not exist as a separate entity
> in the text segment. lrn2asm.
>
>> Just the same as the pointer _px$ is not on the stack.
>> Look at the value of _px$, it is -16, this doesn't mean it's not a
>> pointer. Its just a pointer that stores an offset, or an index into the
>> stack.
>
> The value of the pointer 'px' is stored on the stack at a location stack
> frame pointer + '_px$' (a constant whose value is -16); we have already
> told you this.
>
>>
>>> For:
>>>
>>> lea ecx, DWORD PTR _arr$[ebp]
>>>
>>> what will actually be emitted is:
>>>
>>> lea ecx, DWORD PTR [ebp-12]
>>>
>>> as '_arr$' is a constant; not a variable or a "pointer".
>>
>> _arr$ holds an offset which is added to ebp to create the real address.
>
> Correct we have already told you this.
>
>> _arr$ is a constant only because it is stored in the read only text
>> segment. This does not mean it is not a pointer , it stores an offset
>> that points to the begining of the array.
>
> As I have already said '_arr$' does not exist as a distinct separate
> entity in the text segment; it used when emitting machine code in the
> text segment.
>
>> A pointer does not need to store a real address a pointer can also store
>> an offset, as in this case.
>
> It is not a pointer; it is a constant used when emitting machine code.
>
>>
>>
>> Given my stack frame illustration _arr$ points to here:
>>
>> 00001C [-------------]
>> 000018 [--orig ebp---] <- ebp
>> 000014 [------0------]
>> 000010 [------7------]
>> 00000C [------0------] <- _arr$
>> 000008 [---00000C---] <- esp
>> 000004 [-------------]
>> 000000 [-------------]
>>
>> -12 is an offset into the stack frame, which is the location where the
>> array begins.
>
> Finally. Yes -12 is an offset into the stack frame; we have been trying
> to tell you this for the past couple of days; -12 is not a pointer or a
> variable it is a constant offset. A realistic and correct stack frame
> illustration is:
>
> 123000 [-------------]
> 122FFC [--orig ebp---] <- ebp
> 123FF8 [------0------]
> 123FF4 [------7------]
> 123FF0 [------0------] <- ebp + _arr$
> 123FEC [---123FEC---] <- esp
> 123FE8 [-------------]
> 123FE4 [-------------]
>
> Notice how I have replaced your deliberately misleading value of 12
> (00000C) with a more realistic value that shows that the contents of the
> pointer 'px' is unrelated to the number 12; its value is ebp + _arr$ as
> encoded into the emitted machine code in the text segment.
>
> HTH.
>
> /Leigh
Obviously that should have been:
123000 [-------------]
122FFC [--orig ebp---] <- ebp
123FF8 [------0------]
123FF4 [------7------]
123FF0 [------0------] <- ebp + _arr$
123FEC [---123FF0---] <- esp
123FE8 [-------------]
123FE4 [-------------]
/Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-27 15:24 +0100 |
| Message-ID | <EuODp.12909$A05.9283@newsfe13.ams2> |
| In reply to | #5699 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:YO-dndRDz9U1LELQnZ2dnUVZ8n2dnZ2d@giganews.com...
> On 27/05/2011 14:34, Paul wrote:
>>
>>>>>>>>>
>>>>>>>>> Man you really don't have a clue, do you? I'll ask again, How much
>>>>>>>>> x86
>>>>>>>>> assembly programming have you actually done?
>>>>>>>>>
>>>>>>>> It doesn't matter how much I claim to have done or how much you
>>>>>>>> claim to
>>>>>>>> have done. The fact of the matter is, apparently I know what a
>>>>>>>> pointer
>>>>>>>> is
>>>>>>>> and you don't.
>>>>>>>
>>>>>>> I'll take that as "none".
>>>>>>>
>>>>>>>> A variable whose value is an address(or an offset) to another
>>>>>>>> memory
>>>>>>>> location is a pointer in assembly language.
>>>>>>>
>>>>>>> The *number* -20 isn't a variable any more than arr in "#define
>>>>>>> arr 20"
>>>>>>> is.
>>>>>> Correct -20 is not a variable , it is the value of the variable.
>>>>>
>>>>> It is the value of a constant. By your definition, if I write
>>>>>
>>>>> #define arr -20
>>>>>
>>>>> arr is a variable.
>>>>>
>>>>>>> _arr$ = -20 ; size = 20
>>>>>>>
>>>>>>> is the MASM equivalent of
>>>>>>>
>>>>>>> #define arr = -20 // is arr a pointer?
>>>>>>>
>>>>>>> It is declared in the text segment, it is not an offset into the
>>>>>>> text
>>>>>>> segment.
>>>>>>>
>>>>>> _arr$ is a variable that stores the value -20.
>>>>>
>>>>> No, for the last time it is a constant. Please study a topic before
>>>>> posting about it. From the link I posted earlier:
>>>>>
>>>>> "A manifest constant is a symbol name that represents some fixed
>>>>> quantity during the assembly process. That is it is a symbolic name
>>>>> that represents some value. Equates are the mechanism MASM uses to
>>>>> declare symbolic constants."
>>>>>
>>>>> This is now way off topic. I suggest you find an assembly programming
>>>>> group and see how far you get there.
>>>>>
>>>> Its you that brought it up. And now you seem to be ruinning away from
>>>> the argument because you are maybe starting to realise that _arr$ is a
>>>> pointer.
>>>>
>>>>
>>>> Look at the following code:
>>>>
>>>> int main(){
>>>> int arr[3]={0};
>>>> int* px= arr;
>>>> px[1] = 7;
>>>> }
>>>>
>>>> ; Listing generated by Microsoft (R) Optimizing Compiler Version
>>>> 14.00.50727.762
>>>>
>>>> TITLE C:\cpp\public.cpp
>>>> .686P
>>>> .XMM
>>>> include listing.inc
>>>> .model flat
>>>>
>>>> INCLUDELIB LIBCMT
>>>> INCLUDELIB OLDNAMES
>>>>
>>>> PUBLIC _main
>>>> ; Function compile flags: /Odtp
>>>> _TEXT SEGMENT
>>>> _px$ = -16 ; size = 4
>>>> _arr$ = -12 ; size = 12
>>>> _main PROC
>>>> ; File c:\cpp\public.cpp
>>>> ; Line 5
>>>> push ebp
>>>> mov ebp, esp
>>>> sub esp, 16 ; 00000010H
>>>> ; Line 6
>>>> mov DWORD PTR _arr$[ebp], 0
>>>> xor eax, eax
>>>> mov DWORD PTR _arr$[ebp+4], eax
>>>> mov DWORD PTR _arr$[ebp+8], eax
>>>> ; Line 7
>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>> mov DWORD PTR _px$[ebp], ecx
>>>> ; Line 8
>>>> mov edx, DWORD PTR _px$[ebp]
>>>> mov DWORD PTR [edx+4], 7
>>>> ; Line 9
>>>> xor eax, eax
>>>> mov esp, ebp
>>>> pop ebp
>>>> ret 0
>>>> _main ENDP
>>>> _TEXT ENDS
>>>> END
>>>>
>>>> Line 5-6 Creates a stack frame similar to below. It preserves ebp on
>>>> the
>>>> stack, then assgins the esp value to ebp and then decrements esp by 16
>>>> bytes.
>>>> Line 6-7 Initialises the 3 integer objects , of the array, to 0.
>>>> Line 7-8 Stores the address of the first element at the location _px$
>>>> points to.
>>>> Line 8-9 Moves the literal value of 7 into the 2nd element of the
>>>> array.
>>>>
>>>>
>>>> 00001C [-------------]
>>>> 000018 [--orig ebp---]<- orig esp
>>>> 000014 [------0------] <-ebp
>>>> 000010 [------7------]
>>>> 00000C [------0------]
>>>> 000008 [---00000C---] <- esp
>>>> 000004 [-------------]
>>>> 000000 [-------------]
>>>>
>>>> After that ebp is popped and esp is back to its original value.
>>>> Face the facts about what a pointer is in assembly programming.
>>>> If you still do not accept these facts then I urge you to refer to the
>>>> link I posted about pointer data types by Randy Hyde.
>>>
>>> Now you are arguing with yourself: you have just shown that there is
>>> no special hidden object which containing the address of the array
>>> object; the only thing that contains the address of the array object
>>> above is the pointer 'px'.
>>>
>> No there is a pointer named _arr$, which happens to be in the text
>> segment, it is not on the stack.
>
> No, '_arr$' is not a pointer; '_arr$' is a constant used when emitting
> machine code in the text segment. If does not exist as a separate entity
> in the text segment. lrn2asm.
>
>> Just the same as the pointer _px$ is not on the stack.
>> Look at the value of _px$, it is -16, this doesn't mean it's not a
>> pointer. Its just a pointer that stores an offset, or an index into the
>> stack.
>
> The value of the pointer 'px' is stored on the stack at a location stack
> frame pointer + '_px$' (a constant whose value is -16); we have already
> told you this.
>
>>
>>> For:
>>>
>>> lea ecx, DWORD PTR _arr$[ebp]
>>>
>>> what will actually be emitted is:
>>>
>>> lea ecx, DWORD PTR [ebp-12]
>>>
>>> as '_arr$' is a constant; not a variable or a "pointer".
>>
>> _arr$ holds an offset which is added to ebp to create the real address.
>
> Correct we have already told you this.
>
>> _arr$ is a constant only because it is stored in the read only text
>> segment. This does not mean it is not a pointer , it stores an offset
>> that points to the begining of the array.
>
> As I have already said '_arr$' does not exist as a distinct separate
> entity in the text segment; it used when emitting machine code in the text
> segment.
>
>> A pointer does not need to store a real address a pointer can also store
>> an offset, as in this case.
>
> It is not a pointer; it is a constant used when emitting machine code.
Oh you want to go to machine code level now?
There is no pointers in machine code at all, your argument is nonsense.
>
>>
>>
>> Given my stack frame illustration _arr$ points to here:
>>
>> 00001C [-------------]
>> 000018 [--orig ebp---] <- ebp
>> 000014 [------0------]
>> 000010 [------7------]
>> 00000C [------0------] <- _arr$
>> 000008 [---00000C---] <- esp
>> 000004 [-------------]
>> 000000 [-------------]
>>
>> -12 is an offset into the stack frame, which is the location where the
>> array begins.
>
> Finally. Yes -12 is an offset into the stack frame; we have been trying
> to tell you this for the past couple of days; -12 is not a pointer or a
> variable it is a constant offset. A realistic and correct stack frame
> illustration is:
>
> 123000 [-------------]
> 122FFC [--orig ebp---] <- ebp
> 123FF8 [------0------]
> 123FF4 [------7------]
> 123FF0 [------0------] <- ebp + _arr$
> 123FEC [---123FEC---] <- esp
> 123FE8 [-------------]
> 123FE4 [-------------]
>
> Notice how I have replaced your deliberately misleading value of 12
> (00000C) with a more realistic value that shows that the contents of the
> pointer 'px' is unrelated to the number 12; its value is ebp + _arr$ as
> encoded into the emitted machine code in the text segment.
>
There was no deliberate attempt to mislead, It was pure coincidence that the
address turned out to be 12. You interpretation is wrong , the value of
memory location 123FEC should be 123FF0.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-27 15:31 +0100 |
| Message-ID | <IL-dnVNytsVIKELQnZ2dnUVZ8tydnZ2d@giganews.com> |
| In reply to | #5701 |
On 27/05/2011 15:24, Paul wrote:
>
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:YO-dndRDz9U1LELQnZ2dnUVZ8n2dnZ2d@giganews.com...
>> On 27/05/2011 14:34, Paul wrote:
>>>
>>>>>>>>>>
>>>>>>>>>> Man you really don't have a clue, do you? I'll ask again, How
>>>>>>>>>> much
>>>>>>>>>> x86
>>>>>>>>>> assembly programming have you actually done?
>>>>>>>>>>
>>>>>>>>> It doesn't matter how much I claim to have done or how much you
>>>>>>>>> claim to
>>>>>>>>> have done. The fact of the matter is, apparently I know what a
>>>>>>>>> pointer
>>>>>>>>> is
>>>>>>>>> and you don't.
>>>>>>>>
>>>>>>>> I'll take that as "none".
>>>>>>>>
>>>>>>>>> A variable whose value is an address(or an offset) to another
>>>>>>>>> memory
>>>>>>>>> location is a pointer in assembly language.
>>>>>>>>
>>>>>>>> The *number* -20 isn't a variable any more than arr in "#define
>>>>>>>> arr 20"
>>>>>>>> is.
>>>>>>> Correct -20 is not a variable , it is the value of the variable.
>>>>>>
>>>>>> It is the value of a constant. By your definition, if I write
>>>>>>
>>>>>> #define arr -20
>>>>>>
>>>>>> arr is a variable.
>>>>>>
>>>>>>>> _arr$ = -20 ; size = 20
>>>>>>>>
>>>>>>>> is the MASM equivalent of
>>>>>>>>
>>>>>>>> #define arr = -20 // is arr a pointer?
>>>>>>>>
>>>>>>>> It is declared in the text segment, it is not an offset into the
>>>>>>>> text
>>>>>>>> segment.
>>>>>>>>
>>>>>>> _arr$ is a variable that stores the value -20.
>>>>>>
>>>>>> No, for the last time it is a constant. Please study a topic before
>>>>>> posting about it. From the link I posted earlier:
>>>>>>
>>>>>> "A manifest constant is a symbol name that represents some fixed
>>>>>> quantity during the assembly process. That is it is a symbolic name
>>>>>> that represents some value. Equates are the mechanism MASM uses to
>>>>>> declare symbolic constants."
>>>>>>
>>>>>> This is now way off topic. I suggest you find an assembly programming
>>>>>> group and see how far you get there.
>>>>>>
>>>>> Its you that brought it up. And now you seem to be ruinning away from
>>>>> the argument because you are maybe starting to realise that _arr$ is a
>>>>> pointer.
>>>>>
>>>>>
>>>>> Look at the following code:
>>>>>
>>>>> int main(){
>>>>> int arr[3]={0};
>>>>> int* px= arr;
>>>>> px[1] = 7;
>>>>> }
>>>>>
>>>>> ; Listing generated by Microsoft (R) Optimizing Compiler Version
>>>>> 14.00.50727.762
>>>>>
>>>>> TITLE C:\cpp\public.cpp
>>>>> .686P
>>>>> .XMM
>>>>> include listing.inc
>>>>> .model flat
>>>>>
>>>>> INCLUDELIB LIBCMT
>>>>> INCLUDELIB OLDNAMES
>>>>>
>>>>> PUBLIC _main
>>>>> ; Function compile flags: /Odtp
>>>>> _TEXT SEGMENT
>>>>> _px$ = -16 ; size = 4
>>>>> _arr$ = -12 ; size = 12
>>>>> _main PROC
>>>>> ; File c:\cpp\public.cpp
>>>>> ; Line 5
>>>>> push ebp
>>>>> mov ebp, esp
>>>>> sub esp, 16 ; 00000010H
>>>>> ; Line 6
>>>>> mov DWORD PTR _arr$[ebp], 0
>>>>> xor eax, eax
>>>>> mov DWORD PTR _arr$[ebp+4], eax
>>>>> mov DWORD PTR _arr$[ebp+8], eax
>>>>> ; Line 7
>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>> mov DWORD PTR _px$[ebp], ecx
>>>>> ; Line 8
>>>>> mov edx, DWORD PTR _px$[ebp]
>>>>> mov DWORD PTR [edx+4], 7
>>>>> ; Line 9
>>>>> xor eax, eax
>>>>> mov esp, ebp
>>>>> pop ebp
>>>>> ret 0
>>>>> _main ENDP
>>>>> _TEXT ENDS
>>>>> END
>>>>>
>>>>> Line 5-6 Creates a stack frame similar to below. It preserves ebp
>>>>> on the
>>>>> stack, then assgins the esp value to ebp and then decrements esp by 16
>>>>> bytes.
>>>>> Line 6-7 Initialises the 3 integer objects , of the array, to 0.
>>>>> Line 7-8 Stores the address of the first element at the location _px$
>>>>> points to.
>>>>> Line 8-9 Moves the literal value of 7 into the 2nd element of the
>>>>> array.
>>>>>
>>>>>
>>>>> 00001C [-------------]
>>>>> 000018 [--orig ebp---]<- orig esp
>>>>> 000014 [------0------] <-ebp
>>>>> 000010 [------7------]
>>>>> 00000C [------0------]
>>>>> 000008 [---00000C---] <- esp
>>>>> 000004 [-------------]
>>>>> 000000 [-------------]
>>>>>
>>>>> After that ebp is popped and esp is back to its original value.
>>>>> Face the facts about what a pointer is in assembly programming.
>>>>> If you still do not accept these facts then I urge you to refer to the
>>>>> link I posted about pointer data types by Randy Hyde.
>>>>
>>>> Now you are arguing with yourself: you have just shown that there is
>>>> no special hidden object which containing the address of the array
>>>> object; the only thing that contains the address of the array object
>>>> above is the pointer 'px'.
>>>>
>>> No there is a pointer named _arr$, which happens to be in the text
>>> segment, it is not on the stack.
>>
>> No, '_arr$' is not a pointer; '_arr$' is a constant used when emitting
>> machine code in the text segment. If does not exist as a separate
>> entity in the text segment. lrn2asm.
>>
>>> Just the same as the pointer _px$ is not on the stack.
>>> Look at the value of _px$, it is -16, this doesn't mean it's not a
>>> pointer. Its just a pointer that stores an offset, or an index into the
>>> stack.
>>
>> The value of the pointer 'px' is stored on the stack at a location
>> stack frame pointer + '_px$' (a constant whose value is -16); we have
>> already told you this.
>>
>>>
>>>> For:
>>>>
>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>
>>>> what will actually be emitted is:
>>>>
>>>> lea ecx, DWORD PTR [ebp-12]
>>>>
>>>> as '_arr$' is a constant; not a variable or a "pointer".
>>>
>>> _arr$ holds an offset which is added to ebp to create the real address.
>>
>> Correct we have already told you this.
>>
>>> _arr$ is a constant only because it is stored in the read only text
>>> segment. This does not mean it is not a pointer , it stores an offset
>>> that points to the begining of the array.
>>
>> As I have already said '_arr$' does not exist as a distinct separate
>> entity in the text segment; it used when emitting machine code in the
>> text segment.
>>
>>> A pointer does not need to store a real address a pointer can also store
>>> an offset, as in this case.
>>
>> It is not a pointer; it is a constant used when emitting machine code.
>
> Oh you want to go to machine code level now?
> There is no pointers in machine code at all, your argument is nonsense.
>
>>
>>>
>>>
>>> Given my stack frame illustration _arr$ points to here:
>>>
>>> 00001C [-------------]
>>> 000018 [--orig ebp---] <- ebp
>>> 000014 [------0------]
>>> 000010 [------7------]
>>> 00000C [------0------] <- _arr$
>>> 000008 [---00000C---] <- esp
>>> 000004 [-------------]
>>> 000000 [-------------]
>>>
>>> -12 is an offset into the stack frame, which is the location where the
>>> array begins.
>>
>> Finally. Yes -12 is an offset into the stack frame; we have been
>> trying to tell you this for the past couple of days; -12 is not a
>> pointer or a variable it is a constant offset. A realistic and correct
>> stack frame illustration is:
>>
>> 123000 [-------------]
>> 122FFC [--orig ebp---] <- ebp
>> 123FF8 [------0------]
>> 123FF4 [------7------]
>> 123FF0 [------0------] <- ebp + _arr$
>> 123FEC [---123FEC---] <- esp
>> 123FE8 [-------------]
>> 123FE4 [-------------]
>>
>> Notice how I have replaced your deliberately misleading value of 12
>> (00000C) with a more realistic value that shows that the contents of
>> the pointer 'px' is unrelated to the number 12; its value is ebp +
>> _arr$ as encoded into the emitted machine code in the text segment.
>>
> There was no deliberate attempt to mislead, It was pure coincidence that
> the address turned out to be 12. You interpretation is wrong , the value
> of memory location 123FEC should be 123FF0.
>
Typical troll: deliberately ignoring my correction. On the small chance
that you didn't use your newsreader properly yes I did put the wrong
value in the illustration but that doesn't change the fact that what I
said (and my "interpretation") is correct: '_arr$' is not a pointer it
is a constant used when emitting machine code in the text segment.
/Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-27 15:53 +0100 |
| Message-ID | <dWODp.14573$Ky.10091@newsfe24.ams2> |
| In reply to | #5702 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:IL-dnVNytsVIKELQnZ2dnUVZ8tydnZ2d@giganews.com...
> On 27/05/2011 15:24, Paul wrote:
>>
>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
>> news:YO-dndRDz9U1LELQnZ2dnUVZ8n2dnZ2d@giganews.com...
>>> On 27/05/2011 14:34, Paul wrote:
>>>>
>>>>>>>>>>>
>>>>>>>>>>> Man you really don't have a clue, do you? I'll ask again, How
>>>>>>>>>>> much
>>>>>>>>>>> x86
>>>>>>>>>>> assembly programming have you actually done?
>>>>>>>>>>>
>>>>>>>>>> It doesn't matter how much I claim to have done or how much you
>>>>>>>>>> claim to
>>>>>>>>>> have done. The fact of the matter is, apparently I know what a
>>>>>>>>>> pointer
>>>>>>>>>> is
>>>>>>>>>> and you don't.
>>>>>>>>>
>>>>>>>>> I'll take that as "none".
>>>>>>>>>
>>>>>>>>>> A variable whose value is an address(or an offset) to another
>>>>>>>>>> memory
>>>>>>>>>> location is a pointer in assembly language.
>>>>>>>>>
>>>>>>>>> The *number* -20 isn't a variable any more than arr in "#define
>>>>>>>>> arr 20"
>>>>>>>>> is.
>>>>>>>> Correct -20 is not a variable , it is the value of the variable.
>>>>>>>
>>>>>>> It is the value of a constant. By your definition, if I write
>>>>>>>
>>>>>>> #define arr -20
>>>>>>>
>>>>>>> arr is a variable.
>>>>>>>
>>>>>>>>> _arr$ = -20 ; size = 20
>>>>>>>>>
>>>>>>>>> is the MASM equivalent of
>>>>>>>>>
>>>>>>>>> #define arr = -20 // is arr a pointer?
>>>>>>>>>
>>>>>>>>> It is declared in the text segment, it is not an offset into the
>>>>>>>>> text
>>>>>>>>> segment.
>>>>>>>>>
>>>>>>>> _arr$ is a variable that stores the value -20.
>>>>>>>
>>>>>>> No, for the last time it is a constant. Please study a topic before
>>>>>>> posting about it. From the link I posted earlier:
>>>>>>>
>>>>>>> "A manifest constant is a symbol name that represents some fixed
>>>>>>> quantity during the assembly process. That is it is a symbolic name
>>>>>>> that represents some value. Equates are the mechanism MASM uses to
>>>>>>> declare symbolic constants."
>>>>>>>
>>>>>>> This is now way off topic. I suggest you find an assembly
>>>>>>> programming
>>>>>>> group and see how far you get there.
>>>>>>>
>>>>>> Its you that brought it up. And now you seem to be ruinning away from
>>>>>> the argument because you are maybe starting to realise that _arr$ is
>>>>>> a
>>>>>> pointer.
>>>>>>
>>>>>>
>>>>>> Look at the following code:
>>>>>>
>>>>>> int main(){
>>>>>> int arr[3]={0};
>>>>>> int* px= arr;
>>>>>> px[1] = 7;
>>>>>> }
>>>>>>
>>>>>> ; Listing generated by Microsoft (R) Optimizing Compiler Version
>>>>>> 14.00.50727.762
>>>>>>
>>>>>> TITLE C:\cpp\public.cpp
>>>>>> .686P
>>>>>> .XMM
>>>>>> include listing.inc
>>>>>> .model flat
>>>>>>
>>>>>> INCLUDELIB LIBCMT
>>>>>> INCLUDELIB OLDNAMES
>>>>>>
>>>>>> PUBLIC _main
>>>>>> ; Function compile flags: /Odtp
>>>>>> _TEXT SEGMENT
>>>>>> _px$ = -16 ; size = 4
>>>>>> _arr$ = -12 ; size = 12
>>>>>> _main PROC
>>>>>> ; File c:\cpp\public.cpp
>>>>>> ; Line 5
>>>>>> push ebp
>>>>>> mov ebp, esp
>>>>>> sub esp, 16 ; 00000010H
>>>>>> ; Line 6
>>>>>> mov DWORD PTR _arr$[ebp], 0
>>>>>> xor eax, eax
>>>>>> mov DWORD PTR _arr$[ebp+4], eax
>>>>>> mov DWORD PTR _arr$[ebp+8], eax
>>>>>> ; Line 7
>>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>> mov DWORD PTR _px$[ebp], ecx
>>>>>> ; Line 8
>>>>>> mov edx, DWORD PTR _px$[ebp]
>>>>>> mov DWORD PTR [edx+4], 7
>>>>>> ; Line 9
>>>>>> xor eax, eax
>>>>>> mov esp, ebp
>>>>>> pop ebp
>>>>>> ret 0
>>>>>> _main ENDP
>>>>>> _TEXT ENDS
>>>>>> END
>>>>>>
>>>>>> Line 5-6 Creates a stack frame similar to below. It preserves ebp
>>>>>> on the
>>>>>> stack, then assgins the esp value to ebp and then decrements esp by
>>>>>> 16
>>>>>> bytes.
>>>>>> Line 6-7 Initialises the 3 integer objects , of the array, to 0.
>>>>>> Line 7-8 Stores the address of the first element at the location _px$
>>>>>> points to.
>>>>>> Line 8-9 Moves the literal value of 7 into the 2nd element of the
>>>>>> array.
>>>>>>
>>>>>>
>>>>>> 00001C [-------------]
>>>>>> 000018 [--orig ebp---]<- orig esp
>>>>>> 000014 [------0------] <-ebp
>>>>>> 000010 [------7------]
>>>>>> 00000C [------0------]
>>>>>> 000008 [---00000C---] <- esp
>>>>>> 000004 [-------------]
>>>>>> 000000 [-------------]
>>>>>>
>>>>>> After that ebp is popped and esp is back to its original value.
>>>>>> Face the facts about what a pointer is in assembly programming.
>>>>>> If you still do not accept these facts then I urge you to refer to
>>>>>> the
>>>>>> link I posted about pointer data types by Randy Hyde.
>>>>>
>>>>> Now you are arguing with yourself: you have just shown that there is
>>>>> no special hidden object which containing the address of the array
>>>>> object; the only thing that contains the address of the array object
>>>>> above is the pointer 'px'.
>>>>>
>>>> No there is a pointer named _arr$, which happens to be in the text
>>>> segment, it is not on the stack.
>>>
>>> No, '_arr$' is not a pointer; '_arr$' is a constant used when emitting
>>> machine code in the text segment. If does not exist as a separate
>>> entity in the text segment. lrn2asm.
>>>
>>>> Just the same as the pointer _px$ is not on the stack.
>>>> Look at the value of _px$, it is -16, this doesn't mean it's not a
>>>> pointer. Its just a pointer that stores an offset, or an index into the
>>>> stack.
>>>
>>> The value of the pointer 'px' is stored on the stack at a location
>>> stack frame pointer + '_px$' (a constant whose value is -16); we have
>>> already told you this.
>>>
>>>>
>>>>> For:
>>>>>
>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>
>>>>> what will actually be emitted is:
>>>>>
>>>>> lea ecx, DWORD PTR [ebp-12]
>>>>>
>>>>> as '_arr$' is a constant; not a variable or a "pointer".
>>>>
>>>> _arr$ holds an offset which is added to ebp to create the real address.
>>>
>>> Correct we have already told you this.
>>>
>>>> _arr$ is a constant only because it is stored in the read only text
>>>> segment. This does not mean it is not a pointer , it stores an offset
>>>> that points to the begining of the array.
>>>
>>> As I have already said '_arr$' does not exist as a distinct separate
>>> entity in the text segment; it used when emitting machine code in the
>>> text segment.
>>>
>>>> A pointer does not need to store a real address a pointer can also
>>>> store
>>>> an offset, as in this case.
>>>
>>> It is not a pointer; it is a constant used when emitting machine code.
>>
>> Oh you want to go to machine code level now?
>> There is no pointers in machine code at all, your argument is nonsense.
>>
>>>
>>>>
>>>>
>>>> Given my stack frame illustration _arr$ points to here:
>>>>
>>>> 00001C [-------------]
>>>> 000018 [--orig ebp---] <- ebp
>>>> 000014 [------0------]
>>>> 000010 [------7------]
>>>> 00000C [------0------] <- _arr$
>>>> 000008 [---00000C---] <- esp
>>>> 000004 [-------------]
>>>> 000000 [-------------]
>>>>
>>>> -12 is an offset into the stack frame, which is the location where the
>>>> array begins.
>>>
>>> Finally. Yes -12 is an offset into the stack frame; we have been
>>> trying to tell you this for the past couple of days; -12 is not a
>>> pointer or a variable it is a constant offset. A realistic and correct
>>> stack frame illustration is:
>>>
>>> 123000 [-------------]
>>> 122FFC [--orig ebp---] <- ebp
>>> 123FF8 [------0------]
>>> 123FF4 [------7------]
>>> 123FF0 [------0------] <- ebp + _arr$
>>> 123FEC [---123FEC---] <- esp
>>> 123FE8 [-------------]
>>> 123FE4 [-------------]
>>>
>>> Notice how I have replaced your deliberately misleading value of 12
>>> (00000C) with a more realistic value that shows that the contents of
>>> the pointer 'px' is unrelated to the number 12; its value is ebp +
>>> _arr$ as encoded into the emitted machine code in the text segment.
>>>
>> There was no deliberate attempt to mislead, It was pure coincidence that
>> the address turned out to be 12. You interpretation is wrong , the value
>> of memory location 123FEC should be 123FF0.
>>
>
> Typical troll: deliberately ignoring my correction. On the small chance
> that you didn't use your newsreader properly yes I did put the wrong value
> in the illustration but that doesn't change the fact that what I said (and
> my "interpretation") is correct: '_arr$' is not a pointer it is a constant
> used when emitting machine code in the text segment.
>
So a simple task like changing the ficticional addresses is obviously too
complicated for you.
You don't even have a clue about machine code, this code is translated into
object code.
Machine code is post linking where all addresses and instructions are
reduced to binary.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-27 16:18 +0100 |
| Message-ID | <MtCdnb8XbZknXULQnZ2dnUVZ8k2dnZ2d@giganews.com> |
| In reply to | #5706 |
On 27/05/2011 15:53, Paul wrote:
>
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:IL-dnVNytsVIKELQnZ2dnUVZ8tydnZ2d@giganews.com...
>> On 27/05/2011 15:24, Paul wrote:
>>>
>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
>>> news:YO-dndRDz9U1LELQnZ2dnUVZ8n2dnZ2d@giganews.com...
>>>> On 27/05/2011 14:34, Paul wrote:
>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Man you really don't have a clue, do you? I'll ask again, How
>>>>>>>>>>>> much
>>>>>>>>>>>> x86
>>>>>>>>>>>> assembly programming have you actually done?
>>>>>>>>>>>>
>>>>>>>>>>> It doesn't matter how much I claim to have done or how much you
>>>>>>>>>>> claim to
>>>>>>>>>>> have done. The fact of the matter is, apparently I know what a
>>>>>>>>>>> pointer
>>>>>>>>>>> is
>>>>>>>>>>> and you don't.
>>>>>>>>>>
>>>>>>>>>> I'll take that as "none".
>>>>>>>>>>
>>>>>>>>>>> A variable whose value is an address(or an offset) to another
>>>>>>>>>>> memory
>>>>>>>>>>> location is a pointer in assembly language.
>>>>>>>>>>
>>>>>>>>>> The *number* -20 isn't a variable any more than arr in "#define
>>>>>>>>>> arr 20"
>>>>>>>>>> is.
>>>>>>>>> Correct -20 is not a variable , it is the value of the variable.
>>>>>>>>
>>>>>>>> It is the value of a constant. By your definition, if I write
>>>>>>>>
>>>>>>>> #define arr -20
>>>>>>>>
>>>>>>>> arr is a variable.
>>>>>>>>
>>>>>>>>>> _arr$ = -20 ; size = 20
>>>>>>>>>>
>>>>>>>>>> is the MASM equivalent of
>>>>>>>>>>
>>>>>>>>>> #define arr = -20 // is arr a pointer?
>>>>>>>>>>
>>>>>>>>>> It is declared in the text segment, it is not an offset into the
>>>>>>>>>> text
>>>>>>>>>> segment.
>>>>>>>>>>
>>>>>>>>> _arr$ is a variable that stores the value -20.
>>>>>>>>
>>>>>>>> No, for the last time it is a constant. Please study a topic before
>>>>>>>> posting about it. From the link I posted earlier:
>>>>>>>>
>>>>>>>> "A manifest constant is a symbol name that represents some fixed
>>>>>>>> quantity during the assembly process. That is it is a symbolic name
>>>>>>>> that represents some value. Equates are the mechanism MASM uses to
>>>>>>>> declare symbolic constants."
>>>>>>>>
>>>>>>>> This is now way off topic. I suggest you find an assembly
>>>>>>>> programming
>>>>>>>> group and see how far you get there.
>>>>>>>>
>>>>>>> Its you that brought it up. And now you seem to be ruinning away
>>>>>>> from
>>>>>>> the argument because you are maybe starting to realise that _arr$
>>>>>>> is a
>>>>>>> pointer.
>>>>>>>
>>>>>>>
>>>>>>> Look at the following code:
>>>>>>>
>>>>>>> int main(){
>>>>>>> int arr[3]={0};
>>>>>>> int* px= arr;
>>>>>>> px[1] = 7;
>>>>>>> }
>>>>>>>
>>>>>>> ; Listing generated by Microsoft (R) Optimizing Compiler Version
>>>>>>> 14.00.50727.762
>>>>>>>
>>>>>>> TITLE C:\cpp\public.cpp
>>>>>>> .686P
>>>>>>> .XMM
>>>>>>> include listing.inc
>>>>>>> .model flat
>>>>>>>
>>>>>>> INCLUDELIB LIBCMT
>>>>>>> INCLUDELIB OLDNAMES
>>>>>>>
>>>>>>> PUBLIC _main
>>>>>>> ; Function compile flags: /Odtp
>>>>>>> _TEXT SEGMENT
>>>>>>> _px$ = -16 ; size = 4
>>>>>>> _arr$ = -12 ; size = 12
>>>>>>> _main PROC
>>>>>>> ; File c:\cpp\public.cpp
>>>>>>> ; Line 5
>>>>>>> push ebp
>>>>>>> mov ebp, esp
>>>>>>> sub esp, 16 ; 00000010H
>>>>>>> ; Line 6
>>>>>>> mov DWORD PTR _arr$[ebp], 0
>>>>>>> xor eax, eax
>>>>>>> mov DWORD PTR _arr$[ebp+4], eax
>>>>>>> mov DWORD PTR _arr$[ebp+8], eax
>>>>>>> ; Line 7
>>>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>>> mov DWORD PTR _px$[ebp], ecx
>>>>>>> ; Line 8
>>>>>>> mov edx, DWORD PTR _px$[ebp]
>>>>>>> mov DWORD PTR [edx+4], 7
>>>>>>> ; Line 9
>>>>>>> xor eax, eax
>>>>>>> mov esp, ebp
>>>>>>> pop ebp
>>>>>>> ret 0
>>>>>>> _main ENDP
>>>>>>> _TEXT ENDS
>>>>>>> END
>>>>>>>
>>>>>>> Line 5-6 Creates a stack frame similar to below. It preserves ebp
>>>>>>> on the
>>>>>>> stack, then assgins the esp value to ebp and then decrements esp
>>>>>>> by 16
>>>>>>> bytes.
>>>>>>> Line 6-7 Initialises the 3 integer objects , of the array, to 0.
>>>>>>> Line 7-8 Stores the address of the first element at the location
>>>>>>> _px$
>>>>>>> points to.
>>>>>>> Line 8-9 Moves the literal value of 7 into the 2nd element of the
>>>>>>> array.
>>>>>>>
>>>>>>>
>>>>>>> 00001C [-------------]
>>>>>>> 000018 [--orig ebp---]<- orig esp
>>>>>>> 000014 [------0------] <-ebp
>>>>>>> 000010 [------7------]
>>>>>>> 00000C [------0------]
>>>>>>> 000008 [---00000C---] <- esp
>>>>>>> 000004 [-------------]
>>>>>>> 000000 [-------------]
>>>>>>>
>>>>>>> After that ebp is popped and esp is back to its original value.
>>>>>>> Face the facts about what a pointer is in assembly programming.
>>>>>>> If you still do not accept these facts then I urge you to refer
>>>>>>> to the
>>>>>>> link I posted about pointer data types by Randy Hyde.
>>>>>>
>>>>>> Now you are arguing with yourself: you have just shown that there is
>>>>>> no special hidden object which containing the address of the array
>>>>>> object; the only thing that contains the address of the array object
>>>>>> above is the pointer 'px'.
>>>>>>
>>>>> No there is a pointer named _arr$, which happens to be in the text
>>>>> segment, it is not on the stack.
>>>>
>>>> No, '_arr$' is not a pointer; '_arr$' is a constant used when emitting
>>>> machine code in the text segment. If does not exist as a separate
>>>> entity in the text segment. lrn2asm.
>>>>
>>>>> Just the same as the pointer _px$ is not on the stack.
>>>>> Look at the value of _px$, it is -16, this doesn't mean it's not a
>>>>> pointer. Its just a pointer that stores an offset, or an index into
>>>>> the
>>>>> stack.
>>>>
>>>> The value of the pointer 'px' is stored on the stack at a location
>>>> stack frame pointer + '_px$' (a constant whose value is -16); we have
>>>> already told you this.
>>>>
>>>>>
>>>>>> For:
>>>>>>
>>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>>
>>>>>> what will actually be emitted is:
>>>>>>
>>>>>> lea ecx, DWORD PTR [ebp-12]
>>>>>>
>>>>>> as '_arr$' is a constant; not a variable or a "pointer".
>>>>>
>>>>> _arr$ holds an offset which is added to ebp to create the real
>>>>> address.
>>>>
>>>> Correct we have already told you this.
>>>>
>>>>> _arr$ is a constant only because it is stored in the read only text
>>>>> segment. This does not mean it is not a pointer , it stores an offset
>>>>> that points to the begining of the array.
>>>>
>>>> As I have already said '_arr$' does not exist as a distinct separate
>>>> entity in the text segment; it used when emitting machine code in the
>>>> text segment.
>>>>
>>>>> A pointer does not need to store a real address a pointer can also
>>>>> store
>>>>> an offset, as in this case.
>>>>
>>>> It is not a pointer; it is a constant used when emitting machine code.
>>>
>>> Oh you want to go to machine code level now?
>>> There is no pointers in machine code at all, your argument is nonsense.
>>>
>>>>
>>>>>
>>>>>
>>>>> Given my stack frame illustration _arr$ points to here:
>>>>>
>>>>> 00001C [-------------]
>>>>> 000018 [--orig ebp---] <- ebp
>>>>> 000014 [------0------]
>>>>> 000010 [------7------]
>>>>> 00000C [------0------] <- _arr$
>>>>> 000008 [---00000C---] <- esp
>>>>> 000004 [-------------]
>>>>> 000000 [-------------]
>>>>>
>>>>> -12 is an offset into the stack frame, which is the location where the
>>>>> array begins.
>>>>
>>>> Finally. Yes -12 is an offset into the stack frame; we have been
>>>> trying to tell you this for the past couple of days; -12 is not a
>>>> pointer or a variable it is a constant offset. A realistic and correct
>>>> stack frame illustration is:
>>>>
>>>> 123000 [-------------]
>>>> 122FFC [--orig ebp---] <- ebp
>>>> 123FF8 [------0------]
>>>> 123FF4 [------7------]
>>>> 123FF0 [------0------] <- ebp + _arr$
>>>> 123FEC [---123FEC---] <- esp
>>>> 123FE8 [-------------]
>>>> 123FE4 [-------------]
>>>>
>>>> Notice how I have replaced your deliberately misleading value of 12
>>>> (00000C) with a more realistic value that shows that the contents of
>>>> the pointer 'px' is unrelated to the number 12; its value is ebp +
>>>> _arr$ as encoded into the emitted machine code in the text segment.
>>>>
>>> There was no deliberate attempt to mislead, It was pure coincidence that
>>> the address turned out to be 12. You interpretation is wrong , the value
>>> of memory location 123FEC should be 123FF0.
>>>
>>
>> Typical troll: deliberately ignoring my correction. On the small
>> chance that you didn't use your newsreader properly yes I did put the
>> wrong value in the illustration but that doesn't change the fact that
>> what I said (and my "interpretation") is correct: '_arr$' is not a
>> pointer it is a constant used when emitting machine code in the text
>> segment.
>>
> So a simple task like changing the ficticional addresses is obviously
> too complicated for you.
Your original stack frame illustration also contained an error which you
silently corrected so following your logic you are also unable to
perform such a simple task.
>
> You don't even have a clue about machine code, this code is translated
> into object code.
> Machine code is post linking where all addresses and instructions are
> reduced to binary.
You are the one without a clue: an object file contains machine code
along with relocation information and stack frame pointer offsets do not
require relocation.
lrn2asm.
/Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-27 20:35 +0100 |
| Message-ID | <S1TDp.13619$f95.10328@newsfe02.ams2> |
| In reply to | #5708 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:MtCdnb8XbZknXULQnZ2dnUVZ8k2dnZ2d@giganews.com...
> On 27/05/2011 15:53, Paul wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Man you really don't have a clue, do you? I'll ask again, How
>>>>>>>>>>>>> much
>>>>>>>>>>>>> x86
>>>>>>>>>>>>> assembly programming have you actually done?
>>>>>>>>>>>>>
>>>>>>>>>>>> It doesn't matter how much I claim to have done or how much you
>>>>>>>>>>>> claim to
>>>>>>>>>>>> have done. The fact of the matter is, apparently I know what a
>>>>>>>>>>>> pointer
>>>>>>>>>>>> is
>>>>>>>>>>>> and you don't.
>>>>>>>>>>>
>>>>>>>>>>> I'll take that as "none".
>>>>>>>>>>>
>>>>>>>>>>>> A variable whose value is an address(or an offset) to another
>>>>>>>>>>>> memory
>>>>>>>>>>>> location is a pointer in assembly language.
>>>>>>>>>>>
>>>>>>>>>>> The *number* -20 isn't a variable any more than arr in "#define
>>>>>>>>>>> arr 20"
>>>>>>>>>>> is.
>>>>>>>>>> Correct -20 is not a variable , it is the value of the variable.
>>>>>>>>>
>>>>>>>>> It is the value of a constant. By your definition, if I write
>>>>>>>>>
>>>>>>>>> #define arr -20
>>>>>>>>>
>>>>>>>>> arr is a variable.
>>>>>>>>>
>>>>>>>>>>> _arr$ = -20 ; size = 20
>>>>>>>>>>>
>>>>>>>>>>> is the MASM equivalent of
>>>>>>>>>>>
>>>>>>>>>>> #define arr = -20 // is arr a pointer?
>>>>>>>>>>>
>>>>>>>>>>> It is declared in the text segment, it is not an offset into the
>>>>>>>>>>> text
>>>>>>>>>>> segment.
>>>>>>>>>>>
>>>>>>>>>> _arr$ is a variable that stores the value -20.
>>>>>>>>>
>>>>>>>>> No, for the last time it is a constant. Please study a topic
>>>>>>>>> before
>>>>>>>>> posting about it. From the link I posted earlier:
>>>>>>>>>
>>>>>>>>> "A manifest constant is a symbol name that represents some fixed
>>>>>>>>> quantity during the assembly process. That is it is a symbolic
>>>>>>>>> name
>>>>>>>>> that represents some value. Equates are the mechanism MASM uses to
>>>>>>>>> declare symbolic constants."
>>>>>>>>>
>>>>>>>>> This is now way off topic. I suggest you find an assembly
>>>>>>>>> programming
>>>>>>>>> group and see how far you get there.
>>>>>>>>>
>>>>>>>> Its you that brought it up. And now you seem to be ruinning away
>>>>>>>> from
>>>>>>>> the argument because you are maybe starting to realise that _arr$
>>>>>>>> is a
>>>>>>>> pointer.
>>>>>>>>
>>>>>>>>
>>>>>>>> Look at the following code:
>>>>>>>>
>>>>>>>> int main(){
>>>>>>>> int arr[3]={0};
>>>>>>>> int* px= arr;
>>>>>>>> px[1] = 7;
>>>>>>>> }
>>>>>>>>
>>>>>>>> ; Listing generated by Microsoft (R) Optimizing Compiler Version
>>>>>>>> 14.00.50727.762
>>>>>>>>
>>>>>>>> TITLE C:\cpp\public.cpp
>>>>>>>> .686P
>>>>>>>> .XMM
>>>>>>>> include listing.inc
>>>>>>>> .model flat
>>>>>>>>
>>>>>>>> INCLUDELIB LIBCMT
>>>>>>>> INCLUDELIB OLDNAMES
>>>>>>>>
>>>>>>>> PUBLIC _main
>>>>>>>> ; Function compile flags: /Odtp
>>>>>>>> _TEXT SEGMENT
>>>>>>>> _px$ = -16 ; size = 4
>>>>>>>> _arr$ = -12 ; size = 12
>>>>>>>> _main PROC
>>>>>>>> ; File c:\cpp\public.cpp
>>>>>>>> ; Line 5
>>>>>>>> push ebp
>>>>>>>> mov ebp, esp
>>>>>>>> sub esp, 16 ; 00000010H
>>>>>>>> ; Line 6
>>>>>>>> mov DWORD PTR _arr$[ebp], 0
>>>>>>>> xor eax, eax
>>>>>>>> mov DWORD PTR _arr$[ebp+4], eax
>>>>>>>> mov DWORD PTR _arr$[ebp+8], eax
>>>>>>>> ; Line 7
>>>>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>>>> mov DWORD PTR _px$[ebp], ecx
>>>>>>>> ; Line 8
>>>>>>>> mov edx, DWORD PTR _px$[ebp]
>>>>>>>> mov DWORD PTR [edx+4], 7
>>>>>>>> ; Line 9
>>>>>>>> xor eax, eax
>>>>>>>> mov esp, ebp
>>>>>>>> pop ebp
>>>>>>>> ret 0
>>>>>>>> _main ENDP
>>>>>>>> _TEXT ENDS
>>>>>>>> END
>>>>>>>>
>>>>>>>> Line 5-6 Creates a stack frame similar to below. It preserves ebp
>>>>>>>> on the
>>>>>>>> stack, then assgins the esp value to ebp and then decrements esp
>>>>>>>> by 16
>>>>>>>> bytes.
>>>>>>>> Line 6-7 Initialises the 3 integer objects , of the array, to 0.
>>>>>>>> Line 7-8 Stores the address of the first element at the location
>>>>>>>> _px$
>>>>>>>> points to.
>>>>>>>> Line 8-9 Moves the literal value of 7 into the 2nd element of the
>>>>>>>> array.
>>>>>>>>
>>>>>>>>
>>>>>>>> 00001C [-------------]
>>>>>>>> 000018 [--orig ebp---]<- orig esp
>>>>>>>> 000014 [------0------] <-ebp
>>>>>>>> 000010 [------7------]
>>>>>>>> 00000C [------0------]
>>>>>>>> 000008 [---00000C---] <- esp
>>>>>>>> 000004 [-------------]
>>>>>>>> 000000 [-------------]
>>>>>>>>
>>>>>>>> After that ebp is popped and esp is back to its original value.
>>>>>>>> Face the facts about what a pointer is in assembly programming.
>>>>>>>> If you still do not accept these facts then I urge you to refer
>>>>>>>> to the
>>>>>>>> link I posted about pointer data types by Randy Hyde.
>>>>>>>
>>>>>>> Now you are arguing with yourself: you have just shown that there is
>>>>>>> no special hidden object which containing the address of the array
>>>>>>> object; the only thing that contains the address of the array object
>>>>>>> above is the pointer 'px'.
>>>>>>>
>>>>>> No there is a pointer named _arr$, which happens to be in the text
>>>>>> segment, it is not on the stack.
>>>>>
>>>>> No, '_arr$' is not a pointer; '_arr$' is a constant used when emitting
>>>>> machine code in the text segment. If does not exist as a separate
>>>>> entity in the text segment. lrn2asm.
>>>>>
>>>>>> Just the same as the pointer _px$ is not on the stack.
>>>>>> Look at the value of _px$, it is -16, this doesn't mean it's not a
>>>>>> pointer. Its just a pointer that stores an offset, or an index into
>>>>>> the
>>>>>> stack.
>>>>>
>>>>> The value of the pointer 'px' is stored on the stack at a location
>>>>> stack frame pointer + '_px$' (a constant whose value is -16); we have
>>>>> already told you this.
>>>>>
>>>>>>
>>>>>>> For:
>>>>>>>
>>>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>>>
>>>>>>> what will actually be emitted is:
>>>>>>>
>>>>>>> lea ecx, DWORD PTR [ebp-12]
>>>>>>>
>>>>>>> as '_arr$' is a constant; not a variable or a "pointer".
>>>>>>
>>>>>> _arr$ holds an offset which is added to ebp to create the real
>>>>>> address.
>>>>>
>>>>> Correct we have already told you this.
>>>>>
>>>>>> _arr$ is a constant only because it is stored in the read only text
>>>>>> segment. This does not mean it is not a pointer , it stores an offset
>>>>>> that points to the begining of the array.
>>>>>
>>>>> As I have already said '_arr$' does not exist as a distinct separate
>>>>> entity in the text segment; it used when emitting machine code in the
>>>>> text segment.
>>>>>
>>>>>> A pointer does not need to store a real address a pointer can also
>>>>>> store
>>>>>> an offset, as in this case.
>>>>>
>>>>> It is not a pointer; it is a constant used when emitting machine code.
>>>>
>>>> Oh you want to go to machine code level now?
>>>> There is no pointers in machine code at all, your argument is nonsense.
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Given my stack frame illustration _arr$ points to here:
>>>>>>
>>>>>> 00001C [-------------]
>>>>>> 000018 [--orig ebp---] <- ebp
>>>>>> 000014 [------0------]
>>>>>> 000010 [------7------]
>>>>>> 00000C [------0------] <- _arr$
>>>>>> 000008 [---00000C---] <- esp
>>>>>> 000004 [-------------]
>>>>>> 000000 [-------------]
>>>>>>
>>>>>> -12 is an offset into the stack frame, which is the location where
>>>>>> the
>>>>>> array begins.
>>>>>
>>>>> Finally. Yes -12 is an offset into the stack frame; we have been
>>>>> trying to tell you this for the past couple of days; -12 is not a
>>>>> pointer or a variable it is a constant offset. A realistic and correct
>>>>> stack frame illustration is:
>>>>>
>>>>> 123000 [-------------]
>>>>> 122FFC [--orig ebp---] <- ebp
>>>>> 123FF8 [------0------]
>>>>> 123FF4 [------7------]
>>>>> 123FF0 [------0------] <- ebp + _arr$
>>>>> 123FEC [---123FEC---] <- esp
>>>>> 123FE8 [-------------]
>>>>> 123FE4 [-------------]
>>>>>
>>>>> Notice how I have replaced your deliberately misleading value of 12
>>>>> (00000C) with a more realistic value that shows that the contents of
>>>>> the pointer 'px' is unrelated to the number 12; its value is ebp +
>>>>> _arr$ as encoded into the emitted machine code in the text segment.
>>>>>
>>>> There was no deliberate attempt to mislead, It was pure coincidence
>>>> that
>>>> the address turned out to be 12. You interpretation is wrong , the
>>>> value
>>>> of memory location 123FEC should be 123FF0.
>>>>
>>>
>>> Typical troll: deliberately ignoring my correction. On the small
>>> chance that you didn't use your newsreader properly yes I did put the
>>> wrong value in the illustration but that doesn't change the fact that
>>> what I said (and my "interpretation") is correct: '_arr$' is not a
>>> pointer it is a constant used when emitting machine code in the text
>>> segment.
>>>
>> So a simple task like changing the ficticional addresses is obviously
>> too complicated for you.
>
> Your original stack frame illustration also contained an error which you
> silently corrected so following your logic you are also unable to perform
> such a simple task.
>
My original illustration demonstrated knowledge of the code presented and
understanding of how the computer system works.
I didn't *silently* correct it, I corrected on small error that was a
text -> graphical asciiart mistake.
There is more complexity in what I did to interpret the code and convert
this into a stack ullustration than simply changing the ficticional
addresses.
>>
>> You don't even have a clue about machine code, this code is translated
>> into object code.
>> Machine code is post linking where all addresses and instructions are
>> reduced to binary.
>
> You are the one without a clue: an object file contains machine code along
> with relocation information and stack frame pointer offsets do not require
> relocation.
>
True an object file does contain machine code but this does not change the
fact that you are changing the goalpoasts to a lower level of code, you will
eventually get to the point where you are saying that a binary file does not
contain pointers therefore _arr$ is not a pointer.
If I change the C++ code to
int arr[3]={0};
int main(){
arr[1] = 5;
}
When you inspect the object file you will see that this array is not
optimised into a literal value at machine code level.
When I examine dumpbin arr is a symbol and its name is ?arr@@3PAHA (int *
arr)
Note that dumpbin displays this symbol with the addition info (int* arr),
this is compiled as a coff on a MS machine.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-27 21:23 +0100 |
| Message-ID | <keGdnRLkX8-wlX3QnZ2dnUVZ8qadnZ2d@giganews.com> |
| In reply to | #5724 |
On 27/05/2011 20:35, Paul wrote:
>
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:MtCdnb8XbZknXULQnZ2dnUVZ8k2dnZ2d@giganews.com...
>> On 27/05/2011 15:53, Paul wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Man you really don't have a clue, do you? I'll ask again, How
>>>>>>>>>>>>>> much
>>>>>>>>>>>>>> x86
>>>>>>>>>>>>>> assembly programming have you actually done?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> It doesn't matter how much I claim to have done or how much
>>>>>>>>>>>>> you
>>>>>>>>>>>>> claim to
>>>>>>>>>>>>> have done. The fact of the matter is, apparently I know what a
>>>>>>>>>>>>> pointer
>>>>>>>>>>>>> is
>>>>>>>>>>>>> and you don't.
>>>>>>>>>>>>
>>>>>>>>>>>> I'll take that as "none".
>>>>>>>>>>>>
>>>>>>>>>>>>> A variable whose value is an address(or an offset) to another
>>>>>>>>>>>>> memory
>>>>>>>>>>>>> location is a pointer in assembly language.
>>>>>>>>>>>>
>>>>>>>>>>>> The *number* -20 isn't a variable any more than arr in "#define
>>>>>>>>>>>> arr 20"
>>>>>>>>>>>> is.
>>>>>>>>>>> Correct -20 is not a variable , it is the value of the variable.
>>>>>>>>>>
>>>>>>>>>> It is the value of a constant. By your definition, if I write
>>>>>>>>>>
>>>>>>>>>> #define arr -20
>>>>>>>>>>
>>>>>>>>>> arr is a variable.
>>>>>>>>>>
>>>>>>>>>>>> _arr$ = -20 ; size = 20
>>>>>>>>>>>>
>>>>>>>>>>>> is the MASM equivalent of
>>>>>>>>>>>>
>>>>>>>>>>>> #define arr = -20 // is arr a pointer?
>>>>>>>>>>>>
>>>>>>>>>>>> It is declared in the text segment, it is not an offset into
>>>>>>>>>>>> the
>>>>>>>>>>>> text
>>>>>>>>>>>> segment.
>>>>>>>>>>>>
>>>>>>>>>>> _arr$ is a variable that stores the value -20.
>>>>>>>>>>
>>>>>>>>>> No, for the last time it is a constant. Please study a topic
>>>>>>>>>> before
>>>>>>>>>> posting about it. From the link I posted earlier:
>>>>>>>>>>
>>>>>>>>>> "A manifest constant is a symbol name that represents some fixed
>>>>>>>>>> quantity during the assembly process. That is it is a symbolic
>>>>>>>>>> name
>>>>>>>>>> that represents some value. Equates are the mechanism MASM
>>>>>>>>>> uses to
>>>>>>>>>> declare symbolic constants."
>>>>>>>>>>
>>>>>>>>>> This is now way off topic. I suggest you find an assembly
>>>>>>>>>> programming
>>>>>>>>>> group and see how far you get there.
>>>>>>>>>>
>>>>>>>>> Its you that brought it up. And now you seem to be ruinning away
>>>>>>>>> from
>>>>>>>>> the argument because you are maybe starting to realise that _arr$
>>>>>>>>> is a
>>>>>>>>> pointer.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Look at the following code:
>>>>>>>>>
>>>>>>>>> int main(){
>>>>>>>>> int arr[3]={0};
>>>>>>>>> int* px= arr;
>>>>>>>>> px[1] = 7;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> ; Listing generated by Microsoft (R) Optimizing Compiler Version
>>>>>>>>> 14.00.50727.762
>>>>>>>>>
>>>>>>>>> TITLE C:\cpp\public.cpp
>>>>>>>>> .686P
>>>>>>>>> .XMM
>>>>>>>>> include listing.inc
>>>>>>>>> .model flat
>>>>>>>>>
>>>>>>>>> INCLUDELIB LIBCMT
>>>>>>>>> INCLUDELIB OLDNAMES
>>>>>>>>>
>>>>>>>>> PUBLIC _main
>>>>>>>>> ; Function compile flags: /Odtp
>>>>>>>>> _TEXT SEGMENT
>>>>>>>>> _px$ = -16 ; size = 4
>>>>>>>>> _arr$ = -12 ; size = 12
>>>>>>>>> _main PROC
>>>>>>>>> ; File c:\cpp\public.cpp
>>>>>>>>> ; Line 5
>>>>>>>>> push ebp
>>>>>>>>> mov ebp, esp
>>>>>>>>> sub esp, 16 ; 00000010H
>>>>>>>>> ; Line 6
>>>>>>>>> mov DWORD PTR _arr$[ebp], 0
>>>>>>>>> xor eax, eax
>>>>>>>>> mov DWORD PTR _arr$[ebp+4], eax
>>>>>>>>> mov DWORD PTR _arr$[ebp+8], eax
>>>>>>>>> ; Line 7
>>>>>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>>>>> mov DWORD PTR _px$[ebp], ecx
>>>>>>>>> ; Line 8
>>>>>>>>> mov edx, DWORD PTR _px$[ebp]
>>>>>>>>> mov DWORD PTR [edx+4], 7
>>>>>>>>> ; Line 9
>>>>>>>>> xor eax, eax
>>>>>>>>> mov esp, ebp
>>>>>>>>> pop ebp
>>>>>>>>> ret 0
>>>>>>>>> _main ENDP
>>>>>>>>> _TEXT ENDS
>>>>>>>>> END
>>>>>>>>>
>>>>>>>>> Line 5-6 Creates a stack frame similar to below. It preserves ebp
>>>>>>>>> on the
>>>>>>>>> stack, then assgins the esp value to ebp and then decrements esp
>>>>>>>>> by 16
>>>>>>>>> bytes.
>>>>>>>>> Line 6-7 Initialises the 3 integer objects , of the array, to 0.
>>>>>>>>> Line 7-8 Stores the address of the first element at the location
>>>>>>>>> _px$
>>>>>>>>> points to.
>>>>>>>>> Line 8-9 Moves the literal value of 7 into the 2nd element of the
>>>>>>>>> array.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 00001C [-------------]
>>>>>>>>> 000018 [--orig ebp---]<- orig esp
>>>>>>>>> 000014 [------0------] <-ebp
>>>>>>>>> 000010 [------7------]
>>>>>>>>> 00000C [------0------]
>>>>>>>>> 000008 [---00000C---] <- esp
>>>>>>>>> 000004 [-------------]
>>>>>>>>> 000000 [-------------]
>>>>>>>>>
>>>>>>>>> After that ebp is popped and esp is back to its original value.
>>>>>>>>> Face the facts about what a pointer is in assembly programming.
>>>>>>>>> If you still do not accept these facts then I urge you to refer
>>>>>>>>> to the
>>>>>>>>> link I posted about pointer data types by Randy Hyde.
>>>>>>>>
>>>>>>>> Now you are arguing with yourself: you have just shown that
>>>>>>>> there is
>>>>>>>> no special hidden object which containing the address of the array
>>>>>>>> object; the only thing that contains the address of the array
>>>>>>>> object
>>>>>>>> above is the pointer 'px'.
>>>>>>>>
>>>>>>> No there is a pointer named _arr$, which happens to be in the text
>>>>>>> segment, it is not on the stack.
>>>>>>
>>>>>> No, '_arr$' is not a pointer; '_arr$' is a constant used when
>>>>>> emitting
>>>>>> machine code in the text segment. If does not exist as a separate
>>>>>> entity in the text segment. lrn2asm.
>>>>>>
>>>>>>> Just the same as the pointer _px$ is not on the stack.
>>>>>>> Look at the value of _px$, it is -16, this doesn't mean it's not a
>>>>>>> pointer. Its just a pointer that stores an offset, or an index into
>>>>>>> the
>>>>>>> stack.
>>>>>>
>>>>>> The value of the pointer 'px' is stored on the stack at a location
>>>>>> stack frame pointer + '_px$' (a constant whose value is -16); we have
>>>>>> already told you this.
>>>>>>
>>>>>>>
>>>>>>>> For:
>>>>>>>>
>>>>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>>>>
>>>>>>>> what will actually be emitted is:
>>>>>>>>
>>>>>>>> lea ecx, DWORD PTR [ebp-12]
>>>>>>>>
>>>>>>>> as '_arr$' is a constant; not a variable or a "pointer".
>>>>>>>
>>>>>>> _arr$ holds an offset which is added to ebp to create the real
>>>>>>> address.
>>>>>>
>>>>>> Correct we have already told you this.
>>>>>>
>>>>>>> _arr$ is a constant only because it is stored in the read only text
>>>>>>> segment. This does not mean it is not a pointer , it stores an
>>>>>>> offset
>>>>>>> that points to the begining of the array.
>>>>>>
>>>>>> As I have already said '_arr$' does not exist as a distinct separate
>>>>>> entity in the text segment; it used when emitting machine code in the
>>>>>> text segment.
>>>>>>
>>>>>>> A pointer does not need to store a real address a pointer can also
>>>>>>> store
>>>>>>> an offset, as in this case.
>>>>>>
>>>>>> It is not a pointer; it is a constant used when emitting machine
>>>>>> code.
>>>>>
>>>>> Oh you want to go to machine code level now?
>>>>> There is no pointers in machine code at all, your argument is
>>>>> nonsense.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Given my stack frame illustration _arr$ points to here:
>>>>>>>
>>>>>>> 00001C [-------------]
>>>>>>> 000018 [--orig ebp---] <- ebp
>>>>>>> 000014 [------0------]
>>>>>>> 000010 [------7------]
>>>>>>> 00000C [------0------] <- _arr$
>>>>>>> 000008 [---00000C---] <- esp
>>>>>>> 000004 [-------------]
>>>>>>> 000000 [-------------]
>>>>>>>
>>>>>>> -12 is an offset into the stack frame, which is the location
>>>>>>> where the
>>>>>>> array begins.
>>>>>>
>>>>>> Finally. Yes -12 is an offset into the stack frame; we have been
>>>>>> trying to tell you this for the past couple of days; -12 is not a
>>>>>> pointer or a variable it is a constant offset. A realistic and
>>>>>> correct
>>>>>> stack frame illustration is:
>>>>>>
>>>>>> 123000 [-------------]
>>>>>> 122FFC [--orig ebp---] <- ebp
>>>>>> 123FF8 [------0------]
>>>>>> 123FF4 [------7------]
>>>>>> 123FF0 [------0------] <- ebp + _arr$
>>>>>> 123FEC [---123FEC---] <- esp
>>>>>> 123FE8 [-------------]
>>>>>> 123FE4 [-------------]
>>>>>>
>>>>>> Notice how I have replaced your deliberately misleading value of 12
>>>>>> (00000C) with a more realistic value that shows that the contents of
>>>>>> the pointer 'px' is unrelated to the number 12; its value is ebp +
>>>>>> _arr$ as encoded into the emitted machine code in the text segment.
>>>>>>
>>>>> There was no deliberate attempt to mislead, It was pure coincidence
>>>>> that
>>>>> the address turned out to be 12. You interpretation is wrong , the
>>>>> value
>>>>> of memory location 123FEC should be 123FF0.
>>>>>
>>>>
>>>> Typical troll: deliberately ignoring my correction. On the small
>>>> chance that you didn't use your newsreader properly yes I did put the
>>>> wrong value in the illustration but that doesn't change the fact that
>>>> what I said (and my "interpretation") is correct: '_arr$' is not a
>>>> pointer it is a constant used when emitting machine code in the text
>>>> segment.
>>>>
>>> So a simple task like changing the ficticional addresses is obviously
>>> too complicated for you.
>>
>> Your original stack frame illustration also contained an error which
>> you silently corrected so following your logic you are also unable to
>> perform such a simple task.
>>
> My original illustration demonstrated knowledge of the code presented
> and understanding of how the computer system works.
> I didn't *silently* correct it, I corrected on small error that was a
> text -> graphical asciiart mistake.
> There is more complexity in what I did to interpret the code and convert
> this into a stack ullustration than simply changing the ficticional
> addresses.
No it contained a major error (ebp pointing to the wrong thing) but meh
who cares? You are the one who pounced on *my* minor error; an error
which I publicly corrected; a correction you chose to ignore to try and
score points due to your immaturity; immaturity which you have displayed
numerous times in this newsgroup.
>
>>>
>>> You don't even have a clue about machine code, this code is translated
>>> into object code.
>>> Machine code is post linking where all addresses and instructions are
>>> reduced to binary.
>>
>> You are the one without a clue: an object file contains machine code
>> along with relocation information and stack frame pointer offsets do
>> not require relocation.
>>
> True an object file does contain machine code but this does not change
> the fact that you are changing the goalpoasts to a lower level of code,
> you will eventually get to the point where you are saying that a binary
> file does not contain pointers therefore _arr$ is not a pointer.
'_arr$' is not a pointer; it is a constant used when emitting machine
code for the text segment; it is a transient artefact of the compilation
process.
>
> If I change the C++ code to
>
> int arr[3]={0};
> int main(){
> arr[1] = 5;
> }
>
> When you inspect the object file you will see that this array is not
> optimised into a literal value at machine code level.
What has this got to do with what we have been talking about? Here the
array is of static storage duration so has a fixed address requiring
relocation during linking.
>
> When I examine dumpbin arr is a symbol and its name is ?arr@@3PAHA (int
> * arr)
Of course arr has a symbolic name; what is your point? This has nothing
to do with the possible existance of this mythical object of yours that
contains the memory address of an array.
>
> Note that dumpbin displays this symbol with the addition info (int*
> arr), this is compiled as a coff on a MS machine.
Your basic problem (in addition to immaturity) is one of pride and of
being unable to own up to your mistakes. You won't even apologize for
your previous obnoxious insults.
HTH.
/Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-27 22:04 +0100 |
| Message-ID | <imUDp.13659$f95.5285@newsfe02.ams2> |
| In reply to | #5730 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:keGdnRLkX8-wlX3QnZ2dnUVZ8qadnZ2d@giganews.com...
> On 27/05/2011 20:35, Paul wrote:
>>
>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
>> news:MtCdnb8XbZknXULQnZ2dnUVZ8k2dnZ2d@giganews.com...
>>> On 27/05/2011 15:53, Paul wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Man you really don't have a clue, do you? I'll ask again,
>>>>>>>>>>>>>>> How
>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>> x86
>>>>>>>>>>>>>>> assembly programming have you actually done?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It doesn't matter how much I claim to have done or how much
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>> claim to
>>>>>>>>>>>>>> have done. The fact of the matter is, apparently I know what
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> pointer
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> and you don't.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'll take that as "none".
>>>>>>>>>>>>>
>>>>>>>>>>>>>> A variable whose value is an address(or an offset) to another
>>>>>>>>>>>>>> memory
>>>>>>>>>>>>>> location is a pointer in assembly language.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The *number* -20 isn't a variable any more than arr in
>>>>>>>>>>>>> "#define
>>>>>>>>>>>>> arr 20"
>>>>>>>>>>>>> is.
>>>>>>>>>>>> Correct -20 is not a variable , it is the value of the
>>>>>>>>>>>> variable.
>>>>>>>>>>>
>>>>>>>>>>> It is the value of a constant. By your definition, if I write
>>>>>>>>>>>
>>>>>>>>>>> #define arr -20
>>>>>>>>>>>
>>>>>>>>>>> arr is a variable.
>>>>>>>>>>>
>>>>>>>>>>>>> _arr$ = -20 ; size = 20
>>>>>>>>>>>>>
>>>>>>>>>>>>> is the MASM equivalent of
>>>>>>>>>>>>>
>>>>>>>>>>>>> #define arr = -20 // is arr a pointer?
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is declared in the text segment, it is not an offset into
>>>>>>>>>>>>> the
>>>>>>>>>>>>> text
>>>>>>>>>>>>> segment.
>>>>>>>>>>>>>
>>>>>>>>>>>> _arr$ is a variable that stores the value -20.
>>>>>>>>>>>
>>>>>>>>>>> No, for the last time it is a constant. Please study a topic
>>>>>>>>>>> before
>>>>>>>>>>> posting about it. From the link I posted earlier:
>>>>>>>>>>>
>>>>>>>>>>> "A manifest constant is a symbol name that represents some fixed
>>>>>>>>>>> quantity during the assembly process. That is it is a symbolic
>>>>>>>>>>> name
>>>>>>>>>>> that represents some value. Equates are the mechanism MASM
>>>>>>>>>>> uses to
>>>>>>>>>>> declare symbolic constants."
>>>>>>>>>>>
>>>>>>>>>>> This is now way off topic. I suggest you find an assembly
>>>>>>>>>>> programming
>>>>>>>>>>> group and see how far you get there.
>>>>>>>>>>>
>>>>>>>>>> Its you that brought it up. And now you seem to be ruinning away
>>>>>>>>>> from
>>>>>>>>>> the argument because you are maybe starting to realise that _arr$
>>>>>>>>>> is a
>>>>>>>>>> pointer.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Look at the following code:
>>>>>>>>>>
>>>>>>>>>> int main(){
>>>>>>>>>> int arr[3]={0};
>>>>>>>>>> int* px= arr;
>>>>>>>>>> px[1] = 7;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> ; Listing generated by Microsoft (R) Optimizing Compiler Version
>>>>>>>>>> 14.00.50727.762
>>>>>>>>>>
>>>>>>>>>> TITLE C:\cpp\public.cpp
>>>>>>>>>> .686P
>>>>>>>>>> .XMM
>>>>>>>>>> include listing.inc
>>>>>>>>>> .model flat
>>>>>>>>>>
>>>>>>>>>> INCLUDELIB LIBCMT
>>>>>>>>>> INCLUDELIB OLDNAMES
>>>>>>>>>>
>>>>>>>>>> PUBLIC _main
>>>>>>>>>> ; Function compile flags: /Odtp
>>>>>>>>>> _TEXT SEGMENT
>>>>>>>>>> _px$ = -16 ; size = 4
>>>>>>>>>> _arr$ = -12 ; size = 12
>>>>>>>>>> _main PROC
>>>>>>>>>> ; File c:\cpp\public.cpp
>>>>>>>>>> ; Line 5
>>>>>>>>>> push ebp
>>>>>>>>>> mov ebp, esp
>>>>>>>>>> sub esp, 16 ; 00000010H
>>>>>>>>>> ; Line 6
>>>>>>>>>> mov DWORD PTR _arr$[ebp], 0
>>>>>>>>>> xor eax, eax
>>>>>>>>>> mov DWORD PTR _arr$[ebp+4], eax
>>>>>>>>>> mov DWORD PTR _arr$[ebp+8], eax
>>>>>>>>>> ; Line 7
>>>>>>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>>>>>> mov DWORD PTR _px$[ebp], ecx
>>>>>>>>>> ; Line 8
>>>>>>>>>> mov edx, DWORD PTR _px$[ebp]
>>>>>>>>>> mov DWORD PTR [edx+4], 7
>>>>>>>>>> ; Line 9
>>>>>>>>>> xor eax, eax
>>>>>>>>>> mov esp, ebp
>>>>>>>>>> pop ebp
>>>>>>>>>> ret 0
>>>>>>>>>> _main ENDP
>>>>>>>>>> _TEXT ENDS
>>>>>>>>>> END
>>>>>>>>>>
>>>>>>>>>> Line 5-6 Creates a stack frame similar to below. It preserves ebp
>>>>>>>>>> on the
>>>>>>>>>> stack, then assgins the esp value to ebp and then decrements esp
>>>>>>>>>> by 16
>>>>>>>>>> bytes.
>>>>>>>>>> Line 6-7 Initialises the 3 integer objects , of the array, to 0.
>>>>>>>>>> Line 7-8 Stores the address of the first element at the location
>>>>>>>>>> _px$
>>>>>>>>>> points to.
>>>>>>>>>> Line 8-9 Moves the literal value of 7 into the 2nd element of the
>>>>>>>>>> array.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 00001C [-------------]
>>>>>>>>>> 000018 [--orig ebp---]<- orig esp
>>>>>>>>>> 000014 [------0------] <-ebp
>>>>>>>>>> 000010 [------7------]
>>>>>>>>>> 00000C [------0------]
>>>>>>>>>> 000008 [---00000C---] <- esp
>>>>>>>>>> 000004 [-------------]
>>>>>>>>>> 000000 [-------------]
>>>>>>>>>>
>>>>>>>>>> After that ebp is popped and esp is back to its original value.
>>>>>>>>>> Face the facts about what a pointer is in assembly programming.
>>>>>>>>>> If you still do not accept these facts then I urge you to refer
>>>>>>>>>> to the
>>>>>>>>>> link I posted about pointer data types by Randy Hyde.
>>>>>>>>>
>>>>>>>>> Now you are arguing with yourself: you have just shown that
>>>>>>>>> there is
>>>>>>>>> no special hidden object which containing the address of the array
>>>>>>>>> object; the only thing that contains the address of the array
>>>>>>>>> object
>>>>>>>>> above is the pointer 'px'.
>>>>>>>>>
>>>>>>>> No there is a pointer named _arr$, which happens to be in the text
>>>>>>>> segment, it is not on the stack.
>>>>>>>
>>>>>>> No, '_arr$' is not a pointer; '_arr$' is a constant used when
>>>>>>> emitting
>>>>>>> machine code in the text segment. If does not exist as a separate
>>>>>>> entity in the text segment. lrn2asm.
>>>>>>>
>>>>>>>> Just the same as the pointer _px$ is not on the stack.
>>>>>>>> Look at the value of _px$, it is -16, this doesn't mean it's not a
>>>>>>>> pointer. Its just a pointer that stores an offset, or an index into
>>>>>>>> the
>>>>>>>> stack.
>>>>>>>
>>>>>>> The value of the pointer 'px' is stored on the stack at a location
>>>>>>> stack frame pointer + '_px$' (a constant whose value is -16); we
>>>>>>> have
>>>>>>> already told you this.
>>>>>>>
>>>>>>>>
>>>>>>>>> For:
>>>>>>>>>
>>>>>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>>>>>
>>>>>>>>> what will actually be emitted is:
>>>>>>>>>
>>>>>>>>> lea ecx, DWORD PTR [ebp-12]
>>>>>>>>>
>>>>>>>>> as '_arr$' is a constant; not a variable or a "pointer".
>>>>>>>>
>>>>>>>> _arr$ holds an offset which is added to ebp to create the real
>>>>>>>> address.
>>>>>>>
>>>>>>> Correct we have already told you this.
>>>>>>>
>>>>>>>> _arr$ is a constant only because it is stored in the read only text
>>>>>>>> segment. This does not mean it is not a pointer , it stores an
>>>>>>>> offset
>>>>>>>> that points to the begining of the array.
>>>>>>>
>>>>>>> As I have already said '_arr$' does not exist as a distinct separate
>>>>>>> entity in the text segment; it used when emitting machine code in
>>>>>>> the
>>>>>>> text segment.
>>>>>>>
>>>>>>>> A pointer does not need to store a real address a pointer can also
>>>>>>>> store
>>>>>>>> an offset, as in this case.
>>>>>>>
>>>>>>> It is not a pointer; it is a constant used when emitting machine
>>>>>>> code.
>>>>>>
>>>>>> Oh you want to go to machine code level now?
>>>>>> There is no pointers in machine code at all, your argument is
>>>>>> nonsense.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Given my stack frame illustration _arr$ points to here:
>>>>>>>>
>>>>>>>> 00001C [-------------]
>>>>>>>> 000018 [--orig ebp---] <- ebp
>>>>>>>> 000014 [------0------]
>>>>>>>> 000010 [------7------]
>>>>>>>> 00000C [------0------] <- _arr$
>>>>>>>> 000008 [---00000C---] <- esp
>>>>>>>> 000004 [-------------]
>>>>>>>> 000000 [-------------]
>>>>>>>>
>>>>>>>> -12 is an offset into the stack frame, which is the location
>>>>>>>> where the
>>>>>>>> array begins.
>>>>>>>
>>>>>>> Finally. Yes -12 is an offset into the stack frame; we have been
>>>>>>> trying to tell you this for the past couple of days; -12 is not a
>>>>>>> pointer or a variable it is a constant offset. A realistic and
>>>>>>> correct
>>>>>>> stack frame illustration is:
>>>>>>>
>>>>>>> 123000 [-------------]
>>>>>>> 122FFC [--orig ebp---] <- ebp
>>>>>>> 123FF8 [------0------]
>>>>>>> 123FF4 [------7------]
>>>>>>> 123FF0 [------0------] <- ebp + _arr$
>>>>>>> 123FEC [---123FEC---] <- esp
>>>>>>> 123FE8 [-------------]
>>>>>>> 123FE4 [-------------]
>>>>>>>
>>>>>>> Notice how I have replaced your deliberately misleading value of 12
>>>>>>> (00000C) with a more realistic value that shows that the contents of
>>>>>>> the pointer 'px' is unrelated to the number 12; its value is ebp +
>>>>>>> _arr$ as encoded into the emitted machine code in the text segment.
>>>>>>>
>>>>>> There was no deliberate attempt to mislead, It was pure coincidence
>>>>>> that
>>>>>> the address turned out to be 12. You interpretation is wrong , the
>>>>>> value
>>>>>> of memory location 123FEC should be 123FF0.
>>>>>>
>>>>>
>>>>> Typical troll: deliberately ignoring my correction. On the small
>>>>> chance that you didn't use your newsreader properly yes I did put the
>>>>> wrong value in the illustration but that doesn't change the fact that
>>>>> what I said (and my "interpretation") is correct: '_arr$' is not a
>>>>> pointer it is a constant used when emitting machine code in the text
>>>>> segment.
>>>>>
>>>> So a simple task like changing the ficticional addresses is obviously
>>>> too complicated for you.
>>>
>>> Your original stack frame illustration also contained an error which
>>> you silently corrected so following your logic you are also unable to
>>> perform such a simple task.
>>>
>> My original illustration demonstrated knowledge of the code presented
>> and understanding of how the computer system works.
>> I didn't *silently* correct it, I corrected on small error that was a
>> text -> graphical asciiart mistake.
>> There is more complexity in what I did to interpret the code and convert
>> this into a stack ullustration than simply changing the ficticional
>> addresses.
>
> No it contained a major error (ebp pointing to the wrong thing) but meh
> who cares? You are the one who pounced on *my* minor error; an error
> which I publicly corrected; a correction you chose to ignore to try and
> score points due to your immaturity; immaturity which you have displayed
> numerous times in this newsgroup.
>
omg.
You changed the contents of the stack to something that was incorrect.
And I didn't pounce on it, I simply pointed out your error. You had not
posted a correction at the time I was replying so I didnt even see your
correction when I was posting.
Any immaturity is coming from your corner, accept your error and move on.
>>
>>>>
>>>> You don't even have a clue about machine code, this code is translated
>>>> into object code.
>>>> Machine code is post linking where all addresses and instructions are
>>>> reduced to binary.
>>>
>>> You are the one without a clue: an object file contains machine code
>>> along with relocation information and stack frame pointer offsets do
>>> not require relocation.
>>>
>> True an object file does contain machine code but this does not change
>> the fact that you are changing the goalpoasts to a lower level of code,
>> you will eventually get to the point where you are saying that a binary
>> file does not contain pointers therefore _arr$ is not a pointer.
>
> '_arr$' is not a pointer; it is a constant used when emitting machine code
> for the text segment; it is a transient artefact of the compilation
> process.
The constantness does not define whether or not its a pointer.
It's complete nonsense to say "its not a pointer its a constant"
Its a constant pointer therefore its both a constant and a pointer.
>
>>
>> If I change the C++ code to
>>
>> int arr[3]={0};
>> int main(){
>> arr[1] = 5;
>> }
>>
>> When you inspect the object file you will see that this array is not
>> optimised into a literal value at machine code level.
>
> What has this got to do with what we have been talking about? Here the
> array is of static storage duration so has a fixed address requiring
> relocation during linking.
>
>>
>> When I examine dumpbin arr is a symbol and its name is ?arr@@3PAHA (int
>> * arr)
>
> Of course arr has a symbolic name; what is your point? This has nothing
> to do with the possible existance of this mythical object of yours that
> contains the memory address of an array.
The point is that this "arr" object exists as a pointer to the array.
>
>>
>> Note that dumpbin displays this symbol with the addition info (int*
>> arr), this is compiled as a coff on a MS machine.
>
> Your basic problem (in addition to immaturity) is one of pride and of
> being unable to own up to your mistakes. You won't even apologize for
> your previous obnoxious insults.
>
You are the one dishing out the insults with every post you make , not me.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-27 22:15 +0100 |
| Message-ID | <UIOdnZ0SveH2iX3QnZ2dnUVZ8hmdnZ2d@giganews.com> |
| In reply to | #5732 |
On 27/05/2011 22:04, Paul wrote:
>
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:keGdnRLkX8-wlX3QnZ2dnUVZ8qadnZ2d@giganews.com...
>> On 27/05/2011 20:35, Paul wrote:
>>>
>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
>>> news:MtCdnb8XbZknXULQnZ2dnUVZ8k2dnZ2d@giganews.com...
>>>> On 27/05/2011 15:53, Paul wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Man you really don't have a clue, do you? I'll ask
>>>>>>>>>>>>>>>> again, How
>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>> x86
>>>>>>>>>>>>>>>> assembly programming have you actually done?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It doesn't matter how much I claim to have done or how much
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>> claim to
>>>>>>>>>>>>>>> have done. The fact of the matter is, apparently I know
>>>>>>>>>>>>>>> what a
>>>>>>>>>>>>>>> pointer
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> and you don't.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll take that as "none".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A variable whose value is an address(or an offset) to
>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>> memory
>>>>>>>>>>>>>>> location is a pointer in assembly language.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The *number* -20 isn't a variable any more than arr in
>>>>>>>>>>>>>> "#define
>>>>>>>>>>>>>> arr 20"
>>>>>>>>>>>>>> is.
>>>>>>>>>>>>> Correct -20 is not a variable , it is the value of the
>>>>>>>>>>>>> variable.
>>>>>>>>>>>>
>>>>>>>>>>>> It is the value of a constant. By your definition, if I write
>>>>>>>>>>>>
>>>>>>>>>>>> #define arr -20
>>>>>>>>>>>>
>>>>>>>>>>>> arr is a variable.
>>>>>>>>>>>>
>>>>>>>>>>>>>> _arr$ = -20 ; size = 20
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> is the MASM equivalent of
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #define arr = -20 // is arr a pointer?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is declared in the text segment, it is not an offset into
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> text
>>>>>>>>>>>>>> segment.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _arr$ is a variable that stores the value -20.
>>>>>>>>>>>>
>>>>>>>>>>>> No, for the last time it is a constant. Please study a topic
>>>>>>>>>>>> before
>>>>>>>>>>>> posting about it. From the link I posted earlier:
>>>>>>>>>>>>
>>>>>>>>>>>> "A manifest constant is a symbol name that represents some
>>>>>>>>>>>> fixed
>>>>>>>>>>>> quantity during the assembly process. That is it is a symbolic
>>>>>>>>>>>> name
>>>>>>>>>>>> that represents some value. Equates are the mechanism MASM
>>>>>>>>>>>> uses to
>>>>>>>>>>>> declare symbolic constants."
>>>>>>>>>>>>
>>>>>>>>>>>> This is now way off topic. I suggest you find an assembly
>>>>>>>>>>>> programming
>>>>>>>>>>>> group and see how far you get there.
>>>>>>>>>>>>
>>>>>>>>>>> Its you that brought it up. And now you seem to be ruinning away
>>>>>>>>>>> from
>>>>>>>>>>> the argument because you are maybe starting to realise that
>>>>>>>>>>> _arr$
>>>>>>>>>>> is a
>>>>>>>>>>> pointer.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Look at the following code:
>>>>>>>>>>>
>>>>>>>>>>> int main(){
>>>>>>>>>>> int arr[3]={0};
>>>>>>>>>>> int* px= arr;
>>>>>>>>>>> px[1] = 7;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> ; Listing generated by Microsoft (R) Optimizing Compiler Version
>>>>>>>>>>> 14.00.50727.762
>>>>>>>>>>>
>>>>>>>>>>> TITLE C:\cpp\public.cpp
>>>>>>>>>>> .686P
>>>>>>>>>>> .XMM
>>>>>>>>>>> include listing.inc
>>>>>>>>>>> .model flat
>>>>>>>>>>>
>>>>>>>>>>> INCLUDELIB LIBCMT
>>>>>>>>>>> INCLUDELIB OLDNAMES
>>>>>>>>>>>
>>>>>>>>>>> PUBLIC _main
>>>>>>>>>>> ; Function compile flags: /Odtp
>>>>>>>>>>> _TEXT SEGMENT
>>>>>>>>>>> _px$ = -16 ; size = 4
>>>>>>>>>>> _arr$ = -12 ; size = 12
>>>>>>>>>>> _main PROC
>>>>>>>>>>> ; File c:\cpp\public.cpp
>>>>>>>>>>> ; Line 5
>>>>>>>>>>> push ebp
>>>>>>>>>>> mov ebp, esp
>>>>>>>>>>> sub esp, 16 ; 00000010H
>>>>>>>>>>> ; Line 6
>>>>>>>>>>> mov DWORD PTR _arr$[ebp], 0
>>>>>>>>>>> xor eax, eax
>>>>>>>>>>> mov DWORD PTR _arr$[ebp+4], eax
>>>>>>>>>>> mov DWORD PTR _arr$[ebp+8], eax
>>>>>>>>>>> ; Line 7
>>>>>>>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>>>>>>> mov DWORD PTR _px$[ebp], ecx
>>>>>>>>>>> ; Line 8
>>>>>>>>>>> mov edx, DWORD PTR _px$[ebp]
>>>>>>>>>>> mov DWORD PTR [edx+4], 7
>>>>>>>>>>> ; Line 9
>>>>>>>>>>> xor eax, eax
>>>>>>>>>>> mov esp, ebp
>>>>>>>>>>> pop ebp
>>>>>>>>>>> ret 0
>>>>>>>>>>> _main ENDP
>>>>>>>>>>> _TEXT ENDS
>>>>>>>>>>> END
>>>>>>>>>>>
>>>>>>>>>>> Line 5-6 Creates a stack frame similar to below. It preserves
>>>>>>>>>>> ebp
>>>>>>>>>>> on the
>>>>>>>>>>> stack, then assgins the esp value to ebp and then decrements esp
>>>>>>>>>>> by 16
>>>>>>>>>>> bytes.
>>>>>>>>>>> Line 6-7 Initialises the 3 integer objects , of the array, to 0.
>>>>>>>>>>> Line 7-8 Stores the address of the first element at the location
>>>>>>>>>>> _px$
>>>>>>>>>>> points to.
>>>>>>>>>>> Line 8-9 Moves the literal value of 7 into the 2nd element of
>>>>>>>>>>> the
>>>>>>>>>>> array.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 00001C [-------------]
>>>>>>>>>>> 000018 [--orig ebp---]<- orig esp
>>>>>>>>>>> 000014 [------0------] <-ebp
>>>>>>>>>>> 000010 [------7------]
>>>>>>>>>>> 00000C [------0------]
>>>>>>>>>>> 000008 [---00000C---] <- esp
>>>>>>>>>>> 000004 [-------------]
>>>>>>>>>>> 000000 [-------------]
>>>>>>>>>>>
>>>>>>>>>>> After that ebp is popped and esp is back to its original value.
>>>>>>>>>>> Face the facts about what a pointer is in assembly programming.
>>>>>>>>>>> If you still do not accept these facts then I urge you to refer
>>>>>>>>>>> to the
>>>>>>>>>>> link I posted about pointer data types by Randy Hyde.
>>>>>>>>>>
>>>>>>>>>> Now you are arguing with yourself: you have just shown that
>>>>>>>>>> there is
>>>>>>>>>> no special hidden object which containing the address of the
>>>>>>>>>> array
>>>>>>>>>> object; the only thing that contains the address of the array
>>>>>>>>>> object
>>>>>>>>>> above is the pointer 'px'.
>>>>>>>>>>
>>>>>>>>> No there is a pointer named _arr$, which happens to be in the text
>>>>>>>>> segment, it is not on the stack.
>>>>>>>>
>>>>>>>> No, '_arr$' is not a pointer; '_arr$' is a constant used when
>>>>>>>> emitting
>>>>>>>> machine code in the text segment. If does not exist as a separate
>>>>>>>> entity in the text segment. lrn2asm.
>>>>>>>>
>>>>>>>>> Just the same as the pointer _px$ is not on the stack.
>>>>>>>>> Look at the value of _px$, it is -16, this doesn't mean it's not a
>>>>>>>>> pointer. Its just a pointer that stores an offset, or an index
>>>>>>>>> into
>>>>>>>>> the
>>>>>>>>> stack.
>>>>>>>>
>>>>>>>> The value of the pointer 'px' is stored on the stack at a location
>>>>>>>> stack frame pointer + '_px$' (a constant whose value is -16); we
>>>>>>>> have
>>>>>>>> already told you this.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> For:
>>>>>>>>>>
>>>>>>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>>>>>>
>>>>>>>>>> what will actually be emitted is:
>>>>>>>>>>
>>>>>>>>>> lea ecx, DWORD PTR [ebp-12]
>>>>>>>>>>
>>>>>>>>>> as '_arr$' is a constant; not a variable or a "pointer".
>>>>>>>>>
>>>>>>>>> _arr$ holds an offset which is added to ebp to create the real
>>>>>>>>> address.
>>>>>>>>
>>>>>>>> Correct we have already told you this.
>>>>>>>>
>>>>>>>>> _arr$ is a constant only because it is stored in the read only
>>>>>>>>> text
>>>>>>>>> segment. This does not mean it is not a pointer , it stores an
>>>>>>>>> offset
>>>>>>>>> that points to the begining of the array.
>>>>>>>>
>>>>>>>> As I have already said '_arr$' does not exist as a distinct
>>>>>>>> separate
>>>>>>>> entity in the text segment; it used when emitting machine code
>>>>>>>> in the
>>>>>>>> text segment.
>>>>>>>>
>>>>>>>>> A pointer does not need to store a real address a pointer can also
>>>>>>>>> store
>>>>>>>>> an offset, as in this case.
>>>>>>>>
>>>>>>>> It is not a pointer; it is a constant used when emitting machine
>>>>>>>> code.
>>>>>>>
>>>>>>> Oh you want to go to machine code level now?
>>>>>>> There is no pointers in machine code at all, your argument is
>>>>>>> nonsense.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Given my stack frame illustration _arr$ points to here:
>>>>>>>>>
>>>>>>>>> 00001C [-------------]
>>>>>>>>> 000018 [--orig ebp---] <- ebp
>>>>>>>>> 000014 [------0------]
>>>>>>>>> 000010 [------7------]
>>>>>>>>> 00000C [------0------] <- _arr$
>>>>>>>>> 000008 [---00000C---] <- esp
>>>>>>>>> 000004 [-------------]
>>>>>>>>> 000000 [-------------]
>>>>>>>>>
>>>>>>>>> -12 is an offset into the stack frame, which is the location
>>>>>>>>> where the
>>>>>>>>> array begins.
>>>>>>>>
>>>>>>>> Finally. Yes -12 is an offset into the stack frame; we have been
>>>>>>>> trying to tell you this for the past couple of days; -12 is not a
>>>>>>>> pointer or a variable it is a constant offset. A realistic and
>>>>>>>> correct
>>>>>>>> stack frame illustration is:
>>>>>>>>
>>>>>>>> 123000 [-------------]
>>>>>>>> 122FFC [--orig ebp---] <- ebp
>>>>>>>> 123FF8 [------0------]
>>>>>>>> 123FF4 [------7------]
>>>>>>>> 123FF0 [------0------] <- ebp + _arr$
>>>>>>>> 123FEC [---123FEC---] <- esp
>>>>>>>> 123FE8 [-------------]
>>>>>>>> 123FE4 [-------------]
>>>>>>>>
>>>>>>>> Notice how I have replaced your deliberately misleading value of 12
>>>>>>>> (00000C) with a more realistic value that shows that the
>>>>>>>> contents of
>>>>>>>> the pointer 'px' is unrelated to the number 12; its value is ebp +
>>>>>>>> _arr$ as encoded into the emitted machine code in the text segment.
>>>>>>>>
>>>>>>> There was no deliberate attempt to mislead, It was pure coincidence
>>>>>>> that
>>>>>>> the address turned out to be 12. You interpretation is wrong , the
>>>>>>> value
>>>>>>> of memory location 123FEC should be 123FF0.
>>>>>>>
>>>>>>
>>>>>> Typical troll: deliberately ignoring my correction. On the small
>>>>>> chance that you didn't use your newsreader properly yes I did put the
>>>>>> wrong value in the illustration but that doesn't change the fact that
>>>>>> what I said (and my "interpretation") is correct: '_arr$' is not a
>>>>>> pointer it is a constant used when emitting machine code in the text
>>>>>> segment.
>>>>>>
>>>>> So a simple task like changing the ficticional addresses is obviously
>>>>> too complicated for you.
>>>>
>>>> Your original stack frame illustration also contained an error which
>>>> you silently corrected so following your logic you are also unable to
>>>> perform such a simple task.
>>>>
>>> My original illustration demonstrated knowledge of the code presented
>>> and understanding of how the computer system works.
>>> I didn't *silently* correct it, I corrected on small error that was a
>>> text -> graphical asciiart mistake.
>>> There is more complexity in what I did to interpret the code and convert
>>> this into a stack ullustration than simply changing the ficticional
>>> addresses.
>>
>> No it contained a major error (ebp pointing to the wrong thing) but
>> meh who cares? You are the one who pounced on *my* minor error; an
>> error which I publicly corrected; a correction you chose to ignore to
>> try and score points due to your immaturity; immaturity which you have
>> displayed numerous times in this newsgroup.
>>
> omg.
> You changed the contents of the stack to something that was incorrect.
> And I didn't pounce on it, I simply pointed out your error. You had not
> posted a correction at the time I was replying so I didnt even see your
> correction when I was posting.
> Any immaturity is coming from your corner, accept your error and move on.
Accept my error? I publicly posted a correction; you silently fixed
your error with no acknowledgement. Move on? Certainly as it is trivial.
>
>>>
>>>>>
>>>>> You don't even have a clue about machine code, this code is translated
>>>>> into object code.
>>>>> Machine code is post linking where all addresses and instructions are
>>>>> reduced to binary.
>>>>
>>>> You are the one without a clue: an object file contains machine code
>>>> along with relocation information and stack frame pointer offsets do
>>>> not require relocation.
>>>>
>>> True an object file does contain machine code but this does not change
>>> the fact that you are changing the goalpoasts to a lower level of code,
>>> you will eventually get to the point where you are saying that a binary
>>> file does not contain pointers therefore _arr$ is not a pointer.
>>
>> '_arr$' is not a pointer; it is a constant used when emitting machine
>> code for the text segment; it is a transient artefact of the
>> compilation process.
>
> The constantness does not define whether or not its a pointer.
> It's complete nonsense to say "its not a pointer its a constant"
> Its a constant pointer therefore its both a constant and a pointer.
It is an integer constant representing an offset to be applied to a
stack frame pointer; it is NOT a pointer for any definition of
"pointer"; it is like saying 'foo' below is a C++ pointer because we add
it to a C++ pointer:
const std::size_t foo = 42;
int *p = ...;
int *p2 = p + foo; // is foo a pointer? don't be stupid.
>>
>>>
>>> If I change the C++ code to
>>>
>>> int arr[3]={0};
>>> int main(){
>>> arr[1] = 5;
>>> }
>>>
>>> When you inspect the object file you will see that this array is not
>>> optimised into a literal value at machine code level.
>>
>> What has this got to do with what we have been talking about? Here the
>> array is of static storage duration so has a fixed address requiring
>> relocation during linking.
>>
>>>
>>> When I examine dumpbin arr is a symbol and its name is ?arr@@3PAHA (int
>>> * arr)
>>
>> Of course arr has a symbolic name; what is your point? This has
>> nothing to do with the possible existance of this mythical object of
>> yours that contains the memory address of an array.
>
> The point is that this "arr" object exists as a pointer to the array.
Wrong yet again. After linking there is nothing that can be construed
as being a pointer to the array for any definition of "pointer". After
linking and relocation any references to 'arr' will be directly replaced
with the address of the array, no pointers.
>
>>
>>>
>>> Note that dumpbin displays this symbol with the addition info (int*
>>> arr), this is compiled as a coff on a MS machine.
>>
>> Your basic problem (in addition to immaturity) is one of pride and of
>> being unable to own up to your mistakes. You won't even apologize for
>> your previous obnoxious insults.
>>
> You are the one dishing out the insults with every post you make , not me.
One only has to look at your previous posts to this newsgroup to see who
has been dishing out the insults.
/Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 00:40 +0100 |
| Message-ID | <7EWDp.21826$m_1.16265@newsfe22.ams2> |
| In reply to | #5734 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:UIOdnZ0SveH2iX3QnZ2dnUVZ8hmdnZ2d@giganews.com...
> On 27/05/2011 22:04, Paul wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Man you really don't have a clue, do you? I'll ask
>>>>>>>>>>>>>>>>> again, How
>>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>> x86
>>>>>>>>>>>>>>>>> assembly programming have you actually done?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It doesn't matter how much I claim to have done or how much
>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>> claim to
>>>>>>>>>>>>>>>> have done. The fact of the matter is, apparently I know
>>>>>>>>>>>>>>>> what a
>>>>>>>>>>>>>>>> pointer
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> and you don't.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll take that as "none".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A variable whose value is an address(or an offset) to
>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>> memory
>>>>>>>>>>>>>>>> location is a pointer in assembly language.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The *number* -20 isn't a variable any more than arr in
>>>>>>>>>>>>>>> "#define
>>>>>>>>>>>>>>> arr 20"
>>>>>>>>>>>>>>> is.
>>>>>>>>>>>>>> Correct -20 is not a variable , it is the value of the
>>>>>>>>>>>>>> variable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is the value of a constant. By your definition, if I write
>>>>>>>>>>>>>
>>>>>>>>>>>>> #define arr -20
>>>>>>>>>>>>>
>>>>>>>>>>>>> arr is a variable.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _arr$ = -20 ; size = 20
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is the MASM equivalent of
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> #define arr = -20 // is arr a pointer?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is declared in the text segment, it is not an offset into
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> text
>>>>>>>>>>>>>>> segment.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _arr$ is a variable that stores the value -20.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, for the last time it is a constant. Please study a topic
>>>>>>>>>>>>> before
>>>>>>>>>>>>> posting about it. From the link I posted earlier:
>>>>>>>>>>>>>
>>>>>>>>>>>>> "A manifest constant is a symbol name that represents some
>>>>>>>>>>>>> fixed
>>>>>>>>>>>>> quantity during the assembly process. That is it is a symbolic
>>>>>>>>>>>>> name
>>>>>>>>>>>>> that represents some value. Equates are the mechanism MASM
>>>>>>>>>>>>> uses to
>>>>>>>>>>>>> declare symbolic constants."
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is now way off topic. I suggest you find an assembly
>>>>>>>>>>>>> programming
>>>>>>>>>>>>> group and see how far you get there.
>>>>>>>>>>>>>
>>>>>>>>>>>> Its you that brought it up. And now you seem to be ruinning
>>>>>>>>>>>> away
>>>>>>>>>>>> from
>>>>>>>>>>>> the argument because you are maybe starting to realise that
>>>>>>>>>>>> _arr$
>>>>>>>>>>>> is a
>>>>>>>>>>>> pointer.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Look at the following code:
>>>>>>>>>>>>
>>>>>>>>>>>> int main(){
>>>>>>>>>>>> int arr[3]={0};
>>>>>>>>>>>> int* px= arr;
>>>>>>>>>>>> px[1] = 7;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> ; Listing generated by Microsoft (R) Optimizing Compiler
>>>>>>>>>>>> Version
>>>>>>>>>>>> 14.00.50727.762
>>>>>>>>>>>>
>>>>>>>>>>>> TITLE C:\cpp\public.cpp
>>>>>>>>>>>> .686P
>>>>>>>>>>>> .XMM
>>>>>>>>>>>> include listing.inc
>>>>>>>>>>>> .model flat
>>>>>>>>>>>>
>>>>>>>>>>>> INCLUDELIB LIBCMT
>>>>>>>>>>>> INCLUDELIB OLDNAMES
>>>>>>>>>>>>
>>>>>>>>>>>> PUBLIC _main
>>>>>>>>>>>> ; Function compile flags: /Odtp
>>>>>>>>>>>> _TEXT SEGMENT
>>>>>>>>>>>> _px$ = -16 ; size = 4
>>>>>>>>>>>> _arr$ = -12 ; size = 12
>>>>>>>>>>>> _main PROC
>>>>>>>>>>>> ; File c:\cpp\public.cpp
>>>>>>>>>>>> ; Line 5
>>>>>>>>>>>> push ebp
>>>>>>>>>>>> mov ebp, esp
>>>>>>>>>>>> sub esp, 16 ; 00000010H
>>>>>>>>>>>> ; Line 6
>>>>>>>>>>>> mov DWORD PTR _arr$[ebp], 0
>>>>>>>>>>>> xor eax, eax
>>>>>>>>>>>> mov DWORD PTR _arr$[ebp+4], eax
>>>>>>>>>>>> mov DWORD PTR _arr$[ebp+8], eax
>>>>>>>>>>>> ; Line 7
>>>>>>>>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>>>>>>>> mov DWORD PTR _px$[ebp], ecx
>>>>>>>>>>>> ; Line 8
>>>>>>>>>>>> mov edx, DWORD PTR _px$[ebp]
>>>>>>>>>>>> mov DWORD PTR [edx+4], 7
>>>>>>>>>>>> ; Line 9
>>>>>>>>>>>> xor eax, eax
>>>>>>>>>>>> mov esp, ebp
>>>>>>>>>>>> pop ebp
>>>>>>>>>>>> ret 0
>>>>>>>>>>>> _main ENDP
>>>>>>>>>>>> _TEXT ENDS
>>>>>>>>>>>> END
>>>>>>>>>>>>
>>>>>>>>>>>> Line 5-6 Creates a stack frame similar to below. It preserves
>>>>>>>>>>>> ebp
>>>>>>>>>>>> on the
>>>>>>>>>>>> stack, then assgins the esp value to ebp and then decrements
>>>>>>>>>>>> esp
>>>>>>>>>>>> by 16
>>>>>>>>>>>> bytes.
>>>>>>>>>>>> Line 6-7 Initialises the 3 integer objects , of the array, to
>>>>>>>>>>>> 0.
>>>>>>>>>>>> Line 7-8 Stores the address of the first element at the
>>>>>>>>>>>> location
>>>>>>>>>>>> _px$
>>>>>>>>>>>> points to.
>>>>>>>>>>>> Line 8-9 Moves the literal value of 7 into the 2nd element of
>>>>>>>>>>>> the
>>>>>>>>>>>> array.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 00001C [-------------]
>>>>>>>>>>>> 000018 [--orig ebp---]<- orig esp
>>>>>>>>>>>> 000014 [------0------] <-ebp
>>>>>>>>>>>> 000010 [------7------]
>>>>>>>>>>>> 00000C [------0------]
>>>>>>>>>>>> 000008 [---00000C---] <- esp
>>>>>>>>>>>> 000004 [-------------]
>>>>>>>>>>>> 000000 [-------------]
>>>>>>>>>>>>
>>>>>>>>>>>> After that ebp is popped and esp is back to its original value.
>>>>>>>>>>>> Face the facts about what a pointer is in assembly programming.
>>>>>>>>>>>> If you still do not accept these facts then I urge you to refer
>>>>>>>>>>>> to the
>>>>>>>>>>>> link I posted about pointer data types by Randy Hyde.
>>>>>>>>>>>
>>>>>>>>>>> Now you are arguing with yourself: you have just shown that
>>>>>>>>>>> there is
>>>>>>>>>>> no special hidden object which containing the address of the
>>>>>>>>>>> array
>>>>>>>>>>> object; the only thing that contains the address of the array
>>>>>>>>>>> object
>>>>>>>>>>> above is the pointer 'px'.
>>>>>>>>>>>
>>>>>>>>>> No there is a pointer named _arr$, which happens to be in the
>>>>>>>>>> text
>>>>>>>>>> segment, it is not on the stack.
>>>>>>>>>
>>>>>>>>> No, '_arr$' is not a pointer; '_arr$' is a constant used when
>>>>>>>>> emitting
>>>>>>>>> machine code in the text segment. If does not exist as a separate
>>>>>>>>> entity in the text segment. lrn2asm.
>>>>>>>>>
>>>>>>>>>> Just the same as the pointer _px$ is not on the stack.
>>>>>>>>>> Look at the value of _px$, it is -16, this doesn't mean it's not
>>>>>>>>>> a
>>>>>>>>>> pointer. Its just a pointer that stores an offset, or an index
>>>>>>>>>> into
>>>>>>>>>> the
>>>>>>>>>> stack.
>>>>>>>>>
>>>>>>>>> The value of the pointer 'px' is stored on the stack at a location
>>>>>>>>> stack frame pointer + '_px$' (a constant whose value is -16); we
>>>>>>>>> have
>>>>>>>>> already told you this.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> For:
>>>>>>>>>>>
>>>>>>>>>>> lea ecx, DWORD PTR _arr$[ebp]
>>>>>>>>>>>
>>>>>>>>>>> what will actually be emitted is:
>>>>>>>>>>>
>>>>>>>>>>> lea ecx, DWORD PTR [ebp-12]
>>>>>>>>>>>
>>>>>>>>>>> as '_arr$' is a constant; not a variable or a "pointer".
>>>>>>>>>>
>>>>>>>>>> _arr$ holds an offset which is added to ebp to create the real
>>>>>>>>>> address.
>>>>>>>>>
>>>>>>>>> Correct we have already told you this.
>>>>>>>>>
>>>>>>>>>> _arr$ is a constant only because it is stored in the read only
>>>>>>>>>> text
>>>>>>>>>> segment. This does not mean it is not a pointer , it stores an
>>>>>>>>>> offset
>>>>>>>>>> that points to the begining of the array.
>>>>>>>>>
>>>>>>>>> As I have already said '_arr$' does not exist as a distinct
>>>>>>>>> separate
>>>>>>>>> entity in the text segment; it used when emitting machine code
>>>>>>>>> in the
>>>>>>>>> text segment.
>>>>>>>>>
>>>>>>>>>> A pointer does not need to store a real address a pointer can
>>>>>>>>>> also
>>>>>>>>>> store
>>>>>>>>>> an offset, as in this case.
>>>>>>>>>
>>>>>>>>> It is not a pointer; it is a constant used when emitting machine
>>>>>>>>> code.
>>>>>>>>
>>>>>>>> Oh you want to go to machine code level now?
>>>>>>>> There is no pointers in machine code at all, your argument is
>>>>>>>> nonsense.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Given my stack frame illustration _arr$ points to here:
>>>>>>>>>>
>>>>>>>>>> 00001C [-------------]
>>>>>>>>>> 000018 [--orig ebp---] <- ebp
>>>>>>>>>> 000014 [------0------]
>>>>>>>>>> 000010 [------7------]
>>>>>>>>>> 00000C [------0------] <- _arr$
>>>>>>>>>> 000008 [---00000C---] <- esp
>>>>>>>>>> 000004 [-------------]
>>>>>>>>>> 000000 [-------------]
>>>>>>>>>>
>>>>>>>>>> -12 is an offset into the stack frame, which is the location
>>>>>>>>>> where the
>>>>>>>>>> array begins.
>>>>>>>>>
>>>>>>>>> Finally. Yes -12 is an offset into the stack frame; we have been
>>>>>>>>> trying to tell you this for the past couple of days; -12 is not a
>>>>>>>>> pointer or a variable it is a constant offset. A realistic and
>>>>>>>>> correct
>>>>>>>>> stack frame illustration is:
>>>>>>>>>
>>>>>>>>> 123000 [-------------]
>>>>>>>>> 122FFC [--orig ebp---] <- ebp
>>>>>>>>> 123FF8 [------0------]
>>>>>>>>> 123FF4 [------7------]
>>>>>>>>> 123FF0 [------0------] <- ebp + _arr$
>>>>>>>>> 123FEC [---123FEC---] <- esp
>>>>>>>>> 123FE8 [-------------]
>>>>>>>>> 123FE4 [-------------]
>>>>>>>>>
>>>>>>>>> Notice how I have replaced your deliberately misleading value of
>>>>>>>>> 12
>>>>>>>>> (00000C) with a more realistic value that shows that the
>>>>>>>>> contents of
>>>>>>>>> the pointer 'px' is unrelated to the number 12; its value is ebp +
>>>>>>>>> _arr$ as encoded into the emitted machine code in the text
>>>>>>>>> segment.
>>>>>>>>>
>>>>>>>> There was no deliberate attempt to mislead, It was pure coincidence
>>>>>>>> that
>>>>>>>> the address turned out to be 12. You interpretation is wrong , the
>>>>>>>> value
>>>>>>>> of memory location 123FEC should be 123FF0.
>>>>>>>>
>>>>>>>
>>>>>>> Typical troll: deliberately ignoring my correction. On the small
>>>>>>> chance that you didn't use your newsreader properly yes I did put
>>>>>>> the
>>>>>>> wrong value in the illustration but that doesn't change the fact
>>>>>>> that
>>>>>>> what I said (and my "interpretation") is correct: '_arr$' is not a
>>>>>>> pointer it is a constant used when emitting machine code in the text
>>>>>>> segment.
>>>>>>>
>>>>>> So a simple task like changing the ficticional addresses is obviously
>>>>>> too complicated for you.
>>>>>
>>>>> Your original stack frame illustration also contained an error which
>>>>> you silently corrected so following your logic you are also unable to
>>>>> perform such a simple task.
>>>>>
>>>> My original illustration demonstrated knowledge of the code presented
>>>> and understanding of how the computer system works.
>>>> I didn't *silently* correct it, I corrected on small error that was a
>>>> text -> graphical asciiart mistake.
>>>> There is more complexity in what I did to interpret the code and
>>>> convert
>>>> this into a stack ullustration than simply changing the ficticional
>>>> addresses.
>>>
>>> No it contained a major error (ebp pointing to the wrong thing) but
>>> meh who cares? You are the one who pounced on *my* minor error; an
>>> error which I publicly corrected; a correction you chose to ignore to
>>> try and score points due to your immaturity; immaturity which you have
>>> displayed numerous times in this newsgroup.
>>>
>> omg.
>> You changed the contents of the stack to something that was incorrect.
>> And I didn't pounce on it, I simply pointed out your error. You had not
>> posted a correction at the time I was replying so I didnt even see your
>> correction when I was posting.
>> Any immaturity is coming from your corner, accept your error and move on.
>
> Accept my error? I publicly posted a correction; you silently fixed your
> error with no acknowledgement. Move on? Certainly as it is trivial.
>
>>
>>>>
>>>>>>
>>>>>> You don't even have a clue about machine code, this code is
>>>>>> translated
>>>>>> into object code.
>>>>>> Machine code is post linking where all addresses and instructions are
>>>>>> reduced to binary.
>>>>>
>>>>> You are the one without a clue: an object file contains machine code
>>>>> along with relocation information and stack frame pointer offsets do
>>>>> not require relocation.
>>>>>
>>>> True an object file does contain machine code but this does not change
>>>> the fact that you are changing the goalpoasts to a lower level of code,
>>>> you will eventually get to the point where you are saying that a binary
>>>> file does not contain pointers therefore _arr$ is not a pointer.
>>>
>>> '_arr$' is not a pointer; it is a constant used when emitting machine
>>> code for the text segment; it is a transient artefact of the
>>> compilation process.
>>
>> The constantness does not define whether or not its a pointer.
>> It's complete nonsense to say "its not a pointer its a constant"
>> Its a constant pointer therefore its both a constant and a pointer.
>
> It is an integer constant representing an offset to be applied to a stack
> frame pointer; it is NOT a pointer for any definition of "pointer"; it is
> like saying 'foo' below is a C++ pointer because we add it to a C++
> pointer:
>
> const std::size_t foo = 42;
> int *p = ...;
> int *p2 = p + foo; // is foo a pointer? don't be stupid.
>
No incorrect , you said it was not a pointer in assembly language.
Ovbioustly its not a C++ pointer, its an array type object.
In C++ we say something is a T becaus eit has a type T, for example:
int x; //x is an integer because of its type.
int* p; //p is a pointer because of its type
etc etc
In assembly there are no types and a variable or constant is simply data,
its purpose defines what it is.
If its purpose is to to store another memory location, or an offset to such,
then it is a pointer.
>>>
>>>>
>>>> If I change the C++ code to
>>>>
>>>> int arr[3]={0};
>>>> int main(){
>>>> arr[1] = 5;
>>>> }
>>>>
>>>> When you inspect the object file you will see that this array is not
>>>> optimised into a literal value at machine code level.
>>>
>>> What has this got to do with what we have been talking about? Here the
>>> array is of static storage duration so has a fixed address requiring
>>> relocation during linking.
>>>
>>>>
>>>> When I examine dumpbin arr is a symbol and its name is ?arr@@3PAHA (int
>>>> * arr)
>>>
>>> Of course arr has a symbolic name; what is your point? This has
>>> nothing to do with the possible existance of this mythical object of
>>> yours that contains the memory address of an array.
>>
>> The point is that this "arr" object exists as a pointer to the array.
>
> Wrong yet again. After linking there is nothing that can be construed as
> being a pointer to the array for any definition of "pointer". After
> linking and relocation any references to 'arr' will be directly replaced
> with the address of the array, no pointers.
I'm talking about object code, not after linking.
So you are wrong because you are talking about the wrong thing altogether.
>
>>
>>>
>>>>
>>>> Note that dumpbin displays this symbol with the addition info (int*
>>>> arr), this is compiled as a coff on a MS machine.
>>>
>>> Your basic problem (in addition to immaturity) is one of pride and of
>>> being unable to own up to your mistakes. You won't even apologize for
>>> your previous obnoxious insults.
>>>
>> You are the one dishing out the insults with every post you make , not
>> me.
>
> One only has to look at your previous posts to this newsgroup to see who
> has been dishing out the insults.
>
I only insult back , my insults are justified.
You just start insulting anyone who disagrees with you.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-28 00:53 +0100 |
| Message-ID | <oJudnW32uqDwpH3QnZ2dnUVZ8hCdnZ2d@giganews.com> |
| In reply to | #5741 |
On 28/05/2011 00:40, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:UIOdnZ0SveH2iX3QnZ2dnUVZ8hmdnZ2d@giganews.com... [snip] >> It is an integer constant representing an offset to be applied to a >> stack frame pointer; it is NOT a pointer for any definition of >> "pointer"; it is like saying 'foo' below is a C++ pointer because we >> add it to a C++ pointer: >> >> const std::size_t foo = 42; >> int *p = ...; >> int *p2 = p + foo; // is foo a pointer? don't be stupid. >> > No incorrect , you said it was not a pointer in assembly language. > Ovbioustly its not a C++ pointer, its an array type object. Do you not understand the meaning of the words "it is like"? Do you know what an "analogy" is? Have you ever bothered to try "lateral thinking"? I never said it was a C++ pointer; I was giving you a C++ analogy of why a pointer offset (for any definition of "pointer") is not a pointer. [nonsense snipped] HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 01:32 +0100 |
| Message-ID | <woXDp.9672$El6.3210@newsfe21.ams2> |
| In reply to | #5742 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:oJudnW32uqDwpH3QnZ2dnUVZ8hCdnZ2d@giganews.com... > On 28/05/2011 00:40, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:UIOdnZ0SveH2iX3QnZ2dnUVZ8hmdnZ2d@giganews.com... > > [snip] > >>> It is an integer constant representing an offset to be applied to a >>> stack frame pointer; it is NOT a pointer for any definition of >>> "pointer"; it is like saying 'foo' below is a C++ pointer because we >>> add it to a C++ pointer: >>> >>> const std::size_t foo = 42; >>> int *p = ...; >>> int *p2 = p + foo; // is foo a pointer? don't be stupid. >>> >> No incorrect , you said it was not a pointer in assembly language. >> Ovbioustly its not a C++ pointer, its an array type object. > > Do you not understand the meaning of the words "it is like"? Do you know > what an "analogy" is? Have you ever bothered to try "lateral thinking"? > > I never said it was a C++ pointer; I was giving you a C++ analogy of why a > pointer offset (for any definition of "pointer") is not a pointer. > But a pointer in assembly is not the same as a pointer in C++. A pointer in C++ is a pointer type object, or an object of pointer type. Assembly does not have types, a pointer in assembly is the same as any other variable or constant, except that its intended use is to store an address(or an offset) to another memory location.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-28 01:49 +0100 |
| Message-ID | <8YadndAUkrEr233QnZ2dnUVZ8uKdnZ2d@giganews.com> |
| In reply to | #5745 |
On 28/05/2011 01:32, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:oJudnW32uqDwpH3QnZ2dnUVZ8hCdnZ2d@giganews.com... >> On 28/05/2011 00:40, Paul wrote: >>> >>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>> news:UIOdnZ0SveH2iX3QnZ2dnUVZ8hmdnZ2d@giganews.com... >> >> [snip] >> >>>> It is an integer constant representing an offset to be applied to a >>>> stack frame pointer; it is NOT a pointer for any definition of >>>> "pointer"; it is like saying 'foo' below is a C++ pointer because we >>>> add it to a C++ pointer: >>>> >>>> const std::size_t foo = 42; >>>> int *p = ...; >>>> int *p2 = p + foo; // is foo a pointer? don't be stupid. >>>> >>> No incorrect , you said it was not a pointer in assembly language. >>> Ovbioustly its not a C++ pointer, its an array type object. >> >> Do you not understand the meaning of the words "it is like"? Do you >> know what an "analogy" is? Have you ever bothered to try "lateral >> thinking"? >> >> I never said it was a C++ pointer; I was giving you a C++ analogy of >> why a pointer offset (for any definition of "pointer") is not a pointer. >> > But a pointer in assembly is not the same as a pointer in C++. A pointer > in C++ is a pointer type object, or an object of pointer type. > Assembly does not have types, a pointer in assembly is the same as any > other variable or constant, except that its intended use is to store an > address(or an offset) to another memory location. I gave you an analogy; you obviously do not understand analogies. An analogy explains one thing by comparing it to something else and these two things are *similar* in some respect not the *same*. Get a clue. A pointer in assembly is anything that is being used to store an address and a constant being used as a stack frame pointer offset is not something which is being used to store an address; such a constant is only being used to emit machine code in the text segment. lrn2asm. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-28 13:17 +1200 |
| Message-ID | <94b0pmFr1qU1@mid.individual.net> |
| In reply to | #5747 |
On 05/28/11 12:49 PM, Leigh Johnston wrote: > > A pointer in assembly is anything that is being used to store an address > and a constant being used as a stack frame pointer offset is not > something which is being used to store an address; such a constant is > only being used to emit machine code in the text segment. Be careful Leigh, you may have noticed that my delusion as to what is and isn't a pointer in assembly has been shattered by our good friend Paul. It's really troubling to realise I have to go back and review over 30 years of assembly listings and check all the places I thought I was returning pointers and updated them to use -20. Should I notify my past clients? Will the avionics applications using my custom x86 allocator stop working now this delusion has been shattered? Will reality ever be the same again? These are troubled times. Thank goodness someone had the insight to realise -20 is the true meaning of a pointer. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 03:29 +0100 |
| Message-ID | <36ZDp.7023$Tw4.2271@newsfe26.ams2> |
| In reply to | #5748 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:94b0pmFr1qU1@mid.individual.net... > On 05/28/11 12:49 PM, Leigh Johnston wrote: >> >> A pointer in assembly is anything that is being used to store an address >> and a constant being used as a stack frame pointer offset is not >> something which is being used to store an address; such a constant is >> only being used to emit machine code in the text segment. > > Be careful Leigh, you may have noticed that my delusion as to what is and > isn't a pointer in assembly has been shattered by our good friend Paul. > It's really troubling to realise I have to go back and review over 30 > years of assembly listings and check all the places I thought I was > returning pointers and updated them to use -20. > > Should I notify my past clients? Will the avionics applications using my > custom x86 allocator stop working now this delusion has been shattered? > Will reality ever be the same again? > > These are troubled times. Thank goodness someone had the insight to > realise -20 is the true meaning of a pointer. > > -- You are very quick to dismiss my opinion of what a pointer is in assembly as incorrect but what exactly is your opinion of what a pointer is? What is a pointer in assembly, in your opinion? I put this question to both you and Leigh.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-28 15:35 +1200 |
| Message-ID | <94b8rkFr1qU2@mid.individual.net> |
| In reply to | #5751 |
On 05/28/11 02:29 PM, Paul wrote: > > You are very quick to dismiss my opinion of what a pointer is in assembly as > incorrect but what exactly is your opinion of what a pointer is? I was equally quick to dismiss the prediction that the world would end last weekend. A pointer in x86 assembly is simply a memory location or register that contains the address of another memory location. That's is not my opinion, it is what it is. The pointers in your example are esp (the stack pointer) and ebp (the base pointer). The instruction mov DWORD PTR _arr$[ebp], 0 given the definition of the constant _arr$ _arr$ = -12 ; size = 12 writes zero the the memory location who's address is ebp-12. Here ebp is the pointer and -12 is the offset. The next assignment which is a bit messy in MASM, mov DWORD PTR _arr$[ebp+4], eax writes zero the the memory location who's address is ebp-12+4. The GNU assemble output is somewhat clearer: movl $0, -12(%ebp) movl $0, -8(%ebp) The pointer+offset relation is the same is in C or C++ when we write int* p = arr; *(p+1) = 0; The '1' above is no more a pointer than the -12 in the assembly. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 12:24 +0100 |
| Message-ID | <vY4Ep.27665$yI6.15519@newsfe06.ams2> |
| In reply to | #5752 |
"Ian Collins" <ian-news@hotmail.com> wrote in message
news:94b8rkFr1qU2@mid.individual.net...
> On 05/28/11 02:29 PM, Paul wrote:
>>
>> You are very quick to dismiss my opinion of what a pointer is in assembly
>> as
>> incorrect but what exactly is your opinion of what a pointer is?
>
> I was equally quick to dismiss the prediction that the world would end
> last weekend.
>
> A pointer in x86 assembly is simply a memory location or register that
> contains the address of another memory location. That's is not my
> opinion, it is what it is.
No that is your opinion.
Other people have different opinions and I happen to be one of those people.
I have already posted a link to Randal Hydes Art of Assembly that describes
what a pointer is, and RH defines that a pointer can be a simple offset.
Here is another link that shows some other peoples opinions:
http://stackoverflow.com/questions/5055619/pointers-seen-on-assembly-or-registries
>
> The pointers in your example are esp (the stack pointer) and ebp (the base
> pointer).
These are hardware registers.
>
> The instruction
>
> mov DWORD PTR _arr$[ebp], 0
>
> given the definition of the constant _arr$
>
> _arr$ = -12 ; size = 12
>
> writes zero the the memory location who's address is ebp-12. Here ebp is
> the pointer and -12 is the offset.
_arr$ is a label that equates to the value of (-12) .
Here the label _arr$ is used as a pointer,
>
> The next assignment which is a bit messy in MASM,
>
> mov DWORD PTR _arr$[ebp+4], eax
>
> writes zero the the memory location who's address is ebp-12+4.
This confirms that _arr$ is an offset, which is used to create a memory
address. Therefore it's a pointer.
>
> The GNU assemble output is somewhat clearer:
>
> movl $0, -12(%ebp)
> movl $0, -8(%ebp)
>
> The pointer+offset relation is the same is in C or C++ when we write
>
> int* p = arr;
> *(p+1) = 0;
>
> The '1' above is no more a pointer than the -12 in the assembly.
>
> --
Why are you trying to comapre a C++ pointer to that of an asm pointer?
The concept of a pointer in C++ does not exist in asm, in C++ a pointer is
an object with a pointer type.
Given the C++ code :
int x=0;
int main(){
int* p1= &x;
}
The following asm is produced.:
INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES
PUBLIC ?x@@3HA ; x
_BSS SEGMENT
?x@@3HA DD 01H DUP (?) ; x
_BSS ENDS
PUBLIC _main
; Function compile flags: /Odtp
_TEXT SEGMENT
_p1$ = -4 ; size = 4
/******************************/
The line above shows that p1 is created in asm as simply a label whos value
is an offset.
/*****************************/
_main PROC
; File c:\cpp\public.cpp
; Line 6
push ebp
mov ebp, esp
push ecx
; Line 7
mov DWORD PTR _p1$[ebp], OFFSET ?x@@3HA ; x
; Line 8
xor eax, eax
mov esp, ebp
pop ebp
ret 0
_main ENDP
_TEXT ENDS
END
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-29 08:21 +1200 |
| Message-ID | <94d3qqFr1qU5@mid.individual.net> |
| In reply to | #5759 |
On 05/28/11 11:24 PM, Paul wrote: > > "Ian Collins"<ian-news@hotmail.com> wrote in message > news:94b8rkFr1qU2@mid.individual.net... >> On 05/28/11 02:29 PM, Paul wrote: >>> >>> You are very quick to dismiss my opinion of what a pointer is in assembly >>> as >>> incorrect but what exactly is your opinion of what a pointer is? >> >> I was equally quick to dismiss the prediction that the world would end >> last weekend. >> >> A pointer in x86 assembly is simply a memory location or register that >> contains the address of another memory location. That's is not my >> opinion, it is what it is. > > No that is your opinion. > Other people have different opinions and I happen to be one of those people. I value the opinions of other professionals I have worked wit or known. So tell me, how many x86 assembly projects have you worked on? > I have already posted a link to Randal Hydes Art of Assembly that describes > what a pointer is, and RH defines that a pointer can be a simple offset. No, it does not. As usual you have chosen to misinterpret the link you have posted. > Here is another link that shows some other peoples opinions: > http://stackoverflow.com/questions/5055619/pointers-seen-on-assembly-or-registries So these are trusted sources? If so answer two is the same as mine, answer one is specific to PIC and answer 3 is a little vague, but contains the key phrase "with a width appropriate for the addressable size of the memory segment". So a pointer could be say 1000H, which could be used to address location 1000H with an immediate access, or loaded to a register as indirect access. This is analogous to writing char c = (char*)0x1000; in C++. >> The pointers in your example are esp (the stack pointer) and ebp (the base >> pointer). > > These are hardware registers. Correct, look at their names again. >> The instruction >> >> mov DWORD PTR _arr$[ebp], 0 >> >> given the definition of the constant _arr$ >> >> _arr$ = -12 ; size = 12 >> >> writes zero the the memory location who's address is ebp-12. Here ebp is >> the pointer and -12 is the offset. > > _arr$ is a label that equates to the value of (-12) . That is what I said. > Here the label _arr$ is used as a pointer, No it is used as an offer to a pointer. >> The next assignment which is a bit messy in MASM, >> >> mov DWORD PTR _arr$[ebp+4], eax >> >> writes zero the the memory location who's address is ebp-12+4. > > This confirms that _arr$ is an offset, which is used to create a memory > address. Therefore it's a pointer. No it isn't. It's no more a pointer than the 1 in *(p+1) = 0; No tell me again, how many x86 assembly projects have you worked on? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 22:04 +0100 |
| Message-ID | <trdEp.7717$Tw4.4984@newsfe26.ams2> |
| In reply to | #5779 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:94d3qqFr1qU5@mid.individual.net... > On 05/28/11 11:24 PM, Paul wrote: >> >> "Ian Collins"<ian-news@hotmail.com> wrote in message >> news:94b8rkFr1qU2@mid.individual.net... >>> On 05/28/11 02:29 PM, Paul wrote: >>>> >>>> You are very quick to dismiss my opinion of what a pointer is in >>>> assembly >>>> as >>>> incorrect but what exactly is your opinion of what a pointer is? >>> >>> I was equally quick to dismiss the prediction that the world would end >>> last weekend. >>> >>> A pointer in x86 assembly is simply a memory location or register that >>> contains the address of another memory location. That's is not my >>> opinion, it is what it is. >> >> No that is your opinion. >> Other people have different opinions and I happen to be one of those >> people. > > I value the opinions of other professionals I have worked wit or known. So > tell me, how many x86 assembly projects have you worked on? > >> I have already posted a link to Randal Hydes Art of Assembly that >> describes >> what a pointer is, and RH defines that a pointer can be a simple offset. > > No, it does not. As usual you have chosen to misinterpret the link you > have posted. > I didn't interpret the link at all. I quoted it word for word. >> Here is another link that shows some other peoples opinions: >> http://stackoverflow.com/questions/5055619/pointers-seen-on-assembly-or-registries > > So these are trusted sources? If so answer two is the same as mine, > answer one is specific to PIC and answer 3 is a little vague, but contains > the key phrase "with a width appropriate for the addressable size of the > memory segment". So a pointer could be say 1000H, which could be used to > address location 1000H with an immediate access, or loaded to a register > as indirect access. This is analogous to writing > Answer two is nothing like yours. Answer 2 states: "Pointer is nothing but a unsigned integer indicating position in a memory (virtual address space to be precise)." > char c = (char*)0x1000; > > in C++. > >>> The pointers in your example are esp (the stack pointer) and ebp (the >>> base >>> pointer). >> >> These are hardware registers. > > Correct, look at their names again. We are talking about pointers in software, not a hardware pointer. > >>> The instruction >>> >>> mov DWORD PTR _arr$[ebp], 0 >>> >>> given the definition of the constant _arr$ >>> >>> _arr$ = -12 ; size = 12 >>> >>> writes zero the the memory location who's address is ebp-12. Here ebp >>> is >>> the pointer and -12 is the offset. >> >> _arr$ is a label that equates to the value of (-12) . > > That is what I said. You said this meant it was not not a pointer. > >> Here the label _arr$ is used as a pointer, > > No it is used as an offer to a pointer. It's used as an offset to a hardware pointer,because it points to an offset in the stack frame. This does not mean that the offset is not also pointer. > >>> The next assignment which is a bit messy in MASM, >>> >>> mov DWORD PTR _arr$[ebp+4], eax >>> >>> writes zero the the memory location who's address is ebp-12+4. >> >> This confirms that _arr$ is an offset, which is used to create a memory >> address. Therefore it's a pointer. > > No it isn't. It's no more a pointer than the 1 in *(p+1) = 0; No its more like: const int offset_to_array = 1; (p+offset_to_array) > > No tell me again, how many x86 assembly projects have you worked on? > Since when was this discussion limited to x86 processors?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-29 09:17 +1200 |
| Message-ID | <94d73cFr2iU1@mid.individual.net> |
| In reply to | #5780 |
On 05/29/11 09:04 AM, Paul wrote: > "Ian Collins"<ian-news@hotmail.com> wrote: >> >> No tell me again, how many x86 assembly projects have you worked on? >> > > Since when was this discussion limited to x86 processors? Evasion again I see, so tell me again, how many assembly language projects have you worked on? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
Page 13 of 18 — ← Prev page 1 … 11 12 [13] 14 15 … 18 Next page →
Back to top | Article view | comp.lang.c++
csiph-web