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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | Jeff-Relf.Me @. |
|---|---|
| Date | 2018-10-17 12:48 -0700 |
| Subject | An array of strings is an array of pointers. |
| Message-ID | <Jeff-Relf.Me@Oct.17--0.48pm.Seattle.2018> |
| In reply to | #472524 |
A string is a (64 bit) pointer, an address, to a sequential array of UTF-8, UTF-16 or UTF-32. So an array of strings is an array of pointers, any of which might be zero, null. Content-Type, file extensions, and BOM markers are also important.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-10-17 13:10 -0700 |
| Subject | Re: An array of strings is an array of pointers. |
| Message-ID | <2b6baea1-5dc1-4c6d-bf88-2177bb853b2a@googlegroups.com> |
| In reply to | #472529 |
On Wednesday, October 17, 2018 at 12:48:43 PM UTC-7, Jeff-Relf.Me wrote: > A string is a (64 bit) pointer, an address, > to a sequential array of UTF-8, UTF-16 or UTF-32. > > So an array of strings is an array of pointers, > any of which might be zero, null. > > Content-Type, file extensions, and BOM markers are also important. It won't matter because the apparent origin on a post is irrelevant, we know it is from the stalker anyway. How is LibreOffice on Linux doing anything above the lowest common denominator? Larry 'The Flooder' Washington and the other trolls imply asking for a recommendation for a FOSS application is trolling. One guy reported Larry 'The Flooder' Washington years ago. As expected, it did zilch to attenuate the boob. -- This Trick Gets Women Hot For You https://www.reddit.com/r/linux/comments/6sfkup/what_desktop_tasks_does_linux_handle_better_than/= http://www.5z8.info/peepshow_z9s9ht_dogporn https://youtu.be/iztSc_msHuo Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-10-17 12:38 -0700 |
| Message-ID | <dd82d1e1-82c2-4520-a7b1-9253d160eada@googlegroups.com> |
| In reply to | #472518 |
On Wednesday, October 17, 2018 at 11:28:13 AM UTC-7, Hadron Quark wrote: > Steve Carroll <fretwizzer@gmail.com> writes: > > > On Wednesday, October 17, 2018 at 11:41:13 AM UTC-6, chrisv wrote: > >> Steve Carroll wrote: > >> > >> > owl wrote: > >> >> > >> >> Well, there is no "string" data type in C. > >> > > >> >I found that out, it was one of the things that was most surprising. > >> > >> Not really, once you understand that "strings" are effectively an > >> array of chars, in any language. > > > > That's true (even in JS)... but I've heard people wrongly claim there's > > an actual 'string' data type in C, all along I've just assumed it has > > one. > > It's a perilous conversation. People still get confused over a null > string and an empty string... > > > > >> What else would they be? C is more > >> "low level" than most languages, of course. > > > > And when you start looking you realize what that actually means when > > you begin to write it ;) > > > >> Check-out the below ignorance from Dumfsck. Oh, dear, no booleans! > >> How did we survive?!? Sheesh. > > > > Booleanless? The pain, the pain... > > > >> -- > >> "You worship a language that still has no String data type > >> (null-terminated array of chars... heh!). That didn't have booleans > >> until 25 years after it was introduced?" - VB "programmer" DumFSck, > >> ignorantly attacking C > > > > I can't pass judgement... until recently, I thought C had a string > > data type. > > It effectively does : string is tightly defined in ISO C. An array > of char units. And of course wchar_t units. Both with a terminator. > > An array of chars is not in itself a string. It must also be have a > trailing zero element : NUL. > > > -- > chrisv alias turdv is a turd Usenet is a free phenomenon based on shared ethics. See: I noted specific examples of Onion 'The Shill' Knight falsely attributing someone else's words to me, trolling multiple groups, etc. His response: to troll Jonas Eklundh. Onion 'The Shill' Knight is regularly seen declaring "NOT THERE" when it comes to information on Jonas Eklundh's post where information is written with other words... but Onion 'The Shill' Knight is just too brain-dead or distracted to understand any instruction he reads. It was Onion 'The Shill' Knight who flooded Jonas Eklundh's site thousands of times and denied it. Can UTF-8 characters be concatenated into a string with a logical connection to the "real" world; that is the question posed recently by those astonished at the endless babbling of "advocates" and Cheetos smelling losers. Gee, imagine Onion 'The Shill' Knight trying to pin his gobbledegook on me or others, no one has ever seen that before ¯\_(ツ)_/¯. I'm guessing, after deleting all the flooding from Onion 'The Shill' Knight, it's mainly just two flooders authoring the preponderance of the trolling. No doubt. And both 100% unhinged screwballs. -- This broke the Internet https://groups.google.com/forum/#!topic/alt.os.linux/BVpdH5KOc6s https://www.youtube.com/watch?v=u4xD43Khhkw Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | fr314159@gmail.com |
|---|---|
| Date | 2018-10-17 11:30 -0700 |
| Message-ID | <49c1b8b7-7b89-4d1b-b5be-575e50f5ab49@googlegroups.com> |
| In reply to | #472514 |
On Wednesday, October 17, 2018 at 2:11:53 PM UTC-4, Steve Carroll wrote: > > > Check-out the below ignorance from Dumfsck. Oh, dear, no booleans! > > How did we survive?!? Sheesh. > > Booleanless? The pain, the pain... > There is NO need for Booleans in C because anything that is non-zero evaluates to TRUE and anything that is zero evaluates to FALSE.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-10-17 12:08 -0700 |
| Message-ID | <b0b9a386-6c6c-49b2-b133-ad63288ccfaf@googlegroups.com> |
| In reply to | #472520 |
On Wednesday, October 17, 2018 at 11:30:23 AM UTC-7, fr31...@gmail.com wrote: > On Wednesday, October 17, 2018 at 2:11:53 PM UTC-4, Steve Carroll wrote: > > > > > > Check-out the below ignorance from Dumfsck. Oh, dear, no booleans! > > > How did we survive?!? Sheesh. > > > > Booleanless? The pain, the pain... > > > > There is NO need for Booleans in C because anything that is non-zero > evaluates to TRUE and anything that is zero evaluates to FALSE. How is barely used potential gray matter tied to failed neuron connectivity in any way going to lead to improved group posting? Having to suffer the use of Cinnamon is too much for Sandman, AKA Jonas Eklundh to deal with. The person you are replying to is in my shit list. - One Smart Penny!! http://www.5z8.info/how-to-build-a-bomb_h2o1be_peepshow https://www.youtube.com/watch?v=OffkiSAsYo8 Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <fretwizzer@gmail.com> |
|---|---|
| Date | 2018-10-17 12:42 -0700 |
| Message-ID | <b5b6c08a-6029-4d7c-a9b0-66498613867d@googlegroups.com> |
| In reply to | #472520 |
On Wednesday, October 17, 2018 at 12:30:23 PM UTC-6, fr31...@gmail.com wrote:
> On Wednesday, October 17, 2018 at 2:11:53 PM UTC-4, Steve Carroll wrote:
>
> >
> > > Check-out the below ignorance from Dumfsck. Oh, dear, no booleans!
> > > How did we survive?!? Sheesh.
> >
> > Booleanless? The pain, the pain...
> >
>
> There is NO need for Booleans in C because anything that is non-zero
> evaluates to TRUE and anything that is zero evaluates to FALSE.
LOL! Ok, I'll take your word for it... relax ;)
What about this...
--
char *x;
char y[]="hello";
printf("%c\n",x);
printf("%s\n", y);
x=y;
printf("%s\n",x);
--
I get:
warning: format specifies type 'int' but the argument has type 'char *' [-Wformat]
printf("%c\n",x);
~~ ^
%s
1 warning generated.
With %s it'll print an empty line.
Is that default behavior? In other words, how does it know x is initially not
a single char if it's not yet been assigned a value?
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2018-10-17 20:00 +0000 |
| Message-ID | <s98ba0ba.3h@rooftop.invalid> |
| In reply to | #472528 |
Steve Carroll <fretwizzer@gmail.com> wrote:
> On Wednesday, October 17, 2018 at 12:30:23 PM UTC-6, fr31...@gmail.com wrote:
>> On Wednesday, October 17, 2018 at 2:11:53 PM UTC-4, Steve Carroll wrote:
>>
>> >
>> > > Check-out the below ignorance from Dumfsck. Oh, dear, no booleans!
>> > > How did we survive?!? Sheesh.
>> >
>> > Booleanless? The pain, the pain...
>> >
>>
>> There is NO need for Booleans in C because anything that is non-zero
>> evaluates to TRUE and anything that is zero evaluates to FALSE.
>
> LOL! Ok, I'll take your word for it... relax ;)
>
> What about this...
>
> --
> char *x;
> char y[]="hello";
>
> printf("%c\n",x);
> printf("%s\n", y);
>
> x=y;
> printf("%s\n",x);
> --
>
> I get:
> warning: format specifies type 'int' but the argument has type 'char *' [-Wformat]
> printf("%c\n",x);
> ~~ ^
> %s
> 1 warning generated.
>
x is a pointer, not a char. It is also NULL at that point (line 4).
> With %s it'll print an empty line.
>
> Is that default behavior? In other words, how does it know x is initially not
> a single char if it's not yet been assigned a value?
x is never anything but a pointer.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <fretwizzer@gmail.com> |
|---|---|
| Date | 2018-10-17 13:25 -0700 |
| Message-ID | <7b39071c-0898-4575-8799-76f04f683d52@googlegroups.com> |
| In reply to | #472531 |
On Wednesday, October 17, 2018 at 2:00:52 PM UTC-6, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Wednesday, October 17, 2018 at 12:30:23 PM UTC-6, fr31...@gmail.com wrote:
> >> On Wednesday, October 17, 2018 at 2:11:53 PM UTC-4, Steve Carroll wrote:
> >>
> >> >
> >> > > Check-out the below ignorance from Dumfsck. Oh, dear, no booleans!
> >> > > How did we survive?!? Sheesh.
> >> >
> >> > Booleanless? The pain, the pain...
> >> >
> >>
> >> There is NO need for Booleans in C because anything that is non-zero
> >> evaluates to TRUE and anything that is zero evaluates to FALSE.
> >
> > LOL! Ok, I'll take your word for it... relax ;)
> >
> > What about this...
> >
> > --
> > char *x;
> > char y[]="hello";
> >
> > printf("%c\n",x);
> > printf("%s\n", y);
> >
> > x=y;
> > printf("%s\n",x);
> > --
> >
> > I get:
> > warning: format specifies type 'int' but the argument has type 'char *' [-Wformat]
> > printf("%c\n",x);
> > ~~ ^
> > %s
> > 1 warning generated.
> >
>
> x is a pointer, not a char. It is also NULL at that point (line 4).
>
>
> > With %s it'll print an empty line.
> >
> > Is that default behavior? In other words, how does it know x is initially not
> > a single char if it's not yet been assigned a value?
>
>
> x is never anything but a pointer.
But it can still hold a value. 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.
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)'.
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2018-10-17 20:46 +0000 |
| Message-ID | <az0b0a00ba.3@rooftop.invalid> |
| In reply to | #472535 |
Steve Carroll <fretwizzer@gmail.com> wrote:
> On Wednesday, October 17, 2018 at 2:00:52 PM UTC-6, owl wrote:
>> Steve Carroll <fretwizzer@gmail.com> wrote:
>> > On Wednesday, October 17, 2018 at 12:30:23 PM UTC-6, fr31...@gmail.com wrote:
>> >> On Wednesday, October 17, 2018 at 2:11:53 PM UTC-4, Steve Carroll wrote:
>> >>
>> >> >
>> >> > > Check-out the below ignorance from Dumfsck. Oh, dear, no booleans!
>> >> > > How did we survive?!? Sheesh.
>> >> >
>> >> > Booleanless? The pain, the pain...
>> >> >
>> >>
>> >> There is NO need for Booleans in C because anything that is non-zero
>> >> evaluates to TRUE and anything that is zero evaluates to FALSE.
>> >
>> > LOL! Ok, I'll take your word for it... relax ;)
>> >
>> > What about this...
>> >
>> > --
>> > char *x;
>> > char y[]="hello";
>> >
>> > printf("%c\n",x);
>> > printf("%s\n", y);
>> >
>> > x=y;
>> > printf("%s\n",x);
>> > --
>> >
>> > I get:
>> > warning: format specifies type 'int' but the argument has type 'char *' [-Wformat]
>> > printf("%c\n",x);
>> > ~~ ^
>> > %s
>> > 1 warning generated.
>> >
>>
>> x is a pointer, not a char. It is also NULL at that point (line 4).
>>
>>
>> > With %s it'll print an empty line.
>> >
>> > Is that default behavior? In other words, how does it know x is initially not
>> > a single char if it's not yet been assigned a value?
>>
>>
>> x is never anything but a pointer.
>
> But it can still hold a value.
An address value.
> 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. 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.
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.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-10-17 14:13 -0700 |
| Message-ID | <147ec301-530b-4b39-9a78-c0c5223603a1@googlegroups.com> |
| In reply to | #472540 |
On Wednesday, October 17, 2018 at 1:46:27 PM UTC-7, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Wednesday, October 17, 2018 at 2:00:52 PM UTC-6, owl wrote:
> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> > On Wednesday, October 17, 2018 at 12:30:23 PM UTC-6, fr31...@gmail.com wrote:
> >> >> On Wednesday, October 17, 2018 at 2:11:53 PM UTC-4, Steve Carroll wrote:
> >> >>
> >> >> >
> >> >> > > Check-out the below ignorance from Dumfsck. Oh, dear, no booleans!
> >> >> > > How did we survive?!? Sheesh.
> >> >> >
> >> >> > Booleanless? The pain, the pain...
> >> >> >
> >> >>
> >> >> There is NO need for Booleans in C because anything that is non-zero
> >> >> evaluates to TRUE and anything that is zero evaluates to FALSE.
> >> >
> >> > LOL! Ok, I'll take your word for it... relax ;)
> >> >
> >> > What about this...
> >> >
> >> > --
> >> > char *x;
> >> > char y[]="hello";
> >> >
> >> > printf("%c\n",x);
> >> > printf("%s\n", y);
> >> >
> >> > x=y;
> >> > printf("%s\n",x);
> >> > --
> >> >
> >> > I get:
> >> > warning: format specifies type 'int' but the argument has type 'char *' [-Wformat]
> >> > printf("%c\n",x);
> >> > ~~ ^
> >> > %s
> >> > 1 warning generated.
> >> >
> >>
> >> x is a pointer, not a char. It is also NULL at that point (line 4).
> >>
> >>
> >> > With %s it'll print an empty line.
> >> >
> >> > Is that default behavior? In other words, how does it know x is initially not
> >> > a single char if it's not yet been assigned a value?
> >>
> >>
> >> x is never anything but a pointer.
> >
> > But it can still hold a value.
>
>
> An address value.
>
>
> > 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. 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.
> 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.
My uptime is almost thirty-nine weeks and Tar is still going strong! And in reply you have nothing but a crack to start a troll-fest. Fuchsia runs on the Tar kernel. So yeah, Tar is mobile. Tar is a super computer. Tar is a server. Tar is a desktop. Tar is growing in market share.
Can you get over it? Jonas Eklundh shreds Klaus Schadenfreude in every way possible. It's a prolonged battle, and Klaus Schadenfreude is simultaneously unable to stop his trolling remarks, while posting with socks with a myriad of tells.
--
"You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention"
Steven Petruzzellis, making the dumbest comment ever uttered.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <fretwizzer@gmail.com> |
|---|---|
| Date | 2018-10-18 08:58 -0700 |
| Message-ID | <75645a72-f0d2-44da-bc48-d47fab4c83ea@googlegroups.com> |
| In reply to | #472540 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2018-10-18 17:28 +0000 |
| Message-ID | <Do3yD.78179$QD7.69643@fx44.am4> |
| In reply to | #472635 |
On 2018-10-18, 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?
Because it's char variable. Single char.
>
>> > 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
>
No. It is assigning address of string literal to pointer.
Take a course in assembler, it will be much clearer to you.
--
press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <fretwizzer@gmail.com> |
|---|---|
| Date | 2018-10-18 11:01 -0700 |
| Message-ID | <820b8bc4-ede0-4c21-9bb4-12a6f9f6ed88@googlegroups.com> |
| In reply to | #472646 |
On Thursday, October 18, 2018 at 11:28:06 AM UTC-6, Melzzzzz wrote:
> On 2018-10-18, 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?
>
> Because it's char variable. Single char.
> >
> >> > 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
> >
> No. It is assigning address of string literal to pointer.
Consider...
char *p = "test";
printf("%c\n",*p);
printf("%s\n",p);
webdev$ ./show_stuff
t
test
To my eye 'p' is acting like any variable I've ever seen... print it, you get
it's stored value. I obviously didn't explicitly define it where I didn't also
do the pointer. Something fishy is going on if it's not what I suggested.
> Take a course in assembler, it will be much clearer to you.
I did a little assembly code for the 6502 like 35 years ago... don't recall
much, so maybe I'll need to do this if I continue with messing with C.
( highly debatable at the moment ;)
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2018-10-18 18:16 +0000 |
| Message-ID | <8f090a0ab.3@rooftop.invalid> |
| In reply to | #472649 |
Steve Carroll <fretwizzer@gmail.com> wrote:
> On Thursday, October 18, 2018 at 11:28:06 AM UTC-6, Melzzzzz wrote:
>> On 2018-10-18, 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?
>>
>> Because it's char variable. Single char.
>> >
>> >> > 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
>> >
>> No. It is assigning address of string literal to pointer.
>
> Consider...
>
> char *p = "test";
> printf("%c\n",*p);
> printf("%s\n",p);
>
> webdev$ ./show_stuff
> t
> test
>
> To my eye 'p' is acting like any variable I've ever seen... print it, you get
> it's stored value. I obviously didn't explicitly define it where I didn't also
> do the pointer. Something fishy is going on if it's not what I suggested.
>
When you call
printf("%c\n",*p);
the printf function is dereferencing p and printing the char it
points to.
When you call
printf("%s\n",p);
the printf function is reading and printing individual chars, starting
at the address held by p and continuing until it hits a '\0'.
In other words, it is sequentially printing the chars *p, *(p+1),
*(p+2), etc. When *(p+n) == '\0', it stops printing.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2018-10-18 18:39 +0000 |
| Message-ID | <Jr4yD.32067$Do.4772@fx31.am4> |
| In reply to | #472649 |
On 2018-10-18, Steve Carroll <fretwizzer@gmail.com> wrote:
> On Thursday, October 18, 2018 at 11:28:06 AM UTC-6, Melzzzzz wrote:
>> On 2018-10-18, 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?
>>
>> Because it's char variable. Single char.
>> >
>> >> > 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
>> >
>> No. It is assigning address of string literal to pointer.
>
> Consider...
>
> char *p = "test";
> printf("%c\n",*p);
> printf("%s\n",p);
>
> webdev$ ./show_stuff
> t
> test
>
> To my eye 'p' is acting like any variable I've ever seen... print it, you get
> it's stored value. I obviously didn't explicitly define it where I didn't also
> do the pointer. Something fishy is going on if it's not what I suggested.
*p is dereferencing pointer, that is taking value at that address.
try *(p+1) or p[1] or p[0]
--
press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-10-18 11:51 -0700 |
| Message-ID | <966e4f42-f25c-4e73-8d39-c7b901cd3e67@googlegroups.com> |
| In reply to | #472658 |
On Thursday, October 18, 2018 at 11:39:40 AM UTC-7, Melzzzzz wrote:
> On 2018-10-18, Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Thursday, October 18, 2018 at 11:28:06 AM UTC-6, Melzzzzz wrote:
> >> On 2018-10-18, 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?
> >>
> >> Because it's char variable. Single char.
> >> >
> >> >> > 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
> >> >
> >> No. It is assigning address of string literal to pointer.
> >
> > Consider...
> >
> > char *p = "test";
> > printf("%c\n",*p);
> > printf("%s\n",p);
> >
> > webdev$ ./show_stuff
> > t
> > test
> >
> > To my eye 'p' is acting like any variable I've ever seen... print it, you get
> > it's stored value. I obviously didn't explicitly define it where I didn't also
> > do the pointer. Something fishy is going on if it's not what I suggested.
>
> *p is dereferencing pointer, that is taking value at that address.
> try *(p+1) or p[1] or p[0]
>
>
> --
> press any key to continue or any other to quit...
My position: Even if Snit Glasser was merely stealing classes from colleges, the idea that acquiring expertise as being one of having "not anything" to show for it doesn't fly because you will by definition have the proficiency to show for it and knowledge is beyond Snit Glasser. You insisting a lie is real does not make it true. <giggle>
--
Curious how these posts are made? Email: fretwizzer@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-10-18 11:04 -0700 |
| Message-ID | <5cdcb7c0-59be-4c71-901d-cf19162eecf6@googlegroups.com> |
| In reply to | #472646 |
On Thursday, October 18, 2018 at 10:28:06 AM UTC-7, Melzzzzz wrote:
> On 2018-10-18, 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?
>
> Because it's char variable. Single char.
> >
> >> > 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
> >
> No. It is assigning address of string literal to pointer.
> Take a course in assembler, it will be much clearer to you.
>
> --
> press any key to continue or any other to quit...
I am a complete advocate of Arch Linux, because that's where all the thrilling ingenuity is happening. He pretends that he uses Windows, while you know he never recorded it on anything but an emulator and faithfully played with it. I do not know if there is a free open source solution. Thanks to Owl and his 'convenient friends' you now need an approved list (which I made for NewsLeecher and slrn). Dig through the archives, by and large I lately stopped giving him what he earned (even though I want to). If people start targeting him again I will slip in my resolve... as I've always stated I would. I'm referring to advocates here, not socks, who think for themselves.
--
Best CMS Solution of 2017!!
https://youtu.be/GPPqvw8iEBs
Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2018-10-18 17:54 +0000 |
| Message-ID | <sa0b080bfaf.o3@rooftop.invalid> |
| In reply to | #472635 |
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. In the case of "strings", the
pointer is a "pointer to char". That is another way of saying "pointer
to byte." 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.
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$
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <fretwizzer@gmail.com> |
|---|---|
| Date | 2018-10-18 11:12 -0700 |
| Message-ID | <448e03ca-7540-4fb0-aa0c-c00f40659161@googlegroups.com> |
| In reply to | #472648 |
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).
> 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)? 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.
> 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 ;)
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2018-10-18 18:25 +0000 |
| Message-ID | <sa900zb80d.a@rooftop.invalid> |
| In reply to | #472652 |
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.
> 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;
}
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.os.linux.advocacy
csiph-web