Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.advocacy > #472229 > unrolled thread
| Started by | RonB <ronb02NOSPAM@gmail.com> |
|---|---|
| First post | 2018-10-16 00:24 +0000 |
| Last post | 2018-10-19 16:12 -0400 |
| Articles | 20 on this page of 203 — 18 participants |
Back to article view | Back to comp.os.linux.advocacy
Elizabeth Warren 1/1024 Native American RonB <ronb02NOSPAM@gmail.com> - 2018-10-16 00:24 +0000
Re: Elizabeth Warren 1/1024 Native American SilverSlimer <silver@slim.er> - 2018-10-15 20:27 -0400
Re: Elizabeth Warren 1/1024 Native American RonB <ronb02NOSPAM@gmail.com> - 2018-10-16 00:37 +0000
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-16 00:46 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-15 18:05 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-16 03:05 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-15 20:23 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-16 03:33 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-16 08:58 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-16 09:04 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-16 16:39 +0000
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-16 16:15 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 09:33 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-16 09:41 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-16 16:55 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-16 10:07 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-16 18:40 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-16 14:14 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 14:30 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-17 01:23 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 18:41 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-16 19:29 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 19:59 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-17 03:58 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 21:17 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-17 10:08 -0700
Re: Elizabeth Warren 1/1024 Native American chrisv <chrisv@nospam.invalid> - 2018-10-17 12:41 -0500
Re: Elizabeth Warren 1/1024 Native American Hadron Quark <hadronquark@gmail.com> - 2018-10-17 19:48 +0200
Re: Elizabeth Warren 1/1024 Native American chrisv <chrisv@nospam.invalid> - 2018-10-17 13:10 -0500
Re: Elizabeth Warren 1/1024 Native American Torquemada <whocares@whocares.org> - 2018-10-17 14:13 -0400
Re: Elizabeth Warren 1/1024 Native American chrisv <chrisv@nospam.invalid> - 2018-10-17 15:09 -0500
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-17 20:31 +0000
Re: Elizabeth Warren 1/1024 Native American chrisv <chrisv@nospam.invalid> - 2018-10-18 07:06 -0500
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-18 05:35 -0700
Re: Elizabeth Warren 1/1024 Native American "F. Russell" <fr@random.info> - 2018-10-18 12:41 +0000
Re: Elizabeth Warren 1/1024 Native American Torquemada <whocares@whocares.org> - 2018-10-17 20:10 -0400
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 17:20 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-17 11:11 -0700
Re: Elizabeth Warren 1/1024 Native American Hadron Quark <hadronquark@gmail.com> - 2018-10-17 20:28 +0200
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-17 11:54 -0700
An array of strings is an array of pointers. Jeff-Relf.Me @. - 2018-10-17 12:48 -0700
Re: An array of strings is an array of pointers. Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 13:10 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 12:38 -0700
Re: Elizabeth Warren 1/1024 Native American fr314159@gmail.com - 2018-10-17 11:30 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 12:08 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-17 12:42 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-17 20:00 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-17 13:25 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-17 20:46 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 14:13 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-18 08:58 -0700
Re: Elizabeth Warren 1/1024 Native American Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-18 17:28 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-18 11:01 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-18 18:16 +0000
Re: Elizabeth Warren 1/1024 Native American Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-18 18:39 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-18 11:51 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-18 11:04 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-18 17:54 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-18 11:12 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-18 18:25 +0000
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-18 18:39 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-18 12:03 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-18 19:54 +0000
Re: Elizabeth Warren 1/1024 Native American "F. Russell" <fr@random.info> - 2018-10-18 20:02 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-18 13:24 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-18 22:32 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-18 16:02 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-19 01:22 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-19 00:19 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-19 09:24 -0700
Re: Elizabeth Warren 1/1024 Native American Hadron Quark <hadronquark@gmail.com> - 2018-10-19 19:16 +0200
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-19 10:30 -0700
Re: Elizabeth Warren 1/1024 Native American Hadron Quark <hadronquark@gmail.com> - 2018-10-19 22:34 +0200
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-19 13:51 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-19 18:33 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-19 12:16 -0700
Re: Elizabeth Warren 1/1024 Native American Hadron Quark <hadronquark@gmail.com> - 2018-10-19 22:39 +0200
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-19 11:14 -0700
Re: Elizabeth Warren 1/1024 Native American "F. Russell" <fr@random.info> - 2018-10-18 18:46 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-18 12:06 -0700
Re: Elizabeth Warren 1/1024 Native American fr314159@gmail.com - 2018-10-17 13:13 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 13:25 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-17 13:31 -0700
Re: Elizabeth Warren 1/1024 Native American fr314159@gmail.com - 2018-10-17 13:50 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 15:00 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-17 20:50 +0000
Re: Elizabeth Warren 1/1024 Native American "F. Russell" <fr@random.info> - 2018-10-18 00:11 +0000
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-17 19:48 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 20:12 -0700
Re: Elizabeth Warren 1/1024 Native American Hadron Quark <hadronquark@gmail.com> - 2018-10-18 09:35 +0200
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-18 00:52 -0700
Re: Elizabeth Warren 1/1024 Native American Mel <mel@zzzzz.com> - 2018-10-18 12:16 +0200
Re: Elizabeth Warren 1/1024 Native American chrisv <chrisv@nospam.invalid> - 2018-10-18 07:11 -0500
Re: Elizabeth Warren 1/1024 Native American "F. Russell" <fr@random.info> - 2018-10-18 12:47 +0000
Re: Elizabeth Warren 1/1024 Native American chrisv <chrisv@nospam.invalid> - 2018-10-18 08:10 -0500
Re: Elizabeth Warren 1/1024 Native American "F. Russell" <fr@random.info> - 2018-10-18 13:28 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-18 09:04 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-18 06:38 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-18 06:22 -0700
Re: Elizabeth Warren 1/1024 Native American Hadron Quark <hadronquark@gmail.com> - 2018-10-17 22:48 +0200
Re: Elizabeth Warren 1/1024 Native American "F. Russell" <fr@random.info> - 2018-10-17 09:53 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 03:15 -0700
Re: Elizabeth Warren 1/1024 Native American fr314159@gmail.com - 2018-10-17 09:37 -0700
Re: Elizabeth Warren 1/1024 Native American Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-17 16:41 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-17 10:12 -0700
Re: Elizabeth Warren 1/1024 Native American fr314159@gmail.com - 2018-10-17 10:14 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-17 10:40 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 11:20 -0700
Re: Elizabeth Warren 1/1024 Native American "F. Russell" <fr@random.info> - 2018-10-18 01:29 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 18:53 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-18 09:00 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-18 09:15 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 10:33 -0700
Re: Elizabeth Warren 1/1024 Native American Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-17 23:01 +0000
Re: Elizabeth Warren 1/1024 Native American Hadron Quark <hadronquark@gmail.com> - 2018-10-18 01:29 +0200
Re: Elizabeth Warren 1/1024 Native American Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-17 23:37 +0000
Re: Elizabeth Warren 1/1024 Native American "F. Russell" <fr@random.info> - 2018-10-18 00:01 +0000
Re: Elizabeth Warren 1/1024 Native American Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-18 00:03 +0000
Re: Elizabeth Warren 1/1024 Native American "F. Russell" <fr@random.info> - 2018-10-18 00:23 +0000
Re: Elizabeth Warren 1/1024 Native American Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-18 00:26 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 17:35 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-18 00:23 +0000
Re: Elizabeth Warren 1/1024 Native American Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-18 00:26 +0000
Re: Elizabeth Warren 1/1024 Native American "F. Russell" <fr@random.info> - 2018-10-18 00:34 +0000
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-18 01:49 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 19:08 -0700
Re: Elizabeth Warren 1/1024 Native American "F. Russell" <fr@random.info> - 2018-10-18 13:04 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 17:05 -0700
Re: Elizabeth Warren 1/1024 Native American "F. Russell" <fr@random.info> - 2018-10-18 00:20 +0000
Re: Elizabeth Warren 1/1024 Native American Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-18 00:25 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 09:45 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <fretwizzer@gmail.com> - 2018-10-17 10:11 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-15 20:49 -0700
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-16 06:46 -0700
Re: Elizabeth Warren 1/1024 Native American Hadron Quark <hadronquark@gmail.com> - 2018-10-16 16:17 +0200
Re: Elizabeth Warren 1/1024 Native American SilverSlimer <silver@slim.er> - 2018-10-16 12:25 -0400
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 10:05 -0700
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-16 15:21 -0700
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-16 15:19 -0700
Re: Elizabeth Warren 1/1024 Native American SilverSlimer <silver@slim.er> - 2018-10-15 21:17 -0400
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-16 06:39 -0700
Re: Elizabeth Warren 1/1024 Native American -hh <recscuba_google@huntzinger.com> - 2018-10-15 18:21 -0700
Re: Elizabeth Warren 1/1024 Native American SilverSlimer <silver@slim.er> - 2018-10-16 12:18 -0400
Re: Elizabeth Warren 1/1024 Native American DFS <nospam@nospam.com> - 2018-10-16 12:28 -0400
Re: Elizabeth Warren 1/1024 Native American RonB <ronb02NOSPAM@gmail.com> - 2018-10-17 01:07 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 18:10 -0700
Re: Elizabeth Warren 1/1024 Native American owl <owl@rooftop.invalid> - 2018-10-17 01:40 +0000
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-15 17:42 -0700
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-16 06:48 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-15 17:58 -0700
Elizabeth Warren 1/1024 Native American -hh <recscuba_google@huntzinger.com> - 2018-10-15 18:08 -0700
Re: Elizabeth Warren 1/1024 Native American SilverSlimer <silver@slim.er> - 2018-10-15 21:18 -0400
Re: Elizabeth Warren 1/1024 Native American -hh <recscuba_google@huntzinger.com> - 2018-10-15 18:29 -0700
Re: Elizabeth Warren 1/1024 Native American SilverSlimer <silver@slim.er> - 2018-10-16 12:19 -0400
Re: Elizabeth Warren 1/1024 Native American Torquemada <whocares@whocares.org> - 2018-10-16 14:12 -0400
Re: Elizabeth Warren 1/1024 Native American -hh <recscuba_google@huntzinger.com> - 2018-10-16 11:43 -0700
Re: Elizabeth Warren 1/1024 Native American SilverSlimer <silver@slim.er> - 2018-10-16 18:48 -0400
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-16 15:57 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 16:50 -0700
Re: Elizabeth Warren 1/1024 Native American DFS <nospam@nospam.com> - 2018-10-16 20:16 -0400
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-16 19:02 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 19:12 -0700
Re: Elizabeth Warren 1/1024 Native American Hadron Quark <hadronquark@gmail.com> - 2018-10-17 19:36 +0200
Re: Elizabeth Warren 1/1024 Native American Torquemada <whocares@whocares.org> - 2018-10-17 13:42 -0400
Re: Elizabeth Warren 1/1024 Native American chrisv <chrisv@nospam.invalid> - 2018-10-17 12:44 -0500
Re: Elizabeth Warren 1/1024 Native American Torquemada <whocares@whocares.org> - 2018-10-17 13:48 -0400
Re: Elizabeth Warren 1/1024 Native American chrisv <chrisv@nospam.invalid> - 2018-10-17 12:52 -0500
Re: Elizabeth Warren 1/1024 Native American Hadron Quark <hadronquark@gmail.com> - 2018-10-17 20:03 +0200
Re: Elizabeth Warren 1/1024 Native American Torquemada <whocares@whocares.org> - 2018-10-17 14:12 -0400
Re: Elizabeth Warren 1/1024 Native American Hadron Quark <hadronquark@gmail.com> - 2018-10-17 20:29 +0200
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-16 15:20 -0700
Hugh could be more succinct, if he tried. Jeff-Relf.Me @. - 2018-10-16 15:24 -0700
Hugh could be more succinct, if he tried. -hh <recscuba_google@huntzinger.com> - 2018-10-16 15:55 -0700
We're all selling something. Jeff-Relf.Me @. - 2018-10-16 16:11 -0700
We're all selling something. -hh <recscuba_google@huntzinger.com> - 2018-10-16 17:14 -0700
Re: We're all selling something. Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 17:38 -0700
Re: Hugh could be more succinct, if he tried. chrisv <chrisv@nospam.invalid> - 2018-10-17 08:00 -0500
Re: Hugh could be more succinct, if he tried. Steve Carroll <frelwizzen@gmail.com> - 2018-10-17 06:21 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 15:48 -0700
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-16 15:17 -0700
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-16 06:38 -0700
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-16 06:44 -0700
Re: Elizabeth Warren 1/1024 Native American Hadron Quark <hadronquark@gmail.com> - 2018-10-16 16:15 +0200
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 08:15 -0700
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-16 15:18 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 15:32 -0700
Re: Elizabeth Warren 1/1024 Native American Steve Carroll <frelwizzen@gmail.com> - 2018-10-15 18:13 -0700
Re: Elizabeth Warren 1/1024 Native American Snit <usenet@gallopinginsanity.com> - 2018-10-16 06:51 -0700
So bigfoot had nailed Ron's great, great, grandmother? Simon bar Sinister <John.H.Gohde@gmail.com> - 2018-10-16 07:44 -0700
Re: So bigfoot had nailed Ron's great, great, grandmother? chrisv <chrisv@nospam.invalid> - 2018-10-16 10:22 -0500
Re: So bigfoot had nailed Ron's great, great, grandmother? owl <owl@rooftop.invalid> - 2018-10-16 15:46 +0000
Re: So bigfoot had nailed Ron's great, great, grandmother? Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 09:02 -0700
Re: So bigfoot had nailed Ron's great, great, grandmother? chrisv <chrisv@nospam.invalid> - 2018-10-16 12:07 -0500
Re: So bigfoot had nailed Ron's great, great, grandmother? owl <owl@rooftop.invalid> - 2018-10-16 18:42 +0000
Re: So bigfoot had nailed Ron's great, great, grandmother? chrisv <chrisv@nospam.invalid> - 2018-10-16 13:52 -0500
Re: So bigfoot had nailed Ron's great, great, grandmother? owl <owl@rooftop.invalid> - 2018-10-16 19:12 +0000
Re: So bigfoot had nailed Ron's great, great, grandmother? chrisv <chrisv@nospam.invalid> - 2018-10-16 14:41 -0500
Re: So bigfoot had nailed Ron's great, great, grandmother? Chris Ahlstrom <OFeem1987@teleworm.us> - 2018-10-16 17:55 -0400
Re: So bigfoot had nailed Ron's great, great, grandmother? Steve Carroll <frelwizzen@gmail.com> - 2018-10-16 12:09 -0700
Re: So bigfoot had nailed Ron's great, great, grandmother? RonB <ronb02NOSPAM@gmail.com> - 2018-10-17 01:14 +0000
Re: So bigfoot had nailed Ron's great, great, grandmother? Snit <usenet@gallopinginsanity.com> - 2018-10-16 19:03 -0700
Re: So bigfoot had nailed Ron's great, great, grandmother? Hadron Quark <hadronquark@gmail.com> - 2018-10-17 19:37 +0200
Re: So bigfoot had nailed Ron's great, great, grandmother? DFS <nospam@nospam.com> - 2018-10-19 16:12 -0400
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2018-10-18 18:39 +0000 |
| Message-ID | <k80z08bzb03.a3@rooftop.invalid> |
| In reply to | #472655 |
owl <owl@rooftop.invalid> wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
>> On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
>>> Steve Carroll <fretwizzer@gmail.com> wrote:
>>> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
>>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>>> >
>>> > (snip)
>>> >
>>> >> >> x is never anything but a pointer.
>>> >> >
>>> >> > But it can still hold a value.
>>> >>
>>> >>
>>> >> An address value.
>>> >
>>> > I know that a var is just a place in memory that holds a value so, in this
>>> > respect, it's a pointer. But why complicate things with this additional
>>> > pointer keyword? Why the need to refer to the first char at all?
>>> >
>>> >> > For example, when I also run this with the above,
>>> >> > and placed above it...
>>> >> >
>>> >> > char *p = "test";
>>> >> > char b[] = "test";
>>> >> > printf("%c\n",*p);
>>> >> > printf("%s\n",b);
>>> >> >
>>> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
>>> >> >
>>> >>
>>> >> p and *p are different things. p is the address. *p is the char at
>>> >> that address.
>>> >
>>> > What I initially didn't realize (because it failed on a first run!) was this...
>>> >
>>> > char *p = "test";
>>> >
>>> > ... is simultaneously assigning the value "test to the variable 'p' and
>>> > creating a pointer to it (the first char). So this will display both :
>>> >
>>> > char *p = "test";
>>> > printf("%c\n",*p);
>>> > printf("%s\n",p);
>>> >
>>> > In any event, I get back 't' and then the entire string "test", which is, to
>>> > my way of thinking, a value, not an "address". I also noticed a pointer
>>> > has to be defined in advance, this...
>>> >
>>> > char p = "test";
>>> > printf("%c\n",*p);
>>> >
>>> > ... won't work, which seems odd to me. Maybe it's due to the fact that
>>> > you won't always need a pointer? However, if you do decide to create
>>> > one you can assign a value to the 'pointed to' variable simultaneously,
>>> > which is handy.
>>> >
>>> >> a %s printf would print that char and all successive
>>> >> chars until it hits a '\0'.
>>> >>
>>> >>
>>> >>
>>> >> > webdev$ ./test
>>> >> > t
>>> >> > test
>>> >> > (null)
>>> >> > hello
>>> >> > hello
>>> >> >
>>> >> > One strange thing, this time, just by adding the new lines, instead of a blank
>>> >> > line I got: '(null)'.
>>> >>
>>> >> Like I said, x is null at that point.
>>> >
>>> > I got it, but it didn't display null the first time through, just a blank line,
>>> > which was a little confusing.
>>> >
>>> >> When I run it, with the your new code placed above the old, the first
>>> >> thing that happens with stdout is the attempt to
>>> >>
>>> >> printf("%c\n",x);
>>> >>
>>> >> when x has not yet been assigned a value. That is an attempt to
>>> >> print (as a char) the null pointer x.
>>> >
>>> > As I assume most of us do, I often learn more by trying to break things,
>>> > code that runs differently on the first run slows things down a bit. What
>>> > causes that?
>>> >
>>>
>>> When trying to grasp pointers, you have to get away from the concept of
>>> strings. Pointers are addresses. Period.
>>
>> From what I've read they're 'named' addresses so, like you show below, a
>> pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
>>
>
> That is the address of p itself, not the address that p holds.
> (See the code at the bottom).
>
>>
>>> In the case of "strings", the
>>> pointer is a "pointer to char". That is another way of saying "pointer
>>> to byte."
>>
>> Pointer to char... not pointer to *a* char (some given char)?
>
> Yes, pointer to *a* char.
>
This may need clarification. It is a pointer to a single char.
It need not be assigned anything yet. When it has been allocated for,
or otherwise assigned, then you can dereference it to the single char
it points to.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <fretwizzer@gmail.com> |
|---|---|
| Date | 2018-10-18 12:03 -0700 |
| Message-ID | <45823d69-6dbd-4760-aefc-dba729c059f5@googlegroups.com> |
| In reply to | #472655 |
On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >
> >> > (snip)
> >> >
> >> >> >> x is never anything but a pointer.
> >> >> >
> >> >> > But it can still hold a value.
> >> >>
> >> >>
> >> >> An address value.
> >> >
> >> > I know that a var is just a place in memory that holds a value so, in this
> >> > respect, it's a pointer. But why complicate things with this additional
> >> > pointer keyword? Why the need to refer to the first char at all?
> >> >
> >> >> > For example, when I also run this with the above,
> >> >> > and placed above it...
> >> >> >
> >> >> > char *p = "test";
> >> >> > char b[] = "test";
> >> >> > printf("%c\n",*p);
> >> >> > printf("%s\n",b);
> >> >> >
> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
> >> >> >
> >> >>
> >> >> p and *p are different things. p is the address. *p is the char at
> >> >> that address.
> >> >
> >> > What I initially didn't realize (because it failed on a first run!) was this...
> >> >
> >> > char *p = "test";
> >> >
> >> > ... is simultaneously assigning the value "test to the variable 'p' and
> >> > creating a pointer to it (the first char). So this will display both :
> >> >
> >> > char *p = "test";
> >> > printf("%c\n",*p);
> >> > printf("%s\n",p);
> >> >
> >> > In any event, I get back 't' and then the entire string "test", which is, to
> >> > my way of thinking, a value, not an "address". I also noticed a pointer
> >> > has to be defined in advance, this...
> >> >
> >> > char p = "test";
> >> > printf("%c\n",*p);
> >> >
> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that
> >> > you won't always need a pointer? However, if you do decide to create
> >> > one you can assign a value to the 'pointed to' variable simultaneously,
> >> > which is handy.
> >> >
> >> >> a %s printf would print that char and all successive
> >> >> chars until it hits a '\0'.
> >> >>
> >> >>
> >> >>
> >> >> > webdev$ ./test
> >> >> > t
> >> >> > test
> >> >> > (null)
> >> >> > hello
> >> >> > hello
> >> >> >
> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank
> >> >> > line I got: '(null)'.
> >> >>
> >> >> Like I said, x is null at that point.
> >> >
> >> > I got it, but it didn't display null the first time through, just a blank line,
> >> > which was a little confusing.
> >> >
> >> >> When I run it, with the your new code placed above the old, the first
> >> >> thing that happens with stdout is the attempt to
> >> >>
> >> >> printf("%c\n",x);
> >> >>
> >> >> when x has not yet been assigned a value. That is an attempt to
> >> >> print (as a char) the null pointer x.
> >> >
> >> > As I assume most of us do, I often learn more by trying to break things,
> >> > code that runs differently on the first run slows things down a bit. What
> >> > causes that?
> >> >
> >>
> >> When trying to grasp pointers, you have to get away from the concept of
> >> strings. Pointers are addresses. Period.
> >
> > From what I've read they're 'named' addresses so, like you show below, a
> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
> >
>
> That is the address of p itself, not the address that p holds.
Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which
is where 't' is stored. This makes sense and thanks to your other post about
printf doing what it does (yes, I know, you ran that past me several times but I
didn't understand) from the pointer on out... things are a bit more clear.
> (See the code at the bottom).
I've seen this, or similar, but I gotta study on these operators:
char *c=(char *)&x;
Is the idea behind the pointers to (more efficiently?) point to something and,
depending on how you do it, you'll use more of the block of bytes stored as
beginning from that 'starting' memory location? IOW, printf did its things and
stops where it does... other methods will start at the 'starting' point and do
their thing, as it were?
> >> In the case of "strings", the
> >> pointer is a "pointer to char". That is another way of saying "pointer
> >> to byte."
> >
> > Pointer to char... not pointer to *a* char (some given char)?
>
> Yes, pointer to *a* char.
>
> > I'm really not
> > mincing words here,I'm merely highlighting the terms I've seen you use
> > that aren't solidified in my mind. I get the pointer to a byte idea.
> >
>
>
> #include <stdio.h>
>
> int main(void)
> {
> int i=0;
> int x=0x64636261;
> char *c=(char *)&x;
> for(i=0;i<4;i++)
> {
> printf("%c\n",*c++);
> }
> return 0;
> }
>
>
> >> The reason it is important to forget about strings when trying
> >> to grasp pointers is because pointers can be to any type of abstract
> >> data type you might want to create. Incrementing a char pointer just
> >> increments by one byte, which is what the %s printf() format specifier
> >> does until it hits a '\0' "string terminator". With other abstract
> >> data types, such as some struct that you might create, a pointer would
> >> increment by the size of that data type.
> >
> > I don't know the issues involved with learning this as I learn about
> > strings, too, so I'll take your word for it.
> >
> >> The following program just has
> >>
> >> char *p="test";
> >>
> >> and then some observational code.
> >>
> >> anon@lowtide:~/code$ ./w
> >> The pointer variable p is located at address 0x7ffc9f9f81e8
> >> Being a pointer to char, p holds the address of a byte.
> >> The value that p holds is: 0x4006e8
> >> The value of the byte at address 0x4006e8 is t
> >> The value of the byte at address 0x4006e9 is e
> >> The value of the byte at address 0x4006ea is s
> >> The value of the byte at address 0x4006eb is t
> >> The value of the byte at address 0x4006ec is
> >> anon@lowtide:~/code$
> >
> > I realize this, I saw some code, somewhere, that used a function to get
> > the numeric addresses. If I'm to continue with C I think Mel and Feeb
> > might be right about assembler 'cuz this isn't clicking for me 100%.
> > Mel just blew my mind on a previous post ;)
> >
>
> #include <stdio.h>
>
> int main(void)
> {
> char *p="test";
> printf("The pointer variable p is located at address %p\n",(void *)&p);
> printf("Being a pointer to char, p holds the address of a byte.\n");
> printf("The value that p holds is: %p\n",(void *)p);
> printf("The value of the byte at address %p is %c\n",(void *)p,*p);
> printf("The value of the byte at address %p is %c\n",(void *)(p+1),*(p+1));
> printf("The value of the byte at address %p is %c\n",(void *)(p+2),*(p+2));
> printf("The value of the byte at address %p is %c\n",(void *)(p+3),*(p+3));
> printf("The value of the byte at address %p is %c\n",(void *)(p+4),*(p+4));
> return 0;
> }
Runs fine and is informative, thank you. What I get errors with on this Mac is:
void main()
I have to use int.
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2018-10-18 19:54 +0000 |
| Message-ID | <9z0808bz0b.3ga8@rooftop.invalid> |
| In reply to | #472662 |
Steve Carroll <fretwizzer@gmail.com> wrote:
> On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote:
>> Steve Carroll <fretwizzer@gmail.com> wrote:
>> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> >
>> >> > (snip)
>> >> >
>> >> >> >> x is never anything but a pointer.
>> >> >> >
>> >> >> > But it can still hold a value.
>> >> >>
>> >> >>
>> >> >> An address value.
>> >> >
>> >> > I know that a var is just a place in memory that holds a value so, in this
>> >> > respect, it's a pointer. But why complicate things with this additional
>> >> > pointer keyword? Why the need to refer to the first char at all?
>> >> >
>> >> >> > For example, when I also run this with the above,
>> >> >> > and placed above it...
>> >> >> >
>> >> >> > char *p = "test";
>> >> >> > char b[] = "test";
>> >> >> > printf("%c\n",*p);
>> >> >> > printf("%s\n",b);
>> >> >> >
>> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
>> >> >> >
>> >> >>
>> >> >> p and *p are different things. p is the address. *p is the char at
>> >> >> that address.
>> >> >
>> >> > What I initially didn't realize (because it failed on a first run!) was this...
>> >> >
>> >> > char *p = "test";
>> >> >
>> >> > ... is simultaneously assigning the value "test to the variable 'p' and
>> >> > creating a pointer to it (the first char). So this will display both :
>> >> >
>> >> > char *p = "test";
>> >> > printf("%c\n",*p);
>> >> > printf("%s\n",p);
>> >> >
>> >> > In any event, I get back 't' and then the entire string "test", which is, to
>> >> > my way of thinking, a value, not an "address". I also noticed a pointer
>> >> > has to be defined in advance, this...
>> >> >
>> >> > char p = "test";
>> >> > printf("%c\n",*p);
>> >> >
>> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that
>> >> > you won't always need a pointer? However, if you do decide to create
>> >> > one you can assign a value to the 'pointed to' variable simultaneously,
>> >> > which is handy.
>> >> >
>> >> >> a %s printf would print that char and all successive
>> >> >> chars until it hits a '\0'.
>> >> >>
>> >> >>
>> >> >>
>> >> >> > webdev$ ./test
>> >> >> > t
>> >> >> > test
>> >> >> > (null)
>> >> >> > hello
>> >> >> > hello
>> >> >> >
>> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank
>> >> >> > line I got: '(null)'.
>> >> >>
>> >> >> Like I said, x is null at that point.
>> >> >
>> >> > I got it, but it didn't display null the first time through, just a blank line,
>> >> > which was a little confusing.
>> >> >
>> >> >> When I run it, with the your new code placed above the old, the first
>> >> >> thing that happens with stdout is the attempt to
>> >> >>
>> >> >> printf("%c\n",x);
>> >> >>
>> >> >> when x has not yet been assigned a value. That is an attempt to
>> >> >> print (as a char) the null pointer x.
>> >> >
>> >> > As I assume most of us do, I often learn more by trying to break things,
>> >> > code that runs differently on the first run slows things down a bit. What
>> >> > causes that?
>> >> >
>> >>
>> >> When trying to grasp pointers, you have to get away from the concept of
>> >> strings. Pointers are addresses. Period.
>> >
>> > From what I've read they're 'named' addresses so, like you show below, a
>> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
>> >
>>
>> That is the address of p itself, not the address that p holds.
>
> Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which
> is where 't' is stored. This makes sense and thanks to your other post about
> printf doing what it does (yes, I know, you ran that past me several times but I
> didn't understand) from the pointer on out... things are a bit more clear.
>
>> (See the code at the bottom).
>
> I've seen this, or similar, but I gotta study on these operators:
> char *c=(char *)&x;
>
There x is an int (a 4-byte value). The code casts the address of the
int to a char pointer, so you can walk the bytes of the int.
> Is the idea behind the pointers to (more efficiently?) point to something and,
> depending on how you do it, you'll use more of the block of bytes stored as
> beginning from that 'starting' memory location? IOW, printf did its things and
> stops where it does... other methods will start at the 'starting' point and do
> their thing, as it were?
>
Think of everything as bytes in memory. All pointers just hold a
memory address, and you can have whatever kind of data you want at
that address. When you allocate for a pointer, you specify what kind
of object it is pointing to. That way, when you walk the pointer,
it increments by the appropriate amount of bytes.
char *x;
x=malloc(100); /* allocate 100 bytes */
...
x++; /* increment pointer by one byte */
struct whateva *y;
y=malloc(100 * sizeof(struct whateva)); /* allocate for 100 whatevas */
...
y++; /* incement pointer by size of a wheteva */
[toc] | [prev] | [next] | [standalone]
| From | "F. Russell" <fr@random.info> |
|---|---|
| Date | 2018-10-18 20:02 +0000 |
| Message-ID | <pqaosn02iff@news2.newsguy.com> |
| In reply to | #472667 |
On Thu, 18 Oct 2018 19:54:52 +0000, owl wrote: > > Think of everything as bytes in memory. All pointers just hold a > memory address, and you can have whatever kind of data you want at > that address. When you allocate for a pointer, you specify what kind > of object it is pointing to. > There is help for those in dire need: https://github.com/ridiculousfish/cdecl-blocks
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-10-18 13:24 -0700 |
| Message-ID | <13c2f536-7e66-4c0b-a027-67c9f10155fc@googlegroups.com> |
| In reply to | #472667 |
On Thursday, October 18, 2018 at 12:54:54 PM UTC-7, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote:
> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
> >> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> >
> >> >> > (snip)
> >> >> >
> >> >> >> >> x is never anything but a pointer.
> >> >> >> >
> >> >> >> > But it can still hold a value.
> >> >> >>
> >> >> >>
> >> >> >> An address value.
> >> >> >
> >> >> > I know that a var is just a place in memory that holds a value so, in this
> >> >> > respect, it's a pointer. But why complicate things with this additional
> >> >> > pointer keyword? Why the need to refer to the first char at all?
> >> >> >
> >> >> >> > For example, when I also run this with the above,
> >> >> >> > and placed above it...
> >> >> >> >
> >> >> >> > char *p = "test";
> >> >> >> > char b[] = "test";
> >> >> >> > printf("%c\n",*p);
> >> >> >> > printf("%s\n",b);
> >> >> >> >
> >> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
> >> >> >> >
> >> >> >>
> >> >> >> p and *p are different things. p is the address. *p is the char at
> >> >> >> that address.
> >> >> >
> >> >> > What I initially didn't realize (because it failed on a first run!) was this...
> >> >> >
> >> >> > char *p = "test";
> >> >> >
> >> >> > ... is simultaneously assigning the value "test to the variable 'p' and
> >> >> > creating a pointer to it (the first char). So this will display both :
> >> >> >
> >> >> > char *p = "test";
> >> >> > printf("%c\n",*p);
> >> >> > printf("%s\n",p);
> >> >> >
> >> >> > In any event, I get back 't' and then the entire string "test", which is, to
> >> >> > my way of thinking, a value, not an "address". I also noticed a pointer
> >> >> > has to be defined in advance, this...
> >> >> >
> >> >> > char p = "test";
> >> >> > printf("%c\n",*p);
> >> >> >
> >> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that
> >> >> > you won't always need a pointer? However, if you do decide to create
> >> >> > one you can assign a value to the 'pointed to' variable simultaneously,
> >> >> > which is handy.
> >> >> >
> >> >> >> a %s printf would print that char and all successive
> >> >> >> chars until it hits a '\0'.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> > webdev$ ./test
> >> >> >> > t
> >> >> >> > test
> >> >> >> > (null)
> >> >> >> > hello
> >> >> >> > hello
> >> >> >> >
> >> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank
> >> >> >> > line I got: '(null)'.
> >> >> >>
> >> >> >> Like I said, x is null at that point.
> >> >> >
> >> >> > I got it, but it didn't display null the first time through, just a blank line,
> >> >> > which was a little confusing.
> >> >> >
> >> >> >> When I run it, with the your new code placed above the old, the first
> >> >> >> thing that happens with stdout is the attempt to
> >> >> >>
> >> >> >> printf("%c\n",x);
> >> >> >>
> >> >> >> when x has not yet been assigned a value. That is an attempt to
> >> >> >> print (as a char) the null pointer x.
> >> >> >
> >> >> > As I assume most of us do, I often learn more by trying to break things,
> >> >> > code that runs differently on the first run slows things down a bit. What
> >> >> > causes that?
> >> >> >
> >> >>
> >> >> When trying to grasp pointers, you have to get away from the concept of
> >> >> strings. Pointers are addresses. Period.
> >> >
> >> > From what I've read they're 'named' addresses so, like you show below, a
> >> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
> >> >
> >>
> >> That is the address of p itself, not the address that p holds.
> >
> > Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which
> > is where 't' is stored. This makes sense and thanks to your other post about
> > printf doing what it does (yes, I know, you ran that past me several times but I
> > didn't understand) from the pointer on out... things are a bit more clear.
> >
> >> (See the code at the bottom).
> >
> > I've seen this, or similar, but I gotta study on these operators:
> > char *c=(char *)&x;
> >
>
> There x is an int (a 4-byte value). The code casts the address of the
> int to a char pointer, so you can walk the bytes of the int.
>
>
> > Is the idea behind the pointers to (more efficiently?) point to something and,
> > depending on how you do it, you'll use more of the block of bytes stored as
> > beginning from that 'starting' memory location? IOW, printf did its things and
> > stops where it does... other methods will start at the 'starting' point and do
> > their thing, as it were?
> >
>
> Think of everything as bytes in memory. All pointers just hold a
> memory address, and you can have whatever kind of data you want at
> that address. When you allocate for a pointer, you specify what kind
> of object it is pointing to. That way, when you walk the pointer,
> it increments by the appropriate amount of bytes.
>
> char *x;
> x=malloc(100); /* allocate 100 bytes */
> ...
> x++; /* increment pointer by one byte */
>
> struct whateva *y;
> y=malloc(100 * sizeof(struct whateva)); /* allocate for 100 whatevas */
> ...
> y++; /* incement pointer by size of a wheteva */
BTW, I've already shown that his use of "herd" to describe true advocates is libel, since he's likening them to pack of wolves.
These posts are clearly not automated, they are made by Klaus Schadenfreude who is a glue sniffing insomniac with an axe to grind who has way too much time on his hands (with maybe some scripted pre-processing). You are quick as a tuna on ice.
You guys can only rationalize from the perspective of a psychopath. Ha, ha! Who doesn't know that this kind of hogwash is Klaus Schadenfreude's MO, not the MO of John Gohde? It's all just projection... the flooding, the sock puppets, the writing of drivel, the outbursts... the diaper rash and willingness to show how flustered he is over being kicked from the schoolyard for pissing in it again ;) If Klaus Schadenfreude calls having his lies quoted time and time again day in and day out by John Gohde and me successful 'trolling', then sure... he is a first-class troll. I can not subscribe to that definition, I use another term. I call Klaus Schadenfreude a total dolt.
--
Live on Kickstarter!
https://youtu.be/lF8yk7ul4Mw
http://tmp.gallopinginsanity.com/BilkHelp.html
Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2018-10-18 22:32 +0000 |
| Message-ID | <9a08b8083a.a3@rooftop.invalid> |
| In reply to | #472667 |
owl <owl@rooftop.invalid> wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
>> On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote:
>>> Steve Carroll <fretwizzer@gmail.com> wrote:
>>> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
>>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>>> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
>>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>>> >> >
>>> >> > (snip)
>>> >> >
>>> >> >> >> x is never anything but a pointer.
>>> >> >> >
>>> >> >> > But it can still hold a value.
>>> >> >>
>>> >> >>
>>> >> >> An address value.
>>> >> >
>>> >> > I know that a var is just a place in memory that holds a value so, in this
>>> >> > respect, it's a pointer. But why complicate things with this additional
>>> >> > pointer keyword? Why the need to refer to the first char at all?
>>> >> >
>>> >> >> > For example, when I also run this with the above,
>>> >> >> > and placed above it...
>>> >> >> >
>>> >> >> > char *p = "test";
>>> >> >> > char b[] = "test";
>>> >> >> > printf("%c\n",*p);
>>> >> >> > printf("%s\n",b);
>>> >> >> >
>>> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
>>> >> >> >
>>> >> >>
>>> >> >> p and *p are different things. p is the address. *p is the char at
>>> >> >> that address.
>>> >> >
>>> >> > What I initially didn't realize (because it failed on a first run!) was this...
>>> >> >
>>> >> > char *p = "test";
>>> >> >
>>> >> > ... is simultaneously assigning the value "test to the variable 'p' and
>>> >> > creating a pointer to it (the first char). So this will display both :
>>> >> >
>>> >> > char *p = "test";
>>> >> > printf("%c\n",*p);
>>> >> > printf("%s\n",p);
>>> >> >
>>> >> > In any event, I get back 't' and then the entire string "test", which is, to
>>> >> > my way of thinking, a value, not an "address". I also noticed a pointer
>>> >> > has to be defined in advance, this...
>>> >> >
>>> >> > char p = "test";
>>> >> > printf("%c\n",*p);
>>> >> >
>>> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that
>>> >> > you won't always need a pointer? However, if you do decide to create
>>> >> > one you can assign a value to the 'pointed to' variable simultaneously,
>>> >> > which is handy.
>>> >> >
>>> >> >> a %s printf would print that char and all successive
>>> >> >> chars until it hits a '\0'.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> > webdev$ ./test
>>> >> >> > t
>>> >> >> > test
>>> >> >> > (null)
>>> >> >> > hello
>>> >> >> > hello
>>> >> >> >
>>> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank
>>> >> >> > line I got: '(null)'.
>>> >> >>
>>> >> >> Like I said, x is null at that point.
>>> >> >
>>> >> > I got it, but it didn't display null the first time through, just a blank line,
>>> >> > which was a little confusing.
>>> >> >
>>> >> >> When I run it, with the your new code placed above the old, the first
>>> >> >> thing that happens with stdout is the attempt to
>>> >> >>
>>> >> >> printf("%c\n",x);
>>> >> >>
>>> >> >> when x has not yet been assigned a value. That is an attempt to
>>> >> >> print (as a char) the null pointer x.
>>> >> >
>>> >> > As I assume most of us do, I often learn more by trying to break things,
>>> >> > code that runs differently on the first run slows things down a bit. What
>>> >> > causes that?
>>> >> >
>>> >>
>>> >> When trying to grasp pointers, you have to get away from the concept of
>>> >> strings. Pointers are addresses. Period.
>>> >
>>> > From what I've read they're 'named' addresses so, like you show below, a
>>> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
>>> >
>>>
>>> That is the address of p itself, not the address that p holds.
>>
>> Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which
>> is where 't' is stored. This makes sense and thanks to your other post about
>> printf doing what it does (yes, I know, you ran that past me several times but I
>> didn't understand) from the pointer on out... things are a bit more clear.
>>
>>> (See the code at the bottom).
>>
>> I've seen this, or similar, but I gotta study on these operators:
>> char *c=(char *)&x;
>>
>
> There x is an int (a 4-byte value). The code casts the address of the
> int to a char pointer, so you can walk the bytes of the int.
>
You could also walk the ints themselves, with the int pointer,
and shift bits to isolate bytes:
#include <stdio.h>
#include <stdlib.h>
#define INTCOUNT 10
int main(void)
{
int *ip;
int i=0;
ip=malloc(INTCOUNT * sizeof *ip);
if(ip==NULL)
{
fprintf(stderr,"ip malloc failed\n");
exit(1);
}
ip[0]=0x41424344;
ip[1]=0x45464748;
ip[2]=0x494a4b4c;
ip[3]=0x4d4e4f50;
ip[4]=0x21222324;
ip[5]=0x25262728;
ip[6]=0x292a2b2c;
ip[7]=0x2d2e2f30;
ip[8]=0x31323334;
ip[9]=0x35363738;
for(i=0;i<INTCOUNT;i++)
{
printf("%c",ip[i]>>24);
printf("%c",ip[i]<<8>>24);
printf("%c",ip[i]<<16>>24);
printf("%c",ip[i]<<24>>24);
}
printf("\n");
free(ip);
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-10-18 16:02 -0700 |
| Message-ID | <3ad530bf-a87b-4a17-a0f3-8268653acbb8@googlegroups.com> |
| In reply to | #472679 |
On Thursday, October 18, 2018 at 3:32:37 PM UTC-7, owl wrote:
> owl <owl@rooftop.invalid> wrote:
> > Steve Carroll <fretwizzer@gmail.com> wrote:
> >> On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote:
> >>> Steve Carroll <fretwizzer@gmail.com> wrote:
> >>> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
> >>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >>> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
> >>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >>> >> >
> >>> >> > (snip)
> >>> >> >
> >>> >> >> >> x is never anything but a pointer.
> >>> >> >> >
> >>> >> >> > But it can still hold a value.
> >>> >> >>
> >>> >> >>
> >>> >> >> An address value.
> >>> >> >
> >>> >> > I know that a var is just a place in memory that holds a value so, in this
> >>> >> > respect, it's a pointer. But why complicate things with this additional
> >>> >> > pointer keyword? Why the need to refer to the first char at all?
> >>> >> >
> >>> >> >> > For example, when I also run this with the above,
> >>> >> >> > and placed above it...
> >>> >> >> >
> >>> >> >> > char *p = "test";
> >>> >> >> > char b[] = "test";
> >>> >> >> > printf("%c\n",*p);
> >>> >> >> > printf("%s\n",b);
> >>> >> >> >
> >>> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
> >>> >> >> >
> >>> >> >>
> >>> >> >> p and *p are different things. p is the address. *p is the char at
> >>> >> >> that address.
> >>> >> >
> >>> >> > What I initially didn't realize (because it failed on a first run!) was this...
> >>> >> >
> >>> >> > char *p = "test";
> >>> >> >
> >>> >> > ... is simultaneously assigning the value "test to the variable 'p' and
> >>> >> > creating a pointer to it (the first char). So this will display both :
> >>> >> >
> >>> >> > char *p = "test";
> >>> >> > printf("%c\n",*p);
> >>> >> > printf("%s\n",p);
> >>> >> >
> >>> >> > In any event, I get back 't' and then the entire string "test", which is, to
> >>> >> > my way of thinking, a value, not an "address". I also noticed a pointer
> >>> >> > has to be defined in advance, this...
> >>> >> >
> >>> >> > char p = "test";
> >>> >> > printf("%c\n",*p);
> >>> >> >
> >>> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that
> >>> >> > you won't always need a pointer? However, if you do decide to create
> >>> >> > one you can assign a value to the 'pointed to' variable simultaneously,
> >>> >> > which is handy.
> >>> >> >
> >>> >> >> a %s printf would print that char and all successive
> >>> >> >> chars until it hits a '\0'.
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >> > webdev$ ./test
> >>> >> >> > t
> >>> >> >> > test
> >>> >> >> > (null)
> >>> >> >> > hello
> >>> >> >> > hello
> >>> >> >> >
> >>> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank
> >>> >> >> > line I got: '(null)'.
> >>> >> >>
> >>> >> >> Like I said, x is null at that point.
> >>> >> >
> >>> >> > I got it, but it didn't display null the first time through, just a blank line,
> >>> >> > which was a little confusing.
> >>> >> >
> >>> >> >> When I run it, with the your new code placed above the old, the first
> >>> >> >> thing that happens with stdout is the attempt to
> >>> >> >>
> >>> >> >> printf("%c\n",x);
> >>> >> >>
> >>> >> >> when x has not yet been assigned a value. That is an attempt to
> >>> >> >> print (as a char) the null pointer x.
> >>> >> >
> >>> >> > As I assume most of us do, I often learn more by trying to break things,
> >>> >> > code that runs differently on the first run slows things down a bit. What
> >>> >> > causes that?
> >>> >> >
> >>> >>
> >>> >> When trying to grasp pointers, you have to get away from the concept of
> >>> >> strings. Pointers are addresses. Period.
> >>> >
> >>> > From what I've read they're 'named' addresses so, like you show below, a
> >>> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
> >>> >
> >>>
> >>> That is the address of p itself, not the address that p holds.
> >>
> >> Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which
> >> is where 't' is stored. This makes sense and thanks to your other post about
> >> printf doing what it does (yes, I know, you ran that past me several times but I
> >> didn't understand) from the pointer on out... things are a bit more clear.
> >>
> >>> (See the code at the bottom).
> >>
> >> I've seen this, or similar, but I gotta study on these operators:
> >> char *c=(char *)&x;
> >>
> >
> > There x is an int (a 4-byte value). The code casts the address of the
> > int to a char pointer, so you can walk the bytes of the int.
> >
>
> You could also walk the ints themselves, with the int pointer,
> and shift bits to isolate bytes:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> #define INTCOUNT 10
>
> int main(void)
> {
> int *ip;
> int i=0;
>
> ip=malloc(INTCOUNT * sizeof *ip);
> if(ip==NULL)
> {
> fprintf(stderr,"ip malloc failed\n");
> exit(1);
> }
>
> ip[0]=0x41424344;
> ip[1]=0x45464748;
> ip[2]=0x494a4b4c;
> ip[3]=0x4d4e4f50;
> ip[4]=0x21222324;
> ip[5]=0x25262728;
> ip[6]=0x292a2b2c;
> ip[7]=0x2d2e2f30;
> ip[8]=0x31323334;
> ip[9]=0x35363738;
>
> for(i=0;i<INTCOUNT;i++)
> {
> printf("%c",ip[i]>>24);
> printf("%c",ip[i]<<8>>24);
> printf("%c",ip[i]<<16>>24);
> printf("%c",ip[i]<<24>>24);
> }
> printf("\n");
>
> free(ip);
> return 0;
> }
Do you have a high school diploma?
Thus, my earliest statement stands literal and correct. The only undertaking that matters to Klaus Schadenfreude is arguing he is "right", and if he can't have that he will flood to effectively shout Sandman down... he's been that way forever. Klaus Schadenfreude calls it "obsessing" over him, even though he proceeds to elicit that exact rejoiner.
-
Eight things to never feed your dog!
https://goo.gl/Fho5Nq
https://www.facebook.com/jenny.eklund
Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-10-19 01:22 -0700 |
| Message-ID | <ff3286d8-75ea-42ca-a549-86f82fa6406a@googlegroups.com> |
| In reply to | #472681 |
On Thursday, October 18, 2018 at 4:02:49 PM UTC-7, Steve Carroll wrote:
> On Thursday, October 18, 2018 at 3:32:37 PM UTC-7, owl wrote:
> > owl <owl@rooftop.invalid> wrote:
> > > Steve Carroll <fretwizzer@gmail.com> wrote:
> > >> On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote:
> > >>> Steve Carroll <fretwizzer@gmail.com> wrote:
> > >>> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
> > >>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> > >>> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
> > >>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> > >>> >> >
> > >>> >> > (snip)
> > >>> >> >
> > >>> >> >> >> x is never anything but a pointer.
> > >>> >> >> >
> > >>> >> >> > But it can still hold a value.
> > >>> >> >>
> > >>> >> >>
> > >>> >> >> An address value.
> > >>> >> >
> > >>> >> > I know that a var is just a place in memory that holds a value so, in this
> > >>> >> > respect, it's a pointer. But why complicate things with this additional
> > >>> >> > pointer keyword? Why the need to refer to the first char at all?
> > >>> >> >
> > >>> >> >> > For example, when I also run this with the above,
> > >>> >> >> > and placed above it...
> > >>> >> >> >
> > >>> >> >> > char *p = "test";
> > >>> >> >> > char b[] = "test";
> > >>> >> >> > printf("%c\n",*p);
> > >>> >> >> > printf("%s\n",b);
> > >>> >> >> >
> > >>> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
> > >>> >> >> >
> > >>> >> >>
> > >>> >> >> p and *p are different things. p is the address. *p is the char at
> > >>> >> >> that address.
> > >>> >> >
> > >>> >> > What I initially didn't realize (because it failed on a first run!) was this...
> > >>> >> >
> > >>> >> > char *p = "test";
> > >>> >> >
> > >>> >> > ... is simultaneously assigning the value "test to the variable 'p' and
> > >>> >> > creating a pointer to it (the first char). So this will display both :
> > >>> >> >
> > >>> >> > char *p = "test";
> > >>> >> > printf("%c\n",*p);
> > >>> >> > printf("%s\n",p);
> > >>> >> >
> > >>> >> > In any event, I get back 't' and then the entire string "test", which is, to
> > >>> >> > my way of thinking, a value, not an "address". I also noticed a pointer
> > >>> >> > has to be defined in advance, this...
> > >>> >> >
> > >>> >> > char p = "test";
> > >>> >> > printf("%c\n",*p);
> > >>> >> >
> > >>> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that
> > >>> >> > you won't always need a pointer? However, if you do decide to create
> > >>> >> > one you can assign a value to the 'pointed to' variable simultaneously,
> > >>> >> > which is handy.
> > >>> >> >
> > >>> >> >> a %s printf would print that char and all successive
> > >>> >> >> chars until it hits a '\0'.
> > >>> >> >>
> > >>> >> >>
> > >>> >> >>
> > >>> >> >> > webdev$ ./test
> > >>> >> >> > t
> > >>> >> >> > test
> > >>> >> >> > (null)
> > >>> >> >> > hello
> > >>> >> >> > hello
> > >>> >> >> >
> > >>> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank
> > >>> >> >> > line I got: '(null)'.
> > >>> >> >>
> > >>> >> >> Like I said, x is null at that point.
> > >>> >> >
> > >>> >> > I got it, but it didn't display null the first time through, just a blank line,
> > >>> >> > which was a little confusing.
> > >>> >> >
> > >>> >> >> When I run it, with the your new code placed above the old, the first
> > >>> >> >> thing that happens with stdout is the attempt to
> > >>> >> >>
> > >>> >> >> printf("%c\n",x);
> > >>> >> >>
> > >>> >> >> when x has not yet been assigned a value. That is an attempt to
> > >>> >> >> print (as a char) the null pointer x.
> > >>> >> >
> > >>> >> > As I assume most of us do, I often learn more by trying to break things,
> > >>> >> > code that runs differently on the first run slows things down a bit. What
> > >>> >> > causes that?
> > >>> >> >
> > >>> >>
> > >>> >> When trying to grasp pointers, you have to get away from the concept of
> > >>> >> strings. Pointers are addresses. Period.
> > >>> >
> > >>> > From what I've read they're 'named' addresses so, like you show below, a
> > >>> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
> > >>> >
> > >>>
> > >>> That is the address of p itself, not the address that p holds.
> > >>
> > >> Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which
> > >> is where 't' is stored. This makes sense and thanks to your other post about
> > >> printf doing what it does (yes, I know, you ran that past me several times but I
> > >> didn't understand) from the pointer on out... things are a bit more clear.
> > >>
> > >>> (See the code at the bottom).
> > >>
> > >> I've seen this, or similar, but I gotta study on these operators:
> > >> char *c=(char *)&x;
> > >>
> > >
> > > There x is an int (a 4-byte value). The code casts the address of the
> > > int to a char pointer, so you can walk the bytes of the int.
> > >
> >
> > You could also walk the ints themselves, with the int pointer,
> > and shift bits to isolate bytes:
> >
> > #include <stdio.h>
> > #include <stdlib.h>
> >
> > #define INTCOUNT 10
> >
> > int main(void)
> > {
> > int *ip;
> > int i=0;
> >
> > ip=malloc(INTCOUNT * sizeof *ip);
> > if(ip==NULL)
> > {
> > fprintf(stderr,"ip malloc failed\n");
> > exit(1);
> > }
> >
> > ip[0]=0x41424344;
> > ip[1]=0x45464748;
> > ip[2]=0x494a4b4c;
> > ip[3]=0x4d4e4f50;
> > ip[4]=0x21222324;
> > ip[5]=0x25262728;
> > ip[6]=0x292a2b2c;
> > ip[7]=0x2d2e2f30;
> > ip[8]=0x31323334;
> > ip[9]=0x35363738;
> >
> > for(i=0;i<INTCOUNT;i++)
> > {
> > printf("%c",ip[i]>>24);
> > printf("%c",ip[i]<<8>>24);
> > printf("%c",ip[i]<<16>>24);
> > printf("%c",ip[i]<<24>>24);
> > }
> > printf("\n");
> >
> > free(ip);
> > return 0;
> > }
>
>
>
> Do you have a high school diploma?
>
> Thus, my earliest statement stands literal and correct. The only undertaking that matters to Klaus Schadenfreude is arguing he is "right", and if he can't have that he will flood to effectively shout Sandman down... he's been that way forever. Klaus Schadenfreude calls it "obsessing" over him, even though he proceeds to elicit that exact rejoiner.
>
> -
> Eight things to never feed your dog!
> https://goo.gl/Fho5Nq
> https://www.facebook.com/jenny.eklund
> Jonas Eklundh Communication
I've worked in or with the computer business for 15 years. I've done business with multinational OEMs selling to governments and green technology industries. Never were we instructed to not offer any OS the customer wanted. We sold AIX, Mac, HP-UX, among others as well as Windows with no issues. Klaus Schadenfreude is a false advocate's only reason for living. The Mac has more automation options. Which just pisses Jonas 'The Shill' Eklundh off. What is Jonas 'The Shill' Eklundh's tool for the flooding nonsense? SC? That is the only database he knows, at least that I have seen. He must be abusing it to write these stupid "attack" garbage posts. My theory, Jonas 'The Shill' Eklundh took Klaus Schadenfreude's code that he pirated and declared it his... he is feeding it Klaus Schadenfreude's posts, grabbing "special" paragraphs, then re-writing those using the MaxCliqueDyn Maximum Clique algorithm and then he hand posts them because his mental health issues enables him to do that essentially constantly. Ha! Don't be insane, man... even you have plonked that moron. Given what Jonas 'The Shill' Eklundh is (and does) nobody should condemn me for working to be rid of his insane brand of flapdoodle.
--
Live on Kickstarter
http://www.5z8.info/mydick_x6g9hr_nakedgrandmas.jpg
https://groups.google.com/forum/#!topic/comp.lang.c/KDQrv8appR8
Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-10-19 00:19 -0700 |
| Message-ID | <35520c5f-489d-492b-846f-1b90af889d98@googlegroups.com> |
| In reply to | #472679 |
On Thursday, October 18, 2018 at 3:32:37 PM UTC-7, owl wrote:
> owl <owl@rooftop.invalid> wrote:
> > Steve Carroll <fretwizzer@gmail.com> wrote:
> >> On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote:
> >>> Steve Carroll <fretwizzer@gmail.com> wrote:
> >>> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
> >>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >>> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
> >>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >>> >> >
> >>> >> > (snip)
> >>> >> >
> >>> >> >> >> x is never anything but a pointer.
> >>> >> >> >
> >>> >> >> > But it can still hold a value.
> >>> >> >>
> >>> >> >>
> >>> >> >> An address value.
> >>> >> >
> >>> >> > I know that a var is just a place in memory that holds a value so, in this
> >>> >> > respect, it's a pointer. But why complicate things with this additional
> >>> >> > pointer keyword? Why the need to refer to the first char at all?
> >>> >> >
> >>> >> >> > For example, when I also run this with the above,
> >>> >> >> > and placed above it...
> >>> >> >> >
> >>> >> >> > char *p = "test";
> >>> >> >> > char b[] = "test";
> >>> >> >> > printf("%c\n",*p);
> >>> >> >> > printf("%s\n",b);
> >>> >> >> >
> >>> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
> >>> >> >> >
> >>> >> >>
> >>> >> >> p and *p are different things. p is the address. *p is the char at
> >>> >> >> that address.
> >>> >> >
> >>> >> > What I initially didn't realize (because it failed on a first run!) was this...
> >>> >> >
> >>> >> > char *p = "test";
> >>> >> >
> >>> >> > ... is simultaneously assigning the value "test to the variable 'p' and
> >>> >> > creating a pointer to it (the first char). So this will display both :
> >>> >> >
> >>> >> > char *p = "test";
> >>> >> > printf("%c\n",*p);
> >>> >> > printf("%s\n",p);
> >>> >> >
> >>> >> > In any event, I get back 't' and then the entire string "test", which is, to
> >>> >> > my way of thinking, a value, not an "address". I also noticed a pointer
> >>> >> > has to be defined in advance, this...
> >>> >> >
> >>> >> > char p = "test";
> >>> >> > printf("%c\n",*p);
> >>> >> >
> >>> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that
> >>> >> > you won't always need a pointer? However, if you do decide to create
> >>> >> > one you can assign a value to the 'pointed to' variable simultaneously,
> >>> >> > which is handy.
> >>> >> >
> >>> >> >> a %s printf would print that char and all successive
> >>> >> >> chars until it hits a '\0'.
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >> > webdev$ ./test
> >>> >> >> > t
> >>> >> >> > test
> >>> >> >> > (null)
> >>> >> >> > hello
> >>> >> >> > hello
> >>> >> >> >
> >>> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank
> >>> >> >> > line I got: '(null)'.
> >>> >> >>
> >>> >> >> Like I said, x is null at that point.
> >>> >> >
> >>> >> > I got it, but it didn't display null the first time through, just a blank line,
> >>> >> > which was a little confusing.
> >>> >> >
> >>> >> >> When I run it, with the your new code placed above the old, the first
> >>> >> >> thing that happens with stdout is the attempt to
> >>> >> >>
> >>> >> >> printf("%c\n",x);
> >>> >> >>
> >>> >> >> when x has not yet been assigned a value. That is an attempt to
> >>> >> >> print (as a char) the null pointer x.
> >>> >> >
> >>> >> > As I assume most of us do, I often learn more by trying to break things,
> >>> >> > code that runs differently on the first run slows things down a bit. What
> >>> >> > causes that?
> >>> >> >
> >>> >>
> >>> >> When trying to grasp pointers, you have to get away from the concept of
> >>> >> strings. Pointers are addresses. Period.
> >>> >
> >>> > From what I've read they're 'named' addresses so, like you show below, a
> >>> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
> >>> >
> >>>
> >>> That is the address of p itself, not the address that p holds.
> >>
> >> Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which
> >> is where 't' is stored. This makes sense and thanks to your other post about
> >> printf doing what it does (yes, I know, you ran that past me several times but I
> >> didn't understand) from the pointer on out... things are a bit more clear.
> >>
> >>> (See the code at the bottom).
> >>
> >> I've seen this, or similar, but I gotta study on these operators:
> >> char *c=(char *)&x;
> >>
> >
> > There x is an int (a 4-byte value). The code casts the address of the
> > int to a char pointer, so you can walk the bytes of the int.
> >
>
> You could also walk the ints themselves, with the int pointer,
> and shift bits to isolate bytes:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> #define INTCOUNT 10
>
> int main(void)
> {
> int *ip;
> int i=0;
>
> ip=malloc(INTCOUNT * sizeof *ip);
> if(ip==NULL)
> {
> fprintf(stderr,"ip malloc failed\n");
> exit(1);
> }
>
> ip[0]=0x41424344;
> ip[1]=0x45464748;
> ip[2]=0x494a4b4c;
> ip[3]=0x4d4e4f50;
> ip[4]=0x21222324;
> ip[5]=0x25262728;
> ip[6]=0x292a2b2c;
> ip[7]=0x2d2e2f30;
> ip[8]=0x31323334;
> ip[9]=0x35363738;
>
> for(i=0;i<INTCOUNT;i++)
> {
> printf("%c",ip[i]>>24);
> printf("%c",ip[i]<<8>>24);
> printf("%c",ip[i]<<16>>24);
> printf("%c",ip[i]<<24>>24);
> }
> printf("\n");
>
> free(ip);
> return 0;
> }
Steve "Steven Petruzzellis" Carroll's obsession with flatfish+++ started in 2004 when Carroll got mad about his then girlfriend obsessing over flatfish+++ (heavily documented here: <http://tinyurl.com/proof-about-ebot>). flatfish+++ continued to respond to Steve for about 5 years, when Steve flipped out in 2009 and started contacting flatfish+++'s employer with the stated goal to have him fired (he spoke of doing so even if he had to twist arms):
<http://goo.gl/OHNryA>
<http://goo.gl/MZ6yCD>
<http://goo.gl/WaKKGq>
There were more, but Carroll has had them deleted from the Google archive. I have not spent the time to find them elsewhere (and likely will not).
With that flatfish+++ stopped responding directly to Steve except for *one* chance he gave him in 2011 when Steve was accusing *flatfish+++* of running: <http://goo.gl/racU64>.
Carroll, as predicted, ran (he always does when faced with facts):
<http://goo.gl/qHs5Xh>
Steven Petruzzellis knows he has no backing for any of his nonsense and has become, if anything, more and more obsessive since flatfish+++ stopped responding to him.
Steve "Steven Petruzzellis" Carroll is truly a very, very sick man.
--
I Left My Husband & Daughter At Home And THIS happened!!
https://www.youtube.com/watch?v=AglvCo3dJ38&feature=youtu.be
https://youtu.be/BUjnZhKk1Bg
Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <fretwizzer@gmail.com> |
|---|---|
| Date | 2018-10-19 09:24 -0700 |
| Message-ID | <3e1a636c-736a-49c3-8ed2-eed3017f0cc3@googlegroups.com> |
| In reply to | #472679 |
On Thursday, October 18, 2018 at 4:32:37 PM UTC-6, owl wrote:
> owl <owl@rooftop.invalid> wrote:
> > Steve Carroll <fretwizzer@gmail.com> wrote:
> >> On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote:
> >>> Steve Carroll <fretwizzer@gmail.com> wrote:
> >>> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
> >>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >>> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
> >>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >>> >> >
> >>> >> > (snip)
> >>> >> >
> >>> >> >> >> x is never anything but a pointer.
> >>> >> >> >
> >>> >> >> > But it can still hold a value.
> >>> >> >>
> >>> >> >>
> >>> >> >> An address value.
> >>> >> >
> >>> >> > I know that a var is just a place in memory that holds a value so, in this
> >>> >> > respect, it's a pointer. But why complicate things with this additional
> >>> >> > pointer keyword? Why the need to refer to the first char at all?
> >>> >> >
> >>> >> >> > For example, when I also run this with the above,
> >>> >> >> > and placed above it...
> >>> >> >> >
> >>> >> >> > char *p = "test";
> >>> >> >> > char b[] = "test";
> >>> >> >> > printf("%c\n",*p);
> >>> >> >> > printf("%s\n",b);
> >>> >> >> >
> >>> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
> >>> >> >> >
> >>> >> >>
> >>> >> >> p and *p are different things. p is the address. *p is the char at
> >>> >> >> that address.
> >>> >> >
> >>> >> > What I initially didn't realize (because it failed on a first run!) was this...
> >>> >> >
> >>> >> > char *p = "test";
> >>> >> >
> >>> >> > ... is simultaneously assigning the value "test to the variable 'p' and
> >>> >> > creating a pointer to it (the first char). So this will display both :
> >>> >> >
> >>> >> > char *p = "test";
> >>> >> > printf("%c\n",*p);
> >>> >> > printf("%s\n",p);
> >>> >> >
> >>> >> > In any event, I get back 't' and then the entire string "test", which is, to
> >>> >> > my way of thinking, a value, not an "address". I also noticed a pointer
> >>> >> > has to be defined in advance, this...
> >>> >> >
> >>> >> > char p = "test";
> >>> >> > printf("%c\n",*p);
> >>> >> >
> >>> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that
> >>> >> > you won't always need a pointer? However, if you do decide to create
> >>> >> > one you can assign a value to the 'pointed to' variable simultaneously,
> >>> >> > which is handy.
> >>> >> >
> >>> >> >> a %s printf would print that char and all successive
> >>> >> >> chars until it hits a '\0'.
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >> > webdev$ ./test
> >>> >> >> > t
> >>> >> >> > test
> >>> >> >> > (null)
> >>> >> >> > hello
> >>> >> >> > hello
> >>> >> >> >
> >>> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank
> >>> >> >> > line I got: '(null)'.
> >>> >> >>
> >>> >> >> Like I said, x is null at that point.
> >>> >> >
> >>> >> > I got it, but it didn't display null the first time through, just a blank line,
> >>> >> > which was a little confusing.
> >>> >> >
> >>> >> >> When I run it, with the your new code placed above the old, the first
> >>> >> >> thing that happens with stdout is the attempt to
> >>> >> >>
> >>> >> >> printf("%c\n",x);
> >>> >> >>
> >>> >> >> when x has not yet been assigned a value. That is an attempt to
> >>> >> >> print (as a char) the null pointer x.
> >>> >> >
> >>> >> > As I assume most of us do, I often learn more by trying to break things,
> >>> >> > code that runs differently on the first run slows things down a bit. What
> >>> >> > causes that?
> >>> >> >
> >>> >>
> >>> >> When trying to grasp pointers, you have to get away from the concept of
> >>> >> strings. Pointers are addresses. Period.
> >>> >
> >>> > From what I've read they're 'named' addresses so, like you show below, a
> >>> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
> >>> >
> >>>
> >>> That is the address of p itself, not the address that p holds.
> >>
> >> Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which
> >> is where 't' is stored. This makes sense and thanks to your other post about
> >> printf doing what it does (yes, I know, you ran that past me several times but I
> >> didn't understand) from the pointer on out... things are a bit more clear.
> >>
> >>> (See the code at the bottom).
> >>
> >> I've seen this, or similar, but I gotta study on these operators:
> >> char *c=(char *)&x;
> >>
> >
> > There x is an int (a 4-byte value). The code casts the address of the
> > int to a char pointer, so you can walk the bytes of the int.
> >
>
> You could also walk the ints themselves, with the int pointer,
> and shift bits to isolate bytes:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> #define INTCOUNT 10
>
> int main(void)
> {
> int *ip;
> int i=0;
>
> ip=malloc(INTCOUNT * sizeof *ip);
> if(ip==NULL)
> {
> fprintf(stderr,"ip malloc failed\n");
> exit(1);
> }
>
> ip[0]=0x41424344;
> ip[1]=0x45464748;
> ip[2]=0x494a4b4c;
> ip[3]=0x4d4e4f50;
> ip[4]=0x21222324;
> ip[5]=0x25262728;
> ip[6]=0x292a2b2c;
> ip[7]=0x2d2e2f30;
> ip[8]=0x31323334;
> ip[9]=0x35363738;
>
> for(i=0;i<INTCOUNT;i++)
> {
> printf("%c",ip[i]>>24);
> printf("%c",ip[i]<<8>>24);
> printf("%c",ip[i]<<16>>24);
> printf("%c",ip[i]<<24>>24);
> }
> printf("\n");
>
> free(ip);
> return 0;
> }
I've been reading from that site you gave me a link to, which is helping.
Thanks for all this stuff you're posting, too. It may take awhile 'cuz I don't
have a lot of time right now but I'll get better.
[toc] | [prev] | [next] | [standalone]
| From | Hadron Quark <hadronquark@gmail.com> |
|---|---|
| Date | 2018-10-19 19:16 +0200 |
| Message-ID | <87d0s5dfh1.fsf@gmail.com> |
| In reply to | #472760 |
Steve Carroll <fretwizzer@gmail.com> writes:
> On Thursday, October 18, 2018 at 4:32:37 PM UTC-6, owl wrote:
>> owl <owl@rooftop.invalid> wrote:
>> > Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote:
>> >>> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >>> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
>> >>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >>> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
>> >>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >>> >> >
>> >>> >> > (snip)
>> >>> >> >
>> >>> >> >> >> x is never anything but a pointer.
>> >>> >> >> >
>> >>> >> >> > But it can still hold a value.
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> An address value.
>> >>> >> >
>> >>> >> > I know that a var is just a place in memory that holds a value so, in this
>> >>> >> > respect, it's a pointer. But why complicate things with this additional
>> >>> >> > pointer keyword? Why the need to refer to the first char at all?
>> >>> >> >
>> >>> >> >> > For example, when I also run this with the above,
>> >>> >> >> > and placed above it...
>> >>> >> >> >
>> >>> >> >> > char *p = "test";
>> >>> >> >> > char b[] = "test";
>> >>> >> >> > printf("%c\n",*p);
>> >>> >> >> > printf("%s\n",b);
>> >>> >> >> >
>> >>> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
>> >>> >> >> >
>> >>> >> >>
>> >>> >> >> p and *p are different things. p is the address. *p is the char at
>> >>> >> >> that address.
>> >>> >> >
>> >>> >> > What I initially didn't realize (because it failed on a first run!) was this...
>> >>> >> >
>> >>> >> > char *p = "test";
>> >>> >> >
>> >>> >> > ... is simultaneously assigning the value "test to the variable 'p' and
>> >>> >> > creating a pointer to it (the first char). So this will display both :
>> >>> >> >
>> >>> >> > char *p = "test";
>> >>> >> > printf("%c\n",*p);
>> >>> >> > printf("%s\n",p);
>> >>> >> >
>> >>> >> > In any event, I get back 't' and then the entire string "test", which is, to
>> >>> >> > my way of thinking, a value, not an "address". I also noticed a pointer
>> >>> >> > has to be defined in advance, this...
>> >>> >> >
>> >>> >> > char p = "test";
>> >>> >> > printf("%c\n",*p);
>> >>> >> >
>> >>> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that
>> >>> >> > you won't always need a pointer? However, if you do decide to create
>> >>> >> > one you can assign a value to the 'pointed to' variable simultaneously,
>> >>> >> > which is handy.
>> >>> >> >
>> >>> >> >> a %s printf would print that char and all successive
>> >>> >> >> chars until it hits a '\0'.
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> > webdev$ ./test
>> >>> >> >> > t
>> >>> >> >> > test
>> >>> >> >> > (null)
>> >>> >> >> > hello
>> >>> >> >> > hello
>> >>> >> >> >
>> >>> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank
>> >>> >> >> > line I got: '(null)'.
>> >>> >> >>
>> >>> >> >> Like I said, x is null at that point.
>> >>> >> >
>> >>> >> > I got it, but it didn't display null the first time through, just a blank line,
>> >>> >> > which was a little confusing.
>> >>> >> >
>> >>> >> >> When I run it, with the your new code placed above the old, the first
>> >>> >> >> thing that happens with stdout is the attempt to
>> >>> >> >>
>> >>> >> >> printf("%c\n",x);
>> >>> >> >>
>> >>> >> >> when x has not yet been assigned a value. That is an attempt to
>> >>> >> >> print (as a char) the null pointer x.
>> >>> >> >
>> >>> >> > As I assume most of us do, I often learn more by trying to break things,
>> >>> >> > code that runs differently on the first run slows things down a bit. What
>> >>> >> > causes that?
>> >>> >> >
>> >>> >>
>> >>> >> When trying to grasp pointers, you have to get away from the concept of
>> >>> >> strings. Pointers are addresses. Period.
>> >>> >
>> >>> > From what I've read they're 'named' addresses so, like you show below, a
>> >>> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
>> >>> >
>> >>>
>> >>> That is the address of p itself, not the address that p holds.
>> >>
>> >> Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which
>> >> is where 't' is stored. This makes sense and thanks to your other post about
>> >> printf doing what it does (yes, I know, you ran that past me several times but I
>> >> didn't understand) from the pointer on out... things are a bit more clear.
>> >>
>> >>> (See the code at the bottom).
>> >>
>> >> I've seen this, or similar, but I gotta study on these operators:
>> >> char *c=(char *)&x;
>> >>
>> >
>> > There x is an int (a 4-byte value). The code casts the address of the
>> > int to a char pointer, so you can walk the bytes of the int.
>> >
>>
>> You could also walk the ints themselves, with the int pointer,
>> and shift bits to isolate bytes:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> #define INTCOUNT 10
>>
>> int main(void)
>> {
>> int *ip;
>> int i=0;
>>
>> ip=malloc(INTCOUNT * sizeof *ip);
>> if(ip==NULL)
>> {
>> fprintf(stderr,"ip malloc failed\n");
>> exit(1);
>> }
>>
>> ip[0]=0x41424344;
>> ip[1]=0x45464748;
>> ip[2]=0x494a4b4c;
>> ip[3]=0x4d4e4f50;
>> ip[4]=0x21222324;
>> ip[5]=0x25262728;
>> ip[6]=0x292a2b2c;
>> ip[7]=0x2d2e2f30;
>> ip[8]=0x31323334;
>> ip[9]=0x35363738;
>>
>> for(i=0;i<INTCOUNT;i++)
>> {
>> printf("%c",ip[i]>>24);
>> printf("%c",ip[i]<<8>>24);
>> printf("%c",ip[i]<<16>>24);
>> printf("%c",ip[i]<<24>>24);
>> }
>> printf("\n");
>>
>> free(ip);
>> return 0;
>> }
>
> I've been reading from that site you gave me a link to, which is helping.
> Thanks for all this stuff you're posting, too. It may take awhile 'cuz I don't
> have a lot of time right now but I'll get better.
Array name and pointer interchangeable in C.
,----
| int arrInts[10];
`----
You can then use sizeof() if you want to be 1337 and confuse people..
,----
| elements= sizeof(arrInts) / sizeof(arrInts[0])
`----
But do NOT use sizeof if you pass your array (pointer) to a
functions.... sizeof(p) will be the sizeof of the int * pointer.
--
chrisv alias turdv is a turd
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <fretwizzer@gmail.com> |
|---|---|
| Date | 2018-10-19 10:30 -0700 |
| Message-ID | <6964c188-1952-484f-89a4-4c4dc702a303@googlegroups.com> |
| In reply to | #472768 |
On Friday, October 19, 2018 at 11:16:29 AM UTC-6, Hadron Quark wrote:
> Steve Carroll <fretwizzer@gmail.com> writes:
>
> > On Thursday, October 18, 2018 at 4:32:37 PM UTC-6, owl wrote:
> >> owl <owl@rooftop.invalid> wrote:
> >> > Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote:
> >> >>> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >>> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
> >> >>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >>> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
> >> >>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >>> >> >
> >> >>> >> > (snip)
> >> >>> >> >
> >> >>> >> >> >> x is never anything but a pointer.
> >> >>> >> >> >
> >> >>> >> >> > But it can still hold a value.
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >> An address value.
> >> >>> >> >
> >> >>> >> > I know that a var is just a place in memory that holds a value so, in this
> >> >>> >> > respect, it's a pointer. But why complicate things with this additional
> >> >>> >> > pointer keyword? Why the need to refer to the first char at all?
> >> >>> >> >
> >> >>> >> >> > For example, when I also run this with the above,
> >> >>> >> >> > and placed above it...
> >> >>> >> >> >
> >> >>> >> >> > char *p = "test";
> >> >>> >> >> > char b[] = "test";
> >> >>> >> >> > printf("%c\n",*p);
> >> >>> >> >> > printf("%s\n",b);
> >> >>> >> >> >
> >> >>> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
> >> >>> >> >> >
> >> >>> >> >>
> >> >>> >> >> p and *p are different things. p is the address. *p is the char at
> >> >>> >> >> that address.
> >> >>> >> >
> >> >>> >> > What I initially didn't realize (because it failed on a first run!) was this...
> >> >>> >> >
> >> >>> >> > char *p = "test";
> >> >>> >> >
> >> >>> >> > ... is simultaneously assigning the value "test to the variable 'p' and
> >> >>> >> > creating a pointer to it (the first char). So this will display both :
> >> >>> >> >
> >> >>> >> > char *p = "test";
> >> >>> >> > printf("%c\n",*p);
> >> >>> >> > printf("%s\n",p);
> >> >>> >> >
> >> >>> >> > In any event, I get back 't' and then the entire string "test", which is, to
> >> >>> >> > my way of thinking, a value, not an "address". I also noticed a pointer
> >> >>> >> > has to be defined in advance, this...
> >> >>> >> >
> >> >>> >> > char p = "test";
> >> >>> >> > printf("%c\n",*p);
> >> >>> >> >
> >> >>> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that
> >> >>> >> > you won't always need a pointer? However, if you do decide to create
> >> >>> >> > one you can assign a value to the 'pointed to' variable simultaneously,
> >> >>> >> > which is handy.
> >> >>> >> >
> >> >>> >> >> a %s printf would print that char and all successive
> >> >>> >> >> chars until it hits a '\0'.
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >> > webdev$ ./test
> >> >>> >> >> > t
> >> >>> >> >> > test
> >> >>> >> >> > (null)
> >> >>> >> >> > hello
> >> >>> >> >> > hello
> >> >>> >> >> >
> >> >>> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank
> >> >>> >> >> > line I got: '(null)'.
> >> >>> >> >>
> >> >>> >> >> Like I said, x is null at that point.
> >> >>> >> >
> >> >>> >> > I got it, but it didn't display null the first time through, just a blank line,
> >> >>> >> > which was a little confusing.
> >> >>> >> >
> >> >>> >> >> When I run it, with the your new code placed above the old, the first
> >> >>> >> >> thing that happens with stdout is the attempt to
> >> >>> >> >>
> >> >>> >> >> printf("%c\n",x);
> >> >>> >> >>
> >> >>> >> >> when x has not yet been assigned a value. That is an attempt to
> >> >>> >> >> print (as a char) the null pointer x.
> >> >>> >> >
> >> >>> >> > As I assume most of us do, I often learn more by trying to break things,
> >> >>> >> > code that runs differently on the first run slows things down a bit. What
> >> >>> >> > causes that?
> >> >>> >> >
> >> >>> >>
> >> >>> >> When trying to grasp pointers, you have to get away from the concept of
> >> >>> >> strings. Pointers are addresses. Period.
> >> >>> >
> >> >>> > From what I've read they're 'named' addresses so, like you show below, a
> >> >>> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
> >> >>> >
> >> >>>
> >> >>> That is the address of p itself, not the address that p holds.
> >> >>
> >> >> Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which
> >> >> is where 't' is stored. This makes sense and thanks to your other post about
> >> >> printf doing what it does (yes, I know, you ran that past me several times but I
> >> >> didn't understand) from the pointer on out... things are a bit more clear.
> >> >>
> >> >>> (See the code at the bottom).
> >> >>
> >> >> I've seen this, or similar, but I gotta study on these operators:
> >> >> char *c=(char *)&x;
> >> >>
> >> >
> >> > There x is an int (a 4-byte value). The code casts the address of the
> >> > int to a char pointer, so you can walk the bytes of the int.
> >> >
> >>
> >> You could also walk the ints themselves, with the int pointer,
> >> and shift bits to isolate bytes:
> >>
> >> #include <stdio.h>
> >> #include <stdlib.h>
> >>
> >> #define INTCOUNT 10
> >>
> >> int main(void)
> >> {
> >> int *ip;
> >> int i=0;
> >>
> >> ip=malloc(INTCOUNT * sizeof *ip);
> >> if(ip==NULL)
> >> {
> >> fprintf(stderr,"ip malloc failed\n");
> >> exit(1);
> >> }
> >>
> >> ip[0]=0x41424344;
> >> ip[1]=0x45464748;
> >> ip[2]=0x494a4b4c;
> >> ip[3]=0x4d4e4f50;
> >> ip[4]=0x21222324;
> >> ip[5]=0x25262728;
> >> ip[6]=0x292a2b2c;
> >> ip[7]=0x2d2e2f30;
> >> ip[8]=0x31323334;
> >> ip[9]=0x35363738;
> >>
> >> for(i=0;i<INTCOUNT;i++)
> >> {
> >> printf("%c",ip[i]>>24);
> >> printf("%c",ip[i]<<8>>24);
> >> printf("%c",ip[i]<<16>>24);
> >> printf("%c",ip[i]<<24>>24);
> >> }
> >> printf("\n");
> >>
> >> free(ip);
> >> return 0;
> >> }
> >
> > I've been reading from that site you gave me a link to, which is helping.
> > Thanks for all this stuff you're posting, too. It may take awhile 'cuz I don't
> > have a lot of time right now but I'll get better.
>
>
> Array name and pointer interchangeable in C.
>
> ,----
> | int arrInts[10];
> `----
>
> You can then use sizeof() if you want to be 1337 and confuse people..
I gotta get to 1115 first.
>
> ,----
> | elements= sizeof(arrInts) / sizeof(arrInts[0])
> `----
>
> But do NOT use sizeof if you pass your array (pointer) to a
> functions.... sizeof(p) will be the sizeof of the int * pointer.
That... and something about dereferencing Null pointers... all Greek to me ;)
[toc] | [prev] | [next] | [standalone]
| From | Hadron Quark <hadronquark@gmail.com> |
|---|---|
| Date | 2018-10-19 22:34 +0200 |
| Message-ID | <878t2td6bk.fsf@gmail.com> |
| In reply to | #472771 |
Steve Carroll <fretwizzer@gmail.com> writes:
> On Friday, October 19, 2018 at 11:16:29 AM UTC-6, Hadron Quark wrote:
>> Steve Carroll <fretwizzer@gmail.com> writes:
>>
>> > On Thursday, October 18, 2018 at 4:32:37 PM UTC-6, owl wrote:
>> >> owl <owl@rooftop.invalid> wrote:
>> >> > Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> >> On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote:
>> >> >>> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> >>> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
>> >> >>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> >>> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
>> >> >>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> >>> >> >
>> >> >>> >> > (snip)
>> >> >>> >> >
>> >> >>> >> >> >> x is never anything but a pointer.
>> >> >>> >> >> >
>> >> >>> >> >> > But it can still hold a value.
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >> An address value.
>> >> >>> >> >
>> >> >>> >> > I know that a var is just a place in memory that holds a value so, in this
>> >> >>> >> > respect, it's a pointer. But why complicate things with this additional
>> >> >>> >> > pointer keyword? Why the need to refer to the first char at all?
>> >> >>> >> >
>> >> >>> >> >> > For example, when I also run this with the above,
>> >> >>> >> >> > and placed above it...
>> >> >>> >> >> >
>> >> >>> >> >> > char *p = "test";
>> >> >>> >> >> > char b[] = "test";
>> >> >>> >> >> > printf("%c\n",*p);
>> >> >>> >> >> > printf("%s\n",b);
>> >> >>> >> >> >
>> >> >>> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
>> >> >>> >> >> >
>> >> >>> >> >>
>> >> >>> >> >> p and *p are different things. p is the address. *p is the char at
>> >> >>> >> >> that address.
>> >> >>> >> >
>> >> >>> >> > What I initially didn't realize (because it failed on a first run!) was this...
>> >> >>> >> >
>> >> >>> >> > char *p = "test";
>> >> >>> >> >
>> >> >>> >> > ... is simultaneously assigning the value "test to the variable 'p' and
>> >> >>> >> > creating a pointer to it (the first char). So this will display both :
>> >> >>> >> >
>> >> >>> >> > char *p = "test";
>> >> >>> >> > printf("%c\n",*p);
>> >> >>> >> > printf("%s\n",p);
>> >> >>> >> >
>> >> >>> >> > In any event, I get back 't' and then the entire string "test", which is, to
>> >> >>> >> > my way of thinking, a value, not an "address". I also noticed a pointer
>> >> >>> >> > has to be defined in advance, this...
>> >> >>> >> >
>> >> >>> >> > char p = "test";
>> >> >>> >> > printf("%c\n",*p);
>> >> >>> >> >
>> >> >>> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that
>> >> >>> >> > you won't always need a pointer? However, if you do decide to create
>> >> >>> >> > one you can assign a value to the 'pointed to' variable simultaneously,
>> >> >>> >> > which is handy.
>> >> >>> >> >
>> >> >>> >> >> a %s printf would print that char and all successive
>> >> >>> >> >> chars until it hits a '\0'.
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >> > webdev$ ./test
>> >> >>> >> >> > t
>> >> >>> >> >> > test
>> >> >>> >> >> > (null)
>> >> >>> >> >> > hello
>> >> >>> >> >> > hello
>> >> >>> >> >> >
>> >> >>> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank
>> >> >>> >> >> > line I got: '(null)'.
>> >> >>> >> >>
>> >> >>> >> >> Like I said, x is null at that point.
>> >> >>> >> >
>> >> >>> >> > I got it, but it didn't display null the first time through, just a blank line,
>> >> >>> >> > which was a little confusing.
>> >> >>> >> >
>> >> >>> >> >> When I run it, with the your new code placed above the old, the first
>> >> >>> >> >> thing that happens with stdout is the attempt to
>> >> >>> >> >>
>> >> >>> >> >> printf("%c\n",x);
>> >> >>> >> >>
>> >> >>> >> >> when x has not yet been assigned a value. That is an attempt to
>> >> >>> >> >> print (as a char) the null pointer x.
>> >> >>> >> >
>> >> >>> >> > As I assume most of us do, I often learn more by trying to break things,
>> >> >>> >> > code that runs differently on the first run slows things down a bit. What
>> >> >>> >> > causes that?
>> >> >>> >> >
>> >> >>> >>
>> >> >>> >> When trying to grasp pointers, you have to get away from the concept of
>> >> >>> >> strings. Pointers are addresses. Period.
>> >> >>> >
>> >> >>> > From what I've read they're 'named' addresses so, like you show below, a
>> >> >>> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
>> >> >>> >
>> >> >>>
>> >> >>> That is the address of p itself, not the address that p holds.
>> >> >>
>> >> >> Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which
>> >> >> is where 't' is stored. This makes sense and thanks to your other post about
>> >> >> printf doing what it does (yes, I know, you ran that past me several times but I
>> >> >> didn't understand) from the pointer on out... things are a bit more clear.
>> >> >>
>> >> >>> (See the code at the bottom).
>> >> >>
>> >> >> I've seen this, or similar, but I gotta study on these operators:
>> >> >> char *c=(char *)&x;
>> >> >>
>> >> >
>> >> > There x is an int (a 4-byte value). The code casts the address of the
>> >> > int to a char pointer, so you can walk the bytes of the int.
>> >> >
>> >>
>> >> You could also walk the ints themselves, with the int pointer,
>> >> and shift bits to isolate bytes:
>> >>
>> >> #include <stdio.h>
>> >> #include <stdlib.h>
>> >>
>> >> #define INTCOUNT 10
>> >>
>> >> int main(void)
>> >> {
>> >> int *ip;
>> >> int i=0;
>> >>
>> >> ip=malloc(INTCOUNT * sizeof *ip);
>> >> if(ip==NULL)
>> >> {
>> >> fprintf(stderr,"ip malloc failed\n");
>> >> exit(1);
>> >> }
>> >>
>> >> ip[0]=0x41424344;
>> >> ip[1]=0x45464748;
>> >> ip[2]=0x494a4b4c;
>> >> ip[3]=0x4d4e4f50;
>> >> ip[4]=0x21222324;
>> >> ip[5]=0x25262728;
>> >> ip[6]=0x292a2b2c;
>> >> ip[7]=0x2d2e2f30;
>> >> ip[8]=0x31323334;
>> >> ip[9]=0x35363738;
>> >>
>> >> for(i=0;i<INTCOUNT;i++)
>> >> {
>> >> printf("%c",ip[i]>>24);
>> >> printf("%c",ip[i]<<8>>24);
>> >> printf("%c",ip[i]<<16>>24);
>> >> printf("%c",ip[i]<<24>>24);
>> >> }
>> >> printf("\n");
>> >>
>> >> free(ip);
>> >> return 0;
>> >> }
>> >
>> > I've been reading from that site you gave me a link to, which is helping.
>> > Thanks for all this stuff you're posting, too. It may take awhile 'cuz I don't
>> > have a lot of time right now but I'll get better.
>>
>>
>> Array name and pointer interchangeable in C.
>>
>> ,----
>> | int arrInts[10];
>> `----
>>
>> You can then use sizeof() if you want to be 1337 and confuse people..
>
> I gotta get to 1115 first.
>
>>
>> ,----
>> | elements= sizeof(arrInts) / sizeof(arrInts[0])
>> `----
>>
>> But do NOT use sizeof if you pass your array (pointer) to a
>> functions.... sizeof(p) will be the sizeof of the int * pointer.
>
> That... and something about dereferencing Null pointers... all Greek to me ;)
>
Understand that a null pointer is effectively pointing at
"nothing". Undefined behaviour. A pointer can point to an empty string
though : the first char is nul... ;) An empty string is not the same as
a null pointer.
maybe ok C code (ie C not run through a check)
,----
| char *p=NULL; /* ALWAYS initialise pointers to NULL explicitly. Peace
| of mind */
| char *myString="hello";
| char *myString2="";
| char c;
| c= *p; /*bang ; can't dereference a NULL pointer*/
| p=myString;
| c=*p; /* c='h' */
| p=myString2;
| c=*p; /* c=nul */
`----
--
chrisv alias turdv is a turd
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-10-19 13:51 -0700 |
| Message-ID | <c06189a2-6740-46f4-a9ee-b90bdc5b6970@googlegroups.com> |
| In reply to | #472791 |
On Friday, October 19, 2018 at 1:34:09 PM UTC-7, Hadron Quark wrote:
> Steve Carroll <fretwizzer@gmail.com> writes:
>
> > On Friday, October 19, 2018 at 11:16:29 AM UTC-6, Hadron Quark wrote:
> >> Steve Carroll <fretwizzer@gmail.com> writes:
> >>
> >> > On Thursday, October 18, 2018 at 4:32:37 PM UTC-6, owl wrote:
> >> >> owl <owl@rooftop.invalid> wrote:
> >> >> > Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> >> On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote:
> >> >> >>> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> >>> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
> >> >> >>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> >>> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
> >> >> >>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> >>> >> >
> >> >> >>> >> > (snip)
> >> >> >>> >> >
> >> >> >>> >> >> >> x is never anything but a pointer.
> >> >> >>> >> >> >
> >> >> >>> >> >> > But it can still hold a value.
> >> >> >>> >> >>
> >> >> >>> >> >>
> >> >> >>> >> >> An address value.
> >> >> >>> >> >
> >> >> >>> >> > I know that a var is just a place in memory that holds a value so, in this
> >> >> >>> >> > respect, it's a pointer. But why complicate things with this additional
> >> >> >>> >> > pointer keyword? Why the need to refer to the first char at all?
> >> >> >>> >> >
> >> >> >>> >> >> > For example, when I also run this with the above,
> >> >> >>> >> >> > and placed above it...
> >> >> >>> >> >> >
> >> >> >>> >> >> > char *p = "test";
> >> >> >>> >> >> > char b[] = "test";
> >> >> >>> >> >> > printf("%c\n",*p);
> >> >> >>> >> >> > printf("%s\n",b);
> >> >> >>> >> >> >
> >> >> >>> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
> >> >> >>> >> >> >
> >> >> >>> >> >>
> >> >> >>> >> >> p and *p are different things. p is the address. *p is the char at
> >> >> >>> >> >> that address.
> >> >> >>> >> >
> >> >> >>> >> > What I initially didn't realize (because it failed on a first run!) was this...
> >> >> >>> >> >
> >> >> >>> >> > char *p = "test";
> >> >> >>> >> >
> >> >> >>> >> > ... is simultaneously assigning the value "test to the variable 'p' and
> >> >> >>> >> > creating a pointer to it (the first char). So this will display both :
> >> >> >>> >> >
> >> >> >>> >> > char *p = "test";
> >> >> >>> >> > printf("%c\n",*p);
> >> >> >>> >> > printf("%s\n",p);
> >> >> >>> >> >
> >> >> >>> >> > In any event, I get back 't' and then the entire string "test", which is, to
> >> >> >>> >> > my way of thinking, a value, not an "address". I also noticed a pointer
> >> >> >>> >> > has to be defined in advance, this...
> >> >> >>> >> >
> >> >> >>> >> > char p = "test";
> >> >> >>> >> > printf("%c\n",*p);
> >> >> >>> >> >
> >> >> >>> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that
> >> >> >>> >> > you won't always need a pointer? However, if you do decide to create
> >> >> >>> >> > one you can assign a value to the 'pointed to' variable simultaneously,
> >> >> >>> >> > which is handy.
> >> >> >>> >> >
> >> >> >>> >> >> a %s printf would print that char and all successive
> >> >> >>> >> >> chars until it hits a '\0'.
> >> >> >>> >> >>
> >> >> >>> >> >>
> >> >> >>> >> >>
> >> >> >>> >> >> > webdev$ ./test
> >> >> >>> >> >> > t
> >> >> >>> >> >> > test
> >> >> >>> >> >> > (null)
> >> >> >>> >> >> > hello
> >> >> >>> >> >> > hello
> >> >> >>> >> >> >
> >> >> >>> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank
> >> >> >>> >> >> > line I got: '(null)'.
> >> >> >>> >> >>
> >> >> >>> >> >> Like I said, x is null at that point.
> >> >> >>> >> >
> >> >> >>> >> > I got it, but it didn't display null the first time through, just a blank line,
> >> >> >>> >> > which was a little confusing.
> >> >> >>> >> >
> >> >> >>> >> >> When I run it, with the your new code placed above the old, the first
> >> >> >>> >> >> thing that happens with stdout is the attempt to
> >> >> >>> >> >>
> >> >> >>> >> >> printf("%c\n",x);
> >> >> >>> >> >>
> >> >> >>> >> >> when x has not yet been assigned a value. That is an attempt to
> >> >> >>> >> >> print (as a char) the null pointer x.
> >> >> >>> >> >
> >> >> >>> >> > As I assume most of us do, I often learn more by trying to break things,
> >> >> >>> >> > code that runs differently on the first run slows things down a bit. What
> >> >> >>> >> > causes that?
> >> >> >>> >> >
> >> >> >>> >>
> >> >> >>> >> When trying to grasp pointers, you have to get away from the concept of
> >> >> >>> >> strings. Pointers are addresses. Period.
> >> >> >>> >
> >> >> >>> > From what I've read they're 'named' addresses so, like you show below, a
> >> >> >>> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
> >> >> >>> >
> >> >> >>>
> >> >> >>> That is the address of p itself, not the address that p holds.
> >> >> >>
> >> >> >> Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which
> >> >> >> is where 't' is stored. This makes sense and thanks to your other post about
> >> >> >> printf doing what it does (yes, I know, you ran that past me several times but I
> >> >> >> didn't understand) from the pointer on out... things are a bit more clear.
> >> >> >>
> >> >> >>> (See the code at the bottom).
> >> >> >>
> >> >> >> I've seen this, or similar, but I gotta study on these operators:
> >> >> >> char *c=(char *)&x;
> >> >> >>
> >> >> >
> >> >> > There x is an int (a 4-byte value). The code casts the address of the
> >> >> > int to a char pointer, so you can walk the bytes of the int.
> >> >> >
> >> >>
> >> >> You could also walk the ints themselves, with the int pointer,
> >> >> and shift bits to isolate bytes:
> >> >>
> >> >> #include <stdio.h>
> >> >> #include <stdlib.h>
> >> >>
> >> >> #define INTCOUNT 10
> >> >>
> >> >> int main(void)
> >> >> {
> >> >> int *ip;
> >> >> int i=0;
> >> >>
> >> >> ip=malloc(INTCOUNT * sizeof *ip);
> >> >> if(ip==NULL)
> >> >> {
> >> >> fprintf(stderr,"ip malloc failed\n");
> >> >> exit(1);
> >> >> }
> >> >>
> >> >> ip[0]=0x41424344;
> >> >> ip[1]=0x45464748;
> >> >> ip[2]=0x494a4b4c;
> >> >> ip[3]=0x4d4e4f50;
> >> >> ip[4]=0x21222324;
> >> >> ip[5]=0x25262728;
> >> >> ip[6]=0x292a2b2c;
> >> >> ip[7]=0x2d2e2f30;
> >> >> ip[8]=0x31323334;
> >> >> ip[9]=0x35363738;
> >> >>
> >> >> for(i=0;i<INTCOUNT;i++)
> >> >> {
> >> >> printf("%c",ip[i]>>24);
> >> >> printf("%c",ip[i]<<8>>24);
> >> >> printf("%c",ip[i]<<16>>24);
> >> >> printf("%c",ip[i]<<24>>24);
> >> >> }
> >> >> printf("\n");
> >> >>
> >> >> free(ip);
> >> >> return 0;
> >> >> }
> >> >
> >> > I've been reading from that site you gave me a link to, which is helping.
> >> > Thanks for all this stuff you're posting, too. It may take awhile 'cuz I don't
> >> > have a lot of time right now but I'll get better.
> >>
> >>
> >> Array name and pointer interchangeable in C.
> >>
> >> ,----
> >> | int arrInts[10];
> >> `----
> >>
> >> You can then use sizeof() if you want to be 1337 and confuse people..
> >
> > I gotta get to 1115 first.
> >
> >>
> >> ,----
> >> | elements= sizeof(arrInts) / sizeof(arrInts[0])
> >> `----
> >>
> >> But do NOT use sizeof if you pass your array (pointer) to a
> >> functions.... sizeof(p) will be the sizeof of the int * pointer.
> >
> > That... and something about dereferencing Null pointers... all Greek to me ;)
> >
>
> Understand that a null pointer is effectively pointing at
> "nothing". Undefined behaviour. A pointer can point to an empty string
> though : the first char is nul... ;) An empty string is not the same as
> a null pointer.
>
> maybe ok C code (ie C not run through a check)
> ,----
> | char *p=NULL; /* ALWAYS initialise pointers to NULL explicitly. Peace
> | of mind */
> | char *myString="hello";
> | char *myString2="";
> | char c;
> | c= *p; /*bang ; can't dereference a NULL pointer*/
> | p=myString;
> | c=*p; /* c='h' */
> | p=myString2;
> | c=*p; /* c=nul */
> `----
>
>
>
>
> --
> chrisv alias turdv is a turd
This forum is a puss-filled cyst. Like most in this group, F 'The Flooder' Russell relies on biased media to contrive positions on politics. As a result, he only knows and listens to the accepted accounts which also are the ones which paint humanism in a dishonestly approving and ethical slant.
I am an absolute fanboi of macOS, because that's where all the compelling ingenuity is happening. LOL! Right, F 'The Flooder' Russell is pushing to sell an API reference, which Klaus Schadenfreude can get in seconds, that I taught myself. If he could stop being so stupid he would get how screwed up he proves himself to be.
--
Top 15 Ways F 'The Flooder' Russell Trolls
http://tmp.gallopinginsanity.com/BilkHelp.html
http://alt.conspiracy.narkive.com/QcWYJ4Px/the-mentally-ill-mark-s-bilk
https://www.youtube.com/watch?v=IhOfBmWwCVY
Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2018-10-19 18:33 +0000 |
| Message-ID | <az9b008g4agv.i@rooftop.invalid> |
| In reply to | #472768 |
Hadron Quark <hadronquark@gmail.com> wrote: > Steve Carroll <fretwizzer@gmail.com> writes: > >>> free(ip); >>> return 0; >>> } >> >> I've been reading from that site you gave me a link to, which is helping. >> Thanks for all this stuff you're posting, too. It may take awhile 'cuz I don't >> have a lot of time right now but I'll get better. > > > Array name and pointer interchangeable in C. > They are not. You can assign to pointers. You cannot assign to arrays. > ,---- > | int arrInts[10]; > `---- > The data in an array is on the stack. If you want to create an array of 100,000,000 ints, you'll probably need to make some retarded ulimit adjustment, whereas allocating for 100,000,000 ints on the heap is generally no problem with a modern computer. > You can then use sizeof() if you want to be 1337 and confuse people.. > Since when is sizeof is "1337"? It's fairly basic and is absolutely required for allocating memory in a sane way.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-10-19 12:16 -0700 |
| Message-ID | <d3a602d0-d84d-499a-a960-7941dfb45aaa@googlegroups.com> |
| In reply to | #472778 |
On Friday, October 19, 2018 at 11:33:36 AM UTC-7, owl wrote: > Hadron Quark <hadronquark@gmail.com> wrote: > > Steve Carroll <fretwizzer@gmail.com> writes: > > > >>> free(ip); > >>> return 0; > >>> } > >> > >> I've been reading from that site you gave me a link to, which is helping. > >> Thanks for all this stuff you're posting, too. It may take awhile 'cuz I don't > >> have a lot of time right now but I'll get better. > > > > > > Array name and pointer interchangeable in C. > > > > They are not. > You can assign to pointers. You cannot assign to arrays. > > > ,---- > > | int arrInts[10]; > > `---- > > > > The data in an array is on the stack. If you want to create > an array of 100,000,000 ints, you'll probably need to make some > retarded ulimit adjustment, whereas allocating for 100,000,000 > ints on the heap is generally no problem with a modern computer. > > > > You can then use sizeof() if you want to be 1337 and confuse people.. > > > > Since when is sizeof is "1337"? It's fairly basic and is absolutely > required for allocating memory in a sane way. What's the Earth coming to when a Klaus Schadenfreude plea for attention can not get any reaction? Klaus Schadenfreude is repeatedly seen insisting "GOOGLE HAS NOTHING" when it comes to text on a site where information does exist... but Klaus Schadenfreude is just too soft in the head and/or lost to understand any information... or he does not recognize it _as_ data when he does find it. It was Klaus Schadenfreude who was openly asking how better to obscure his forgeries. Sandman just wiped his ass with Klaus Schadenfreude. It's a prank call. Klaus Schadenfreude has already decided what he is going to say before he calls. What you say just a reaction. What Sandman says just a reaction. -- Curious how these posts are made? https://vid.me/TuHWn
[toc] | [prev] | [next] | [standalone]
| From | Hadron Quark <hadronquark@gmail.com> |
|---|---|
| Date | 2018-10-19 22:39 +0200 |
| Message-ID | <871s8ld62t.fsf@gmail.com> |
| In reply to | #472778 |
owl <owl@rooftop.invalid> writes: > Hadron Quark <hadronquark@gmail.com> wrote: >> Steve Carroll <fretwizzer@gmail.com> writes: >> >>>> free(ip); >>>> return 0; >>>> } >>> >>> I've been reading from that site you gave me a link to, which is helping. >>> Thanks for all this stuff you're posting, too. It may take awhile 'cuz I don't >>> have a lot of time right now but I'll get better. >> >> >> Array name and pointer interchangeable in C. >> > > They are not. > You can assign to pointers. You cannot assign to arrays. You're correct. I mispoke. I should have made clear in context of dereferencing. I think the example correct though. > >> ,---- >> | int arrInts[10]; >> `---- >> > > The data in an array is on the stack. If you want to create > an array of 100,000,000 ints, you'll probably need to make some > retarded ulimit adjustment, whereas allocating for 100,000,000 > ints on the heap is generally no problem with a modern computer. Indeed. But I was giving another example. Using malloc and free is not necessary for small localised stuff (such as this). In many place it would be considered "risky" because you need to remember the free. Not rockets science but in large code bases something to consider. > > >> You can then use sizeof() if you want to be 1337 and confuse people.. >> > > Since when is sizeof is "1337"? It's fairly basic and is absolutely > required for allocating memory in a sane way. > It isnt 1337 all the time, but there is no need here (in this example). if you're using "stack" as I am here you KNOW the length in context ;) Nothing more. I included the sizeof() to show how sizeof is used for pointers and arrays. I'm certainly not fighting with you. But yes about the array name. Years ago you could btw : some compilers were laxer than others ;) -- chrisv alias turdv is a turd
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-10-19 11:14 -0700 |
| Message-ID | <2126f1fa-4bc0-4144-89cf-725ecbc52acb@googlegroups.com> |
| In reply to | #472760 |
On Friday, October 19, 2018 at 9:24:43 AM UTC-7, Steve Carroll wrote:
> On Thursday, October 18, 2018 at 4:32:37 PM UTC-6, owl wrote:
> > owl <owl@rooftop.invalid> wrote:
> > > Steve Carroll <fretwizzer@gmail.com> wrote:
> > >> On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote:
> > >>> Steve Carroll <fretwizzer@gmail.com> wrote:
> > >>> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote:
> > >>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> > >>> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote:
> > >>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> > >>> >> >
> > >>> >> > (snip)
> > >>> >> >
> > >>> >> >> >> x is never anything but a pointer.
> > >>> >> >> >
> > >>> >> >> > But it can still hold a value.
> > >>> >> >>
> > >>> >> >>
> > >>> >> >> An address value.
> > >>> >> >
> > >>> >> > I know that a var is just a place in memory that holds a value so, in this
> > >>> >> > respect, it's a pointer. But why complicate things with this additional
> > >>> >> > pointer keyword? Why the need to refer to the first char at all?
> > >>> >> >
> > >>> >> >> > For example, when I also run this with the above,
> > >>> >> >> > and placed above it...
> > >>> >> >> >
> > >>> >> >> > char *p = "test";
> > >>> >> >> > char b[] = "test";
> > >>> >> >> > printf("%c\n",*p);
> > >>> >> >> > printf("%s\n",b);
> > >>> >> >> >
> > >>> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier.
> > >>> >> >> >
> > >>> >> >>
> > >>> >> >> p and *p are different things. p is the address. *p is the char at
> > >>> >> >> that address.
> > >>> >> >
> > >>> >> > What I initially didn't realize (because it failed on a first run!) was this...
> > >>> >> >
> > >>> >> > char *p = "test";
> > >>> >> >
> > >>> >> > ... is simultaneously assigning the value "test to the variable 'p' and
> > >>> >> > creating a pointer to it (the first char). So this will display both :
> > >>> >> >
> > >>> >> > char *p = "test";
> > >>> >> > printf("%c\n",*p);
> > >>> >> > printf("%s\n",p);
> > >>> >> >
> > >>> >> > In any event, I get back 't' and then the entire string "test", which is, to
> > >>> >> > my way of thinking, a value, not an "address". I also noticed a pointer
> > >>> >> > has to be defined in advance, this...
> > >>> >> >
> > >>> >> > char p = "test";
> > >>> >> > printf("%c\n",*p);
> > >>> >> >
> > >>> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that
> > >>> >> > you won't always need a pointer? However, if you do decide to create
> > >>> >> > one you can assign a value to the 'pointed to' variable simultaneously,
> > >>> >> > which is handy.
> > >>> >> >
> > >>> >> >> a %s printf would print that char and all successive
> > >>> >> >> chars until it hits a '\0'.
> > >>> >> >>
> > >>> >> >>
> > >>> >> >>
> > >>> >> >> > webdev$ ./test
> > >>> >> >> > t
> > >>> >> >> > test
> > >>> >> >> > (null)
> > >>> >> >> > hello
> > >>> >> >> > hello
> > >>> >> >> >
> > >>> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank
> > >>> >> >> > line I got: '(null)'.
> > >>> >> >>
> > >>> >> >> Like I said, x is null at that point.
> > >>> >> >
> > >>> >> > I got it, but it didn't display null the first time through, just a blank line,
> > >>> >> > which was a little confusing.
> > >>> >> >
> > >>> >> >> When I run it, with the your new code placed above the old, the first
> > >>> >> >> thing that happens with stdout is the attempt to
> > >>> >> >>
> > >>> >> >> printf("%c\n",x);
> > >>> >> >>
> > >>> >> >> when x has not yet been assigned a value. That is an attempt to
> > >>> >> >> print (as a char) the null pointer x.
> > >>> >> >
> > >>> >> > As I assume most of us do, I often learn more by trying to break things,
> > >>> >> > code that runs differently on the first run slows things down a bit. What
> > >>> >> > causes that?
> > >>> >> >
> > >>> >>
> > >>> >> When trying to grasp pointers, you have to get away from the concept of
> > >>> >> strings. Pointers are addresses. Period.
> > >>> >
> > >>> > From what I've read they're 'named' addresses so, like you show below, a
> > >>> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8).
> > >>> >
> > >>>
> > >>> That is the address of p itself, not the address that p holds.
> > >>
> > >> Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which
> > >> is where 't' is stored. This makes sense and thanks to your other post about
> > >> printf doing what it does (yes, I know, you ran that past me several times but I
> > >> didn't understand) from the pointer on out... things are a bit more clear.
> > >>
> > >>> (See the code at the bottom).
> > >>
> > >> I've seen this, or similar, but I gotta study on these operators:
> > >> char *c=(char *)&x;
> > >>
> > >
> > > There x is an int (a 4-byte value). The code casts the address of the
> > > int to a char pointer, so you can walk the bytes of the int.
> > >
> >
> > You could also walk the ints themselves, with the int pointer,
> > and shift bits to isolate bytes:
> >
> > #include <stdio.h>
> > #include <stdlib.h>
> >
> > #define INTCOUNT 10
> >
> > int main(void)
> > {
> > int *ip;
> > int i=0;
> >
> > ip=malloc(INTCOUNT * sizeof *ip);
> > if(ip==NULL)
> > {
> > fprintf(stderr,"ip malloc failed\n");
> > exit(1);
> > }
> >
> > ip[0]=0x41424344;
> > ip[1]=0x45464748;
> > ip[2]=0x494a4b4c;
> > ip[3]=0x4d4e4f50;
> > ip[4]=0x21222324;
> > ip[5]=0x25262728;
> > ip[6]=0x292a2b2c;
> > ip[7]=0x2d2e2f30;
> > ip[8]=0x31323334;
> > ip[9]=0x35363738;
> >
> > for(i=0;i<INTCOUNT;i++)
> > {
> > printf("%c",ip[i]>>24);
> > printf("%c",ip[i]<<8>>24);
> > printf("%c",ip[i]<<16>>24);
> > printf("%c",ip[i]<<24>>24);
> > }
> > printf("\n");
> >
> > free(ip);
> > return 0;
> > }
>
> I've been reading from that site you gave me a link to, which is helping.
> Thanks for all this stuff you're posting, too. It may take awhile 'cuz I don't
> have a lot of time right now but I'll get better.
Besides Takuya 'Super Troll' Saitoh, who can not figure out what I'm doing? Did Takuya 'Super Troll' Saitoh think that was clever? This is just an amusement of mine. In fact Takuya 'Super Troll' Saitoh's lies got bigger. So as might be expected I regret not lashing out at Takuya 'Super Troll' Saitoh. While I am sure the trolls liked it, I've not helped the situation at all.
I am a total devotee of Xfce, because that's where all the stimulating ingenuity is happening. Snit shreds Takuya 'Super Troll' Saitoh in every way possible. Just baloney from Takuya 'Super Troll' Saitoh. But he has completely left objectivity behind and is holding me culpable for the exploits of himself.
--
Live on Kickstarter
https://groups.google.com/forum/#!topic/comp.lang.c/KDQrv8appR8
https://youtu.be/HMx0RyzbPgQ
https://youtu.be/HMx0RyzbPgQ
Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | "F. Russell" <fr@random.info> |
|---|---|
| Date | 2018-10-18 18:46 +0000 |
| Message-ID | <pqakem02g9b@news2.newsguy.com> |
| In reply to | #472635 |
On Thu, 18 Oct 2018 08:58:35 -0700, Steve Carroll wrote: > > I know that a var is just a place in memory that holds a value so, in this > respect, it's a pointer. But why complicate things with this additional > pointer keyword? > These questions cannot be answered unless one has the necessary background in computer architecture and computer science. You'd better stick to high level languages that obscure the machine. C does not obscure the machine. Think of a subroutine (assembly) or function (C). In C, a function is created on the fly by pushing the current instruction pointer on the stack, jumping to the function address, and then creating stack space for local variables. But a function can also be passed variables that cannot be copied and thus they require an address reference. That reference is a "pointer." As I indicated earlier, a C pointer is equivalent to the "indirect addressing" capabilities of a microprocessor. C is only one small step above assembly.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <fretwizzer@gmail.com> |
|---|---|
| Date | 2018-10-18 12:06 -0700 |
| Message-ID | <5e7120c4-bab0-43ca-9300-d0cdef31c56a@googlegroups.com> |
| In reply to | #472659 |
On Thursday, October 18, 2018 at 12:47:44 PM UTC-6, F. Russell wrote: > On Thu, 18 Oct 2018 08:58:35 -0700, Steve Carroll wrote: > > > > > I know that a var is just a place in memory that holds a value so, in this > > respect, it's a pointer. But why complicate things with this additional > > pointer keyword? > > > > These questions cannot be answered unless one has the necessary > background in computer architecture and computer science. > > You'd better stick to high level languages that obscure the machine. > C does not obscure the machine. I probably will but I'm just following curiosity at this point. > Think of a subroutine (assembly) or function (C). > > In C, a function is created on the fly by pushing the current > instruction pointer on the stack, jumping to the function address, > and then creating stack space for local variables. But a function > can also be passed variables that cannot be copied and thus they > require an address reference. That reference is a "pointer." > > As I indicated earlier, a C pointer is equivalent to the "indirect > addressing" capabilities of a microprocessor. > > C is only one small step above assembly. I didn't realize how small (I can remember poking bytes on a 6502 but that was a long time ago), in C you must manage a lot.
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.os.linux.advocacy
csiph-web