Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #149088 > unrolled thread
| Started by | T <T@invalid.invalid> |
|---|---|
| First post | 2020-01-14 09:22 -0800 |
| Last post | 2020-01-22 18:44 +0100 |
| Articles | 20 on this page of 262 — 29 participants |
Back to article view | Back to comp.lang.c
C String terminator T <T@invalid.invalid> - 2020-01-14 09:22 -0800
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-14 09:32 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-14 09:43 -0800
Re: C String terminator Bart <bc@freeuk.com> - 2020-01-14 17:53 +0000
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-01-14 20:17 +0100
Re: C String terminator Bart <bc@freeuk.com> - 2020-01-14 20:01 +0000
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-14 09:57 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-14 11:37 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:02 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:38 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:53 -0800
Re: C String terminator Manfred <noname@add.invalid> - 2020-01-14 20:48 +0100
Re: C String terminator chad <cdalten@gmail.com> - 2020-01-15 05:43 -0800
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-15 07:12 -0800
Re: C String terminator Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-15 15:35 +0000
Re: C String terminator chad <cdalten@gmail.com> - 2020-01-19 06:20 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 10:52 -0800
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-15 12:52 -0800
Re: C String terminator gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-15 20:56 +0000
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 02:17 +0000
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 21:54 -0800
Re: C String terminator fir <profesor.fir@gmail.com> - 2020-01-16 02:07 -0800
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-16 02:45 -0800
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-16 08:21 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-16 08:03 -0800
Re: C String terminator John Bode <jfbode1029@gmail.com> - 2020-01-16 09:06 -0800
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-16 11:29 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 02:01 +0000
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-15 23:02 -0500
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-01-16 11:15 +0100
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 13:07 +0000
Re: C String terminator Manfred <noname@add.invalid> - 2020-01-17 18:43 +0100
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 04:00 -0800
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 05:00 -0800
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-14 12:36 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-14 12:05 -0800
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-14 13:54 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-14 15:03 -0800
Re: C String terminator Thiago Adams <thiago.adams@gmail.com> - 2020-01-15 04:55 -0800
Re: C String terminator Guillaume <message@bottle.org> - 2020-01-15 20:49 +0100
Re: C String terminator Thiago Adams <thiago.adams@gmail.com> - 2020-01-15 12:55 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-14 21:31 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:28 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:38 -0800
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-15 10:50 -0700
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 10:17 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:53 -0800
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-01-14 21:43 -0500
Re: C String terminator "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-14 22:52 -0800
Re: C String terminator "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-14 22:54 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 02:00 -0800
Re: C String terminator gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-15 10:47 +0000
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-15 03:02 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 10:19 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 11:33 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 12:03 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 01:30 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 18:17 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 03:44 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 20:33 -0800
Re: C String terminator fir <profesor.fir@gmail.com> - 2020-01-16 02:26 -0800
Re: C String terminator Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-15 15:11 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:32 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 10:47 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 10:58 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 01:39 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 18:27 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 19:03 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 03:28 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 19:33 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 19:38 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 13:31 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-16 09:09 -0800
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-16 10:27 -0700
Re: C String terminator T <T@invalid.invalid> - 2020-01-16 10:54 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 20:59 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-16 14:11 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 20:17 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-16 14:14 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 23:45 +0000
Yes, Ben makes house calls (Was: C String terminator) gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-16 23:57 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 11:28 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-17 20:46 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 12:48 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 12:54 -0800
Re: C String terminator Bart <bc@freeuk.com> - 2020-01-17 21:02 +0000
Re: C String terminator Bart <bc@freeuk.com> - 2020-01-17 21:21 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 13:35 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 13:44 -0800
Re: C String terminator fir <profesor.fir@gmail.com> - 2020-01-17 15:03 -0800
Re: C String terminator fir <profesor.fir@gmail.com> - 2020-01-17 15:06 -0800
Re: C String terminator Ike Naar <ike@sdf.lonestar.org> - 2020-01-18 07:30 +0000
Re: C String terminator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-17 16:06 -0500
Re: C String terminator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-17 16:23 -0500
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 13:37 -0800
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 04:10 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-21 10:41 -0800
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 02:25 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-16 14:24 -0800
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 08:13 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-22 09:05 -0800
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 19:58 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-27 23:26 -0700
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 09:21 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-02 09:54 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-02 11:17 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-02 13:12 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-02 13:28 -0700
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 19:17 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-03 09:47 +0200
Re: C String terminator already5chosen@yahoo.com - 2020-04-03 08:03 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-03 17:34 +0200
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 12:39 -0400
Re: C String terminator Bart <bc@freeuk.com> - 2020-04-03 18:05 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 10:18 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-03 22:13 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 14:36 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 16:18 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 01:43 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-04 18:23 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 11:18 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 13:02 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-05 21:54 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 13:59 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-06 09:07 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 02:25 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 11:43 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 03:56 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 16:34 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 10:30 -0700
Re: C String terminator richard@cogsci.ed.ac.uk (Richard Tobin) - 2020-04-06 17:50 +0000
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 11:31 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 12:04 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 21:51 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 14:34 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 14:39 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 14:52 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 15:31 -0700
Re: C String terminator jameskuyper@stellarscience.com - 2020-04-06 16:05 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 03:08 +0100
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-06 21:12 -0600
Re: C String terminator scott@slp53.sl.home (Scott Lurndal) - 2020-04-07 16:55 +0000
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-07 11:05 -0600
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-07 20:39 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 11:48 -0700
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-07 21:21 -0600
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-07 20:40 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 01:41 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 07:40 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 08:16 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 09:17 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 09:46 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 10:37 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 10:48 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-08 14:07 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 11:29 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 16:46 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 01:57 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-09 08:42 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 08:56 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-09 12:42 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 10:12 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-09 15:51 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 13:02 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-09 13:06 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 14:49 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-09 19:05 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-10 02:25 -0700
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-10 04:38 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-10 05:21 -0700
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-10 07:13 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-10 11:38 -0700
Re: C String terminator Ike Naar <ike@sdf.lonestar.org> - 2020-04-11 17:38 +0000
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-11 15:04 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-11 15:16 -0400
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-11 21:45 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-12 04:39 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-12 21:34 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-12 14:38 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-13 11:13 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-13 08:24 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-11 15:08 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-09 09:53 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-07 14:35 -0400
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-06 21:04 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 01:16 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 02:08 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 02:19 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 08:42 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 10:39 -0700
Re: C String terminator scott@slp53.sl.home (Scott Lurndal) - 2020-04-07 17:45 +0000
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-07 14:40 -0400
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 11:03 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 11:14 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 12:19 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 12:02 +0100
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-07 06:27 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 07:44 -0700
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-07 08:30 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 00:27 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 12:50 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 05:25 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 23:52 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 03:15 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-08 21:28 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 15:40 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-09 00:31 +0100
Re: C String terminator Ike Naar <ike@sdf.lonestar.org> - 2020-04-07 21:40 +0000
Re: C String terminator luser droog <luser.droog@gmail.com> - 2020-04-06 09:41 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 12:46 -0700
Re: C String terminator Guillaume <message@bottle.org> - 2020-04-07 17:17 +0200
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-09 07:23 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-04 22:32 +0100
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-03 21:59 +0200
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 23:48 -0400
Jared Kushner would be proud... (Was: C String terminator) gazelle@shell.xmission.com (Kenny McCormack) - 2020-04-04 09:00 +0000
Re: Jared Kushner would be proud... (Was: C String terminator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 02:45 -0700
Re: Jared Kushner would be proud... (Was: C String terminator) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-04 10:24 +0000
Re: Jared Kushner would be proud... (Was: C String terminator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 03:55 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 13:27 -0700
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 13:52 -0700
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 14:12 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 15:12 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 15:03 -0700
Re: Jared Kushner would be proud... Richard Damon <Richard@Damon-Family.org> - 2020-04-04 18:46 -0400
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 01:53 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-05 02:33 -0700
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 06:43 -0700
Re: Jared Kushner would be proud... (Was: C String terminator) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 19:48 -0700
Re: Jared Kushner would be proud... (Was: C String terminator) James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-04 06:37 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-04 18:36 +0200
Re: C String terminator dave_thompson_2@comcast.net - 2020-05-02 15:13 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 09:41 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 10:33 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 11:14 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 11:34 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 14:48 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 12:10 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 13:24 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 23:59 -0400
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-03 22:05 +0100
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 20:34 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 02:05 -0700
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-09 07:35 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 07:38 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-17 01:55 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-17 09:52 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 11:29 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 18:21 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-16 10:50 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 20:50 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-16 14:17 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 09:59 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 10:15 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-18 21:42 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-19 22:13 -0800
Re: C String terminator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-21 19:49 +0100
Re: C String terminator John Bode <jfbode1029@gmail.com> - 2020-01-21 15:33 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-21 23:19 -0800
Re: C String terminator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 08:39 +0100
Re: C String terminator chad <cdalten@gmail.com> - 2020-01-22 06:59 -0800
Re: C String terminator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 18:44 +0100
Page 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2020-01-16 23:57 +0000 |
| Subject | Yes, Ben makes house calls (Was: C String terminator) |
| Message-ID | <qvqt9r$tha$1@news.xmission.com> |
| In reply to | #149209 |
In article <877e1rc6f7.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
...
>I don't know. That depends on your compiler, OS and so on and that
>obviously different to mine sice whole process of compiling and running
>is shown above.
I think with T, you're going to have to go to his house and show him how to
compile and run the program. Nothing else will do.
--
The difference between communism and capitalism?
In capitalism, man exploits man. In communism, it's the other way around.
- Daniel Bell, The End of Ideology (1960) -
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-17 11:28 -0800 |
| Message-ID | <qvt1s7$jfr$1@dont-email.me> |
| In reply to | #149209 |
On 2020-01-16 15:45, Ben Bacarisse wrote:
> T <T@invalid.invalid> writes:
>
>> On 2020-01-16 12:17, Ben Bacarisse wrote:
>>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>>
>>>> T <T@invalid.invalid> writes:
>>>>
>>>>> On 2020-01-16 05:31, Ben Bacarisse wrote:
>>>>>> You have not yet achieved your goal! Can you submit a patch to the
>>>>>> documentation?
>>>>>
>>>>> I got shot down by the first responder before I even
>>>>> got that far. If the example works, then there is
>>>>> not bug. The correspondence was with him
>>>>
>>>> Then you need to concoct a simple example that does not work.
>>>
>>> That's not always easy. I may be very hard indeed. Here's a C example:
>>>
>>> $ cat t.c
>>> #include <stdio.h>
>>>
>>> void foo(const char *s)
>>> {
>>> printf("[%s]\n", s);
>>> }
>>>
>>> int main(void)
>>> {
>>> char str[3] = "FOO";
>>> foo(str); // DANGER, WILL ROBINSON!
>>> }
>>> $ gcc -o t t.c
>>> $ ./t
>>> [FOO]
>>>
>>> All must be well because it works! It's even harder when the C function
>>> is called from a high-level language where there is far less chance to
>>> control data layout etc.
>>>
>>> People should accept a simple, well-argued claim that something is
>>> wrong.
>>>
>> I am a total idiot when it comes to C. How do
>> I run this?
>
> I don't know. That depends on your compiler, OS and so on and that
> obviously different to mine sice whole process of compiling and running
> is shown above.
I have Fedora Linux at my disposal, which has
a gcc c compiler.
Nothing I know of on the Windows side.
>
>> Does char str[3] = "FOO"; mean there cells (bytes?)
>> or 4 [0..3]?
>
> char is C's name for a byte. The number in an array type is the number
> of objects in the array, so str is an array or three bytes, indexed from
> 0 to 2 inclusive.
>
:-)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-01-17 20:46 +0000 |
| Message-ID | <87v9p9bylk.fsf@bsb.me.uk> |
| In reply to | #149229 |
T <T@invalid.invalid> writes: > On 2020-01-16 15:45, Ben Bacarisse wrote: >> T <T@invalid.invalid> writes: >> >>> On 2020-01-16 12:17, Ben Bacarisse wrote: <cut> >>>> $ gcc -o t t.c >>>> $ ./t <cut> >>> I am a total idiot when it comes to C. How do >>> I run this? >> >> I don't know. That depends on your compiler, OS and so on and that >> obviously different to mine sice whole process of compiling and running >> is shown above. > > I have Fedora Linux at my disposal, which has > a gcc c compiler. Then I am baffled. I showed both the gcc command to compile the code, and the command to run it. I've removed everything else so you can see them. <cut> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-17 12:48 -0800 |
| Message-ID | <qvt6iq$j73$1@dont-email.me> |
| In reply to | #149232 |
On 2020-01-17 12:46, Ben Bacarisse wrote: > T <T@invalid.invalid> writes: > >> On 2020-01-16 15:45, Ben Bacarisse wrote: >>> T <T@invalid.invalid> writes: >>> >>>> On 2020-01-16 12:17, Ben Bacarisse wrote: > <cut> >>>>> $ gcc -o t t.c >>>>> $ ./t > <cut> >>>> I am a total idiot when it comes to C. How do >>>> I run this? >>> >>> I don't know. That depends on your compiler, OS and so on and that >>> obviously different to mine sice whole process of compiling and running >>> is shown above. >> >> I have Fedora Linux at my disposal, which has >> a gcc c compiler. > > Then I am baffled. I showed both the gcc command to compile the code, > and the command to run it. I've removed everything else so you can see > them. > > <cut> > Ben! I am an idiot when it comes to C. You got to start out like I am a total noob!
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-17 12:54 -0800 |
| Message-ID | <qvt6ts$l0m$1@dont-email.me> |
| In reply to | #149233 |
On 2020-01-17 12:48, T wrote:
> On 2020-01-17 12:46, Ben Bacarisse wrote:
>> T <T@invalid.invalid> writes:
>>
>>> On 2020-01-16 15:45, Ben Bacarisse wrote:
>>>> T <T@invalid.invalid> writes:
>>>>
>>>>> On 2020-01-16 12:17, Ben Bacarisse wrote:
>> <cut>
>>>>>> $ gcc -o t t.c
>>>>>> $ ./t
>> <cut>
>>>>> I am a total idiot when it comes to C. How do
>>>>> I run this?
>>>>
>>>> I don't know. That depends on your compiler, OS and so on and that
>>>> obviously different to mine sice whole process of compiling and running
>>>> is shown above.
>>>
>>> I have Fedora Linux at my disposal, which has
>>> a gcc c compiler.
>>
>> Then I am baffled. I showed both the gcc command to compile the code,
>> and the command to run it. I've removed everything else so you can see
>> them.
>>
>> <cut>
>>
>
> Ben! I am an idiot when it comes to C. You
> got to start out like I am a total noob!
Okay, I looked at it from a bash standpoint instead
of a mystery language I had no clue about. And I
feel dumb. You were very precise!
$ cd C
$ vi t.c
$ gcc -o t t.c
$ t
[FOOp@]
Question: why did I get
[FOOp@]
and you got
[FOO]
?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-17 21:02 +0000 |
| Message-ID | <FhpUF.71833$co3.19408@fx11.am4> |
| In reply to | #149234 |
On 17/01/2020 20:54, T wrote: > On 2020-01-17 12:48, T wrote: >> >> Ben! I am an idiot when it comes to C. You >> got to start out like I am a total noob! > > Okay, I looked at it from a bash standpoint instead > of a mystery language I had no clue about. And I > feel dumb. You were very precise! > > $ cd C > $ vi t.c > $ gcc -o t t.c > $ t > [FOOp@] > > > Question: why did I get > [FOOp@] > > and you got > [FOO] > ? Maybe you need a 0 terminator byte at the end of your "FOO" string. How else will printf know how long it is? All it has is a pointer to the 'F' character at the start. Presumably, on one computer, there happened to be zero immediately after the second 'O'; while on yours, "FOO" happened to be followed by 'p' and '@' before it encountered a zero. (Haven't read the thread; perhaps it's been mentioned already...)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-17 21:21 +0000 |
| Message-ID | <AzpUF.126441$QS6.40223@fx02.am4> |
| In reply to | #149235 |
On 17/01/2020 21:02, Bart wrote:
> On 17/01/2020 20:54, T wrote:
>> On 2020-01-17 12:48, T wrote:
>
>>>
>>> Ben! I am an idiot when it comes to C. You
>>> got to start out like I am a total noob!
>>
>> Okay, I looked at it from a bash standpoint instead
>> of a mystery language I had no clue about. And I
>> feel dumb. You were very precise!
>>
>> $ cd C
>> $ vi t.c
>> $ gcc -o t t.c
>> $ t
>> [FOOp@]
>>
>>
>> Question: why did I get
>> [FOOp@]
>>
>> and you got
>> [FOO]
>> ?
>
> Maybe you need a 0 terminator byte at the end of your "FOO" string.
>
> How else will printf know how long it is? All it has is a pointer to the
> 'F' character at the start.
>
> Presumably, on one computer, there happened to be zero immediately after
> the second 'O'; while on yours, "FOO" happened to be followed by 'p' and
> '@' before it encountered a zero.
>
> (Haven't read the thread; perhaps it's been mentioned already...)
BTW I changed the test program to this:
---------------------------------
#include <stdio.h>
void foo(const char *s)
{
for (int i=0; i<10; ++i)
printf("%d ",*s++);
puts("");
}
int main(void)
{
char str[3] = "FOO";
foo(str);
}
---------------------------------
This prints the 3 characters codes of F,O,O in the string, plus 7 bytes
that follow. Results on various compilers are as follows:
bcc: 70 79 79 0 0 0 0 0 0 0
tcc: 70 79 79 80 -1 18 0 0 0 0
gcc -O0: 70 79 79 112 -14 48 0 0 0 0
gcc -O3: 70 79 79 2 0 0 0 0 0 0
lcc: 70 79 79 0 0 0 0 0 0 0
dmc: 70 79 79 0 -120 -1 24 0 25 33
clang -O0: 70 79 79 16 6 64 0 0 0 0
clang -O2: 70 79 79 0 48 -120 73 6 -19 127
msvc: 70 79 79 -29 -9 127 0 0 0 0
The 70, 79, 79 are the F, O and O codes. When those 3 happen to be
followed by 0, then it will appear to work.
That is 4 out of 9, but the other 5 won't work. What follows after FOO
is undefined and could be anything, although a random 0 is common.
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-17 13:35 -0800 |
| Message-ID | <qvt9ai$5tm$1@dont-email.me> |
| In reply to | #149237 |
On 2020-01-17 13:21, Bart wrote:
> On 17/01/2020 21:02, Bart wrote:
>> On 17/01/2020 20:54, T wrote:
>>> On 2020-01-17 12:48, T wrote:
>>
>>>>
>>>> Ben! I am an idiot when it comes to C. You
>>>> got to start out like I am a total noob!
>>>
>>> Okay, I looked at it from a bash standpoint instead
>>> of a mystery language I had no clue about. And I
>>> feel dumb. You were very precise!
>>>
>>> $ cd C
>>> $ vi t.c
>>> $ gcc -o t t.c
>>> $ t
>>> [FOOp@]
>>>
>>>
>>> Question: why did I get
>>> [FOOp@]
>>>
>>> and you got
>>> [FOO]
>>> ?
>>
>> Maybe you need a 0 terminator byte at the end of your "FOO" string.
>>
>> How else will printf know how long it is? All it has is a pointer to
>> the 'F' character at the start.
>>
>> Presumably, on one computer, there happened to be zero immediately
>> after the second 'O'; while on yours, "FOO" happened to be followed by
>> 'p' and '@' before it encountered a zero.
>>
>> (Haven't read the thread; perhaps it's been mentioned already...)
>
> BTW I changed the test program to this:
>
> ---------------------------------
> #include <stdio.h>
>
> void foo(const char *s)
> {
> for (int i=0; i<10; ++i)
> printf("%d ",*s++);
> puts("");
>
> }
>
> int main(void)
> {
> char str[3] = "FOO";
> foo(str);
> }
> ---------------------------------
>
> This prints the 3 characters codes of F,O,O in the string, plus 7 bytes
> that follow. Results on various compilers are as follows:
>
> bcc: 70 79 79 0 0 0 0 0 0 0
> tcc: 70 79 79 80 -1 18 0 0 0 0
> gcc -O0: 70 79 79 112 -14 48 0 0 0 0
> gcc -O3: 70 79 79 2 0 0 0 0 0 0
> lcc: 70 79 79 0 0 0 0 0 0 0
> dmc: 70 79 79 0 -120 -1 24 0 25 33
> clang -O0: 70 79 79 16 6 64 0 0 0 0
> clang -O2: 70 79 79 0 48 -120 73 6 -19 127
> msvc: 70 79 79 -29 -9 127 0 0 0 0
>
> The 70, 79, 79 are the F, O and O codes. When those 3 happen to be
> followed by 0, then it will appear to work.
>
> That is 4 out of 9, but the other 5 won't work. What follows after FOO
> is undefined and could be anything, although a random 0 is common.
>
Oh my gosh, I have now compiled TWO C programs.
I AM DANGEROUS!!!!
:-)
vi t2.c
$ gcc -o t2 t2.c
$ t2
70 79 79 -80 17 64 0 0 0 0
Okay, I know you guys said this clearly and directly,
but I can be thick as a stone at times: is the
-80 17 64 0 0 0 0
an example of careening until a proper terminator
is found?
-T
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-17 13:44 -0800 |
| Message-ID | <qvt9ri$8ui$1@dont-email.me> |
| In reply to | #149239 |
On 2020-01-17 13:35, T wrote:
> On 2020-01-17 13:21, Bart wrote:
>> On 17/01/2020 21:02, Bart wrote:
>>> On 17/01/2020 20:54, T wrote:
>>>> On 2020-01-17 12:48, T wrote:
>>>
>>>>>
>>>>> Ben! I am an idiot when it comes to C. You
>>>>> got to start out like I am a total noob!
>>>>
>>>> Okay, I looked at it from a bash standpoint instead
>>>> of a mystery language I had no clue about. And I
>>>> feel dumb. You were very precise!
>>>>
>>>> $ cd C
>>>> $ vi t.c
>>>> $ gcc -o t t.c
>>>> $ t
>>>> [FOOp@]
>>>>
>>>>
>>>> Question: why did I get
>>>> [FOOp@]
>>>>
>>>> and you got
>>>> [FOO]
>>>> ?
>>>
>>> Maybe you need a 0 terminator byte at the end of your "FOO" string.
>>>
>>> How else will printf know how long it is? All it has is a pointer to
>>> the 'F' character at the start.
>>>
>>> Presumably, on one computer, there happened to be zero immediately
>>> after the second 'O'; while on yours, "FOO" happened to be followed
>>> by 'p' and '@' before it encountered a zero.
>>>
>>> (Haven't read the thread; perhaps it's been mentioned already...)
>>
>> BTW I changed the test program to this:
>>
>> ---------------------------------
>> #include <stdio.h>
>>
>> void foo(const char *s)
>> {
>> for (int i=0; i<10; ++i)
>> printf("%d ",*s++);
>> puts("");
>>
>> }
>>
>> int main(void)
>> {
>> char str[3] = "FOO";
>> foo(str);
>> }
>> ---------------------------------
>>
>> This prints the 3 characters codes of F,O,O in the string, plus 7
>> bytes that follow. Results on various compilers are as follows:
>>
>> bcc: 70 79 79 0 0 0 0 0 0 0
>> tcc: 70 79 79 80 -1 18 0 0 0 0
>> gcc -O0: 70 79 79 112 -14 48 0 0 0 0
>> gcc -O3: 70 79 79 2 0 0 0 0 0 0
>> lcc: 70 79 79 0 0 0 0 0 0 0
>> dmc: 70 79 79 0 -120 -1 24 0 25 33
>> clang -O0: 70 79 79 16 6 64 0 0 0 0
>> clang -O2: 70 79 79 0 48 -120 73 6 -19 127
>> msvc: 70 79 79 -29 -9 127 0 0 0 0
>>
>> The 70, 79, 79 are the F, O and O codes. When those 3 happen to be
>> followed by 0, then it will appear to work.
>>
>> That is 4 out of 9, but the other 5 won't work. What follows after FOO
>> is undefined and could be anything, although a random 0 is common.
>>
>
>
> Oh my gosh, I have now compiled TWO C programs.
> I AM DANGEROUS!!!!
>
> :-)
>
> vi t2.c
> $ gcc -o t2 t2.c
> $ t2
> 70 79 79 -80 17 64 0 0 0 0
>
> Okay, I know you guys said this clearly and directly,
> but I can be thick as a stone at times: is the
>
> -80 17 64 0 0 0 0
>
> an example of careening until a proper terminator
> is found?
>
> -T
>
>
yes it is careening. Sorry I am so slow.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-17 15:03 -0800 |
| Message-ID | <af6fb832-4a0c-44aa-9df5-30593993e13e@googlegroups.com> |
| In reply to | #149237 |
W dniu piątek, 17 stycznia 2020 22:21:44 UTC+1 użytkownik Bart napisał:
> On 17/01/2020 21:02, Bart wrote:
> > On 17/01/2020 20:54, T wrote:
> >> On 2020-01-17 12:48, T wrote:
> >
> >>>
> >>> Ben! I am an idiot when it comes to C. You
> >>> got to start out like I am a total noob!
> >>
> >> Okay, I looked at it from a bash standpoint instead
> >> of a mystery language I had no clue about. And I
> >> feel dumb. You were very precise!
> >>
> >> $ cd C
> >> $ vi t.c
> >> $ gcc -o t t.c
> >> $ t
> >> [FOOp@]
> >>
> >>
> >> Question: why did I get
> >> [FOOp@]
> >>
> >> and you got
> >> [FOO]
> >> ?
> >
> > Maybe you need a 0 terminator byte at the end of your "FOO" string.
> >
> > How else will printf know how long it is? All it has is a pointer to the
> > 'F' character at the start.
> >
> > Presumably, on one computer, there happened to be zero immediately after
> > the second 'O'; while on yours, "FOO" happened to be followed by 'p' and
> > '@' before it encountered a zero.
> >
> > (Haven't read the thread; perhaps it's been mentioned already...)
>
> BTW I changed the test program to this:
>
> ---------------------------------
> #include <stdio.h>
>
> void foo(const char *s)
> {
> for (int i=0; i<10; ++i)
> printf("%d ",*s++);
> puts("");
>
> }
>
> int main(void)
> {
> char str[3] = "FOO";
> foo(str);
> }
> ---------------------------------
>
> This prints the 3 characters codes of F,O,O in the string, plus 7 bytes
> that follow. Results on various compilers are as follows:
>
> bcc: 70 79 79 0 0 0 0 0 0 0
> tcc: 70 79 79 80 -1 18 0 0 0 0
> gcc -O0: 70 79 79 112 -14 48 0 0 0 0
> gcc -O3: 70 79 79 2 0 0 0 0 0 0
> lcc: 70 79 79 0 0 0 0 0 0 0
> dmc: 70 79 79 0 -120 -1 24 0 25 33
> clang -O0: 70 79 79 16 6 64 0 0 0 0
> clang -O2: 70 79 79 0 48 -120 73 6 -19 127
> msvc: 70 79 79 -29 -9 127 0 0 0 0
>
> The 70, 79, 79 are the F, O and O codes. When those 3 happen to be
> followed by 0, then it will appear to work.
>
> That is 4 out of 9, but the other 5 won't work. What follows after FOO
> is undefined and could be anything, although a random 0 is common.
i think most probably at the end of this is next data chunk, when .data section is build things are placed one by one usually, though some maybe may be aligned at least to 4
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-17 15:06 -0800 |
| Message-ID | <07a8df8c-4ef0-4e98-a9b4-4750d606f714@googlegroups.com> |
| In reply to | #149245 |
W dniu sobota, 18 stycznia 2020 00:03:26 UTC+1 użytkownik fir napisał:
> W dniu piątek, 17 stycznia 2020 22:21:44 UTC+1 użytkownik Bart napisał:
> > On 17/01/2020 21:02, Bart wrote:
> > > On 17/01/2020 20:54, T wrote:
> > >> On 2020-01-17 12:48, T wrote:
> > >
> > >>>
> > >>> Ben! I am an idiot when it comes to C. You
> > >>> got to start out like I am a total noob!
> > >>
> > >> Okay, I looked at it from a bash standpoint instead
> > >> of a mystery language I had no clue about. And I
> > >> feel dumb. You were very precise!
> > >>
> > >> $ cd C
> > >> $ vi t.c
> > >> $ gcc -o t t.c
> > >> $ t
> > >> [FOOp@]
> > >>
> > >>
> > >> Question: why did I get
> > >> [FOOp@]
> > >>
> > >> and you got
> > >> [FOO]
> > >> ?
> > >
> > > Maybe you need a 0 terminator byte at the end of your "FOO" string.
> > >
> > > How else will printf know how long it is? All it has is a pointer to the
> > > 'F' character at the start.
> > >
> > > Presumably, on one computer, there happened to be zero immediately after
> > > the second 'O'; while on yours, "FOO" happened to be followed by 'p' and
> > > '@' before it encountered a zero.
> > >
> > > (Haven't read the thread; perhaps it's been mentioned already...)
> >
> > BTW I changed the test program to this:
> >
> > ---------------------------------
> > #include <stdio.h>
> >
> > void foo(const char *s)
> > {
> > for (int i=0; i<10; ++i)
> > printf("%d ",*s++);
> > puts("");
> >
> > }
> >
> > int main(void)
> > {
> > char str[3] = "FOO";
> > foo(str);
> > }
> > ---------------------------------
> >
> > This prints the 3 characters codes of F,O,O in the string, plus 7 bytes
> > that follow. Results on various compilers are as follows:
> >
> > bcc: 70 79 79 0 0 0 0 0 0 0
> > tcc: 70 79 79 80 -1 18 0 0 0 0
> > gcc -O0: 70 79 79 112 -14 48 0 0 0 0
> > gcc -O3: 70 79 79 2 0 0 0 0 0 0
> > lcc: 70 79 79 0 0 0 0 0 0 0
> > dmc: 70 79 79 0 -120 -1 24 0 25 33
> > clang -O0: 70 79 79 16 6 64 0 0 0 0
> > clang -O2: 70 79 79 0 48 -120 73 6 -19 127
> > msvc: 70 79 79 -29 -9 127 0 0 0 0
> >
> > The 70, 79, 79 are the F, O and O codes. When those 3 happen to be
> > followed by 0, then it will appear to work.
> >
> > That is 4 out of 9, but the other 5 won't work. What follows after FOO
> > is undefined and could be anything, although a random 0 is common.
>
> i think most probably at the end of this is next data chunk, when .data section is build things are placed one by one usually, though some maybe may be aligned at least to 4
though here what is after might be just pice of stack (i didnt looked at code that its on stack) and the oryginal might be stored in .data also
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.lonestar.org> |
|---|---|
| Date | 2020-01-18 07:30 +0000 |
| Message-ID | <slrn3s94r25d3f.qtq.ike@sdf.lonestar.org> |
| In reply to | #149237 |
On 2020-01-17, Bart <bc@freeuk.com> wrote:
> [...]
> ---------------------------------
> #include <stdio.h>
>
> void foo(const char *s)
> {
> for (int i=0; i<10; ++i)
> printf("%d ",*s++);
> puts("");
>
> }
>
> int main(void)
> {
> char str[3] = "FOO";
> foo(str);
> }
> ---------------------------------
>
> This prints the 3 characters codes of F,O,O in the string, plus 7 bytes
> that follow. Results on various compilers are as follows:
>
> bcc: 70 79 79 0 0 0 0 0 0 0
> tcc: 70 79 79 80 -1 18 0 0 0 0
> gcc -O0: 70 79 79 112 -14 48 0 0 0 0
> gcc -O3: 70 79 79 2 0 0 0 0 0 0
> lcc: 70 79 79 0 0 0 0 0 0 0
> dmc: 70 79 79 0 -120 -1 24 0 25 33
> clang -O0: 70 79 79 16 6 64 0 0 0 0
> clang -O2: 70 79 79 0 48 -120 73 6 -19 127
> msvc: 70 79 79 -29 -9 127 0 0 0 0
>
> The 70, 79, 79 are the F, O and O codes. When those 3 happen to be
> followed by 0, then it will appear to work.
>
> That is 4 out of 9, but the other 5 won't work. What follows after FOO
> is undefined and could be anything, although a random 0 is common.
It may also appear to work for character codes that produce no visible output.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2020-01-17 16:06 -0500 |
| Message-ID | <qvt7l5$q6n$1@dont-email.me> |
| In reply to | #149234 |
T wrote:
> On 2020-01-17 12:48, T wrote:
>> On 2020-01-17 12:46, Ben Bacarisse wrote:
>>> T <T@invalid.invalid> writes:
>>>
>>>> On 2020-01-16 15:45, Ben Bacarisse wrote:
>>>>> T <T@invalid.invalid> writes:
>>>>>
>>>>>> On 2020-01-16 12:17, Ben Bacarisse wrote:
>>> <cut>
>>>>>>> $ gcc -o t t.c
>>>>>>> $ ./t
>>> <cut>
>>>>>> I am a total idiot when it comes to C. How do
>>>>>> I run this?
>>>>>
>>>>> I don't know. That depends on your compiler, OS and so on and that
>>>>> obviously different to mine sice whole process of compiling and
>>>>> running is shown above.
>>>>
>>>> I have Fedora Linux at my disposal, which has
>>>> a gcc c compiler.
>>>
>>> Then I am baffled. I showed both the gcc command to compile the code,
>>> and the command to run it. I've removed everything else so you can see
>>> them.
>>>
>>> <cut>
>>>
>>
>> Ben! I am an idiot when it comes to C. You
>> got to start out like I am a total noob!
>
> Okay, I looked at it from a bash standpoint instead
> of a mystery language I had no clue about. And I
> feel dumb. You were very precise!
>
> $ cd C
> $ vi t.c
> $ gcc -o t t.c
> $ t
> [FOOp@]
>
>
> Question: why did I get
> [FOOp@]
>
> and you got
> [FOO]
> ?
Because, as implied by Ben's source code comment, the program given
>>>>>>> #include <stdio.h>
>>>>>>>
>>>>>>> void foo(const char *s)
>>>>>>> {
>>>>>>> printf("[%s]\n", s);
>>>>>>> }
>>>>>>>
>>>>>>> int main(void)
>>>>>>> {
>>>>>>> char str[3] = "FOO";
>>>>>>> foo(str); // DANGER, WILL ROBINSON!
>>>>>>> }
invokes undefined behaviour.
It does this by passing an array of three characters (ultimately) to
printf(), which /expects/ a C "string" as it's first argument. The array of
three characters passed /does not/ represent a C "string", as it lacks the
requisite nul ('\0') terminator that all C "string"s have.
In Ben's example execution, his code was fortunate enough to find a nul
character in unallocated, uninitialized, (and thus undependable) memory
immediately following the three character array. /His/ execution, then,
acted as if that three character array was, indeed, a C "string", and acted
accordingly.
In /your/ example execution, on the other hand, your code was unfortunate
enough to /not/ encounter a nul character until somewhat after the end of
the three character array (again, somewhere in unallocated, uninitialized,
(and thus undependable) memory). /Your/ execution emitted an additional
character /that was not in the original array/. /Your/ execution was
analogous to the situation you attempt to describe to the Raku maintainers,
and represents the likely outcome of a Raku NativeCall call to a C function
that /expects/ a C "string".
HTH
--
Lew Pitcher
"In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2020-01-17 16:23 -0500 |
| Message-ID | <qvt8kp$v1f$1@dont-email.me> |
| In reply to | #149236 |
Two minor corrections
Lew Pitcher wrote:
> T wrote:
>
>> On 2020-01-17 12:48, T wrote:
>>> On 2020-01-17 12:46, Ben Bacarisse wrote:
>>>> T <T@invalid.invalid> writes:
>>>>
>>>>> On 2020-01-16 15:45, Ben Bacarisse wrote:
>>>>>> T <T@invalid.invalid> writes:
>>>>>>
>>>>>>> On 2020-01-16 12:17, Ben Bacarisse wrote:
>>>> <cut>
>>>>>>>> $ gcc -o t t.c
>>>>>>>> $ ./t
>>>> <cut>
>>>>>>> I am a total idiot when it comes to C. How do
>>>>>>> I run this?
>>>>>>
>>>>>> I don't know. That depends on your compiler, OS and so on and that
>>>>>> obviously different to mine sice whole process of compiling and
>>>>>> running is shown above.
>>>>>
>>>>> I have Fedora Linux at my disposal, which has
>>>>> a gcc c compiler.
>>>>
>>>> Then I am baffled. I showed both the gcc command to compile the code,
>>>> and the command to run it. I've removed everything else so you can see
>>>> them.
>>>>
>>>> <cut>
>>>>
>>>
>>> Ben! I am an idiot when it comes to C. You
>>> got to start out like I am a total noob!
>>
>> Okay, I looked at it from a bash standpoint instead
>> of a mystery language I had no clue about. And I
>> feel dumb. You were very precise!
>>
>> $ cd C
>> $ vi t.c
>> $ gcc -o t t.c
>> $ t
>> [FOOp@]
>>
>>
>> Question: why did I get
>> [FOOp@]
>>
>> and you got
>> [FOO]
>> ?
>
> Because, as implied by Ben's source code comment, the program given
>>>>>>>> #include <stdio.h>
>>>>>>>>
>>>>>>>> void foo(const char *s)
>>>>>>>> {
>>>>>>>> printf("[%s]\n", s);
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main(void)
>>>>>>>> {
>>>>>>>> char str[3] = "FOO";
>>>>>>>> foo(str); // DANGER, WILL ROBINSON!
>>>>>>>> }
> invokes undefined behaviour.
>
> It does this by passing an array of three characters (ultimately) to
> printf(), which /expects/ a C "string" as it's first argument. The array
Correction #1: in this case, the critical point is that, here, printf()
expects a C "string" as it's second argument (as well as the first argument,
which is the given format string "[%s]\n").
> of three characters passed /does not/ represent a C "string", as it lacks
> the requisite nul ('\0') terminator that all C "string"s have.
>
> In Ben's example execution, his code was fortunate enough to find a nul
> character in unallocated, uninitialized, (and thus undependable) memory
> immediately following the three character array. /His/ execution, then,
> acted as if that three character array was, indeed, a C "string", and
> acted accordingly.
>
> In /your/ example execution, on the other hand, your code was unfortunate
> enough to /not/ encounter a nul character until somewhat after the end of
> the three character array (again, somewhere in unallocated, uninitialized,
> (and thus undependable) memory). /Your/ execution emitted an additional
> character
Correction #2: your execution emitted an additional two characters that were
not in the original array.
> /that was not in the original array/. /Your/ execution was
> analogous to the situation you attempt to describe to the Raku
> maintainers, and represents the likely outcome of a Raku NativeCall call
> to a C function that /expects/ a C "string".
>
> HTH
--
Lew Pitcher
Gotta stop skimming code.
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-17 13:37 -0800 |
| Message-ID | <qvt9e2$5tm$2@dont-email.me> |
| In reply to | #149238 |
On 2020-01-17 13:23, Lew Pitcher wrote:
> Two minor corrections
>
> Lew Pitcher wrote:
>
>> T wrote:
>>
>>> On 2020-01-17 12:48, T wrote:
>>>> On 2020-01-17 12:46, Ben Bacarisse wrote:
>>>>> T <T@invalid.invalid> writes:
>>>>>
>>>>>> On 2020-01-16 15:45, Ben Bacarisse wrote:
>>>>>>> T <T@invalid.invalid> writes:
>>>>>>>
>>>>>>>> On 2020-01-16 12:17, Ben Bacarisse wrote:
>>>>> <cut>
>>>>>>>>> $ gcc -o t t.c
>>>>>>>>> $ ./t
>>>>> <cut>
>>>>>>>> I am a total idiot when it comes to C. How do
>>>>>>>> I run this?
>>>>>>>
>>>>>>> I don't know. That depends on your compiler, OS and so on and that
>>>>>>> obviously different to mine sice whole process of compiling and
>>>>>>> running is shown above.
>>>>>>
>>>>>> I have Fedora Linux at my disposal, which has
>>>>>> a gcc c compiler.
>>>>>
>>>>> Then I am baffled. I showed both the gcc command to compile the code,
>>>>> and the command to run it. I've removed everything else so you can see
>>>>> them.
>>>>>
>>>>> <cut>
>>>>>
>>>>
>>>> Ben! I am an idiot when it comes to C. You
>>>> got to start out like I am a total noob!
>>>
>>> Okay, I looked at it from a bash standpoint instead
>>> of a mystery language I had no clue about. And I
>>> feel dumb. You were very precise!
>>>
>>> $ cd C
>>> $ vi t.c
>>> $ gcc -o t t.c
>>> $ t
>>> [FOOp@]
>>>
>>>
>>> Question: why did I get
>>> [FOOp@]
>>>
>>> and you got
>>> [FOO]
>>> ?
>>
>> Because, as implied by Ben's source code comment, the program given
>>>>>>>>> #include <stdio.h>
>>>>>>>>>
>>>>>>>>> void foo(const char *s)
>>>>>>>>> {
>>>>>>>>> printf("[%s]\n", s);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main(void)
>>>>>>>>> {
>>>>>>>>> char str[3] = "FOO";
>>>>>>>>> foo(str); // DANGER, WILL ROBINSON!
>>>>>>>>> }
>> invokes undefined behaviour.
>>
>> It does this by passing an array of three characters (ultimately) to
>> printf(), which /expects/ a C "string" as it's first argument. The array
>
> Correction #1: in this case, the critical point is that, here, printf()
> expects a C "string" as it's second argument (as well as the first argument,
> which is the given format string "[%s]\n").
>
>> of three characters passed /does not/ represent a C "string", as it lacks
>> the requisite nul ('\0') terminator that all C "string"s have.
>>
>> In Ben's example execution, his code was fortunate enough to find a nul
>> character in unallocated, uninitialized, (and thus undependable) memory
>> immediately following the three character array. /His/ execution, then,
>> acted as if that three character array was, indeed, a C "string", and
>> acted accordingly.
>>
>> In /your/ example execution, on the other hand, your code was unfortunate
>> enough to /not/ encounter a nul character until somewhat after the end of
>> the three character array (again, somewhere in unallocated, uninitialized,
>> (and thus undependable) memory). /Your/ execution emitted an additional
>> character
>
> Correction #2: your execution emitted an additional two characters that were
> not in the original array.
>
>> /that was not in the original array/. /Your/ execution was
>> analogous to the situation you attempt to describe to the Raku
>> maintainers, and represents the likely outcome of a Raku NativeCall call
>> to a C function that /expects/ a C "string".
>>
>> HTH
>
>
Got it!
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-21 04:10 -0800 |
| Message-ID | <861rrtj9hx.fsf@linuxsc.com> |
| In reply to | #149238 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> Two minor corrections
>
> Lew Pitcher wrote:
>
>> T wrote:
>>
>>> On 2020-01-17 12:48, T wrote:
>>>
>>>> On 2020-01-17 12:46, Ben Bacarisse wrote:
>>>>
>>>>> T <T@invalid.invalid> writes:
>>>>>
>>>>>> On 2020-01-16 15:45, Ben Bacarisse wrote:
>>>>>>
>>>>>>> T <T@invalid.invalid> writes:
>>>>>>>
>>>>>>>> On 2020-01-16 12:17, Ben Bacarisse wrote:
>>>>>
>>>>> <cut>
>>>>>
>>>>>>>>> $ gcc -o t t.c
>>>>>>>>> $ ./t
>>>>>
>>>>> <cut>
>>>>>
>>>>>>>> I am a total idiot when it comes to C. How do
>>>>>>>> I run this?
>>>>>>>
>>>>>>> I don't know. That depends on your compiler, OS and so on and that
>>>>>>> obviously different to mine sice whole process of compiling and
>>>>>>> running is shown above.
>>>>>>
>>>>>> I have Fedora Linux at my disposal, which has
>>>>>> a gcc c compiler.
>>>>>
>>>>> Then I am baffled. I showed both the gcc command to compile the code,
>>>>> and the command to run it. I've removed everything else so you can see
>>>>> them.
>>>>>
>>>>> <cut>
>>>>
>>>> Ben! I am an idiot when it comes to C. You
>>>> got to start out like I am a total noob!
>>>
>>> Okay, I looked at it from a bash standpoint instead
>>> of a mystery language I had no clue about. And I
>>> feel dumb. You were very precise!
>>>
>>> $ cd C
>>> $ vi t.c
>>> $ gcc -o t t.c
>>> $ t
>>> [FOOp@]
>>>
>>>
>>> Question: why did I get
>>> [FOOp@]
>>>
>>> and you got
>>> [FOO]
>>> ?
>>
>> Because, as implied by Ben's source code comment, the program given
>>
>>>>>>>>> #include <stdio.h>
>>>>>>>>>
>>>>>>>>> void foo(const char *s)
>>>>>>>>> {
>>>>>>>>> printf("[%s]\n", s);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main(void)
>>>>>>>>> {
>>>>>>>>> char str[3] = "FOO";
>>>>>>>>> foo(str); // DANGER, WILL ROBINSON!
>>>>>>>>> }
>>
>> invokes undefined behaviour.
>>
>> It does this by passing an array of three characters (ultimately) to
>> printf(), which /expects/ a C "string" as it's first argument. The array
>
> Correction #1: in this case, the critical point is that, here, printf()
> expects a C "string" as it's second argument (as well as the first argument,
> which is the given format string "[%s]\n").
Technically, that isn't right. A %s conversion specifier requires
as its argument a pointer to the first element of an array of
character type, not a pointer to a string. It is true in this
particular case that the array must have a null character in it to
avoid undefined behavior, but the argument description says "pointer
to array of character type", and does not mention "string".
(Also: the possessive of "it" is "its", with no apostrophe. The
word "it's", with an apostrophe, is a contraction of "it is".)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-21 10:41 -0800 |
| Message-ID | <87d0bc8xf6.fsf@nosuchdomain.example.com> |
| In reply to | #149303 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
[...]
>> Correction #1: in this case, the critical point is that, here, printf()
>> expects a C "string" as it's second argument (as well as the first argument,
>> which is the given format string "[%s]\n").
>
> Technically, that isn't right. A %s conversion specifier requires
> as its argument a pointer to the first element of an array of
> character type, not a pointer to a string. It is true in this
> particular case that the array must have a null character in it to
> avoid undefined behavior, but the argument description says "pointer
> to array of character type", and does not mention "string".
>
> (Also: the possessive of "it" is "its", with no apostrophe. The
> word "it's", with an apostrophe, is a contraction of "it is".)
I believe the reason it's described that way is that %s with a field
width can require a pointer that isn't necessarily a pointer to a
string. For example, this is well defined:
char not_a_string[3] = "foo";
printf("%.3s\n", not_a_string);
The standard *could* have equivalently stated that a pointer to a string
is required when the format contains a "%s" directive, but that would
have made it overly wordy with no clear benefit. A pointer to a string
*is* required for a "%s" directive, but the standard says so only
indirectly.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-02-16 02:25 -0800 |
| Message-ID | <861rquhlqk.fsf@linuxsc.com> |
| In reply to | #149318 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > > [...] > >>> Correction #1: in this case, the critical point is that, here, >>> printf() expects a C "string" as it's second argument (as well as >>> the first argument, which is the given format string "[%s]\n"). >> >> Technically, that isn't right. A %s conversion specifier requires >> as its argument a pointer to the first element of an array of >> character type, not a pointer to a string. It is true in this >> particular case that the array must have a null character in it to >> avoid undefined behavior, but the argument description says "pointer >> to array of character type", and does not mention "string". >> >> (Also: the possessive of "it" is "its", with no apostrophe. The >> word "it's", with an apostrophe, is a contraction of "it is".) > > I believe the reason it's described that way is that %s with a field > width can require a pointer that isn't necessarily a pointer to a > string. [..example..] The passage in question is part of paragraph 8 in section 7.21.6.1. This paragraph describes conversion /specifiers/, not conversion /specifications/. Considered as a conversion /specifier/, an 's' specifier takes a pointer to (an initial element in) an array of characters (which are wide characters if an 'l' length modifier is present, or regular characters if not). The wording used most likely reflects wanting to describe the 's' conversion specifier generally, rather than particular conversion specifications that use an 's' specifier. Incidentally, it's precision, not field width. > The standard *could* have equivalently stated that a pointer to a > string is required when the format contains a "%s" directive, but > that would have made it overly wordy with no clear benefit. More significantly, it would have been inconsistent with other parts of the same paragraph, which defines the semantics of conversion specifiers, not of whole conversion specifications (which are also called directives). It would be out of place in this paragraph to talk about a particular directive that contains an 's' specifier (and besides which is incomplete, because there are other cases where the character array needs to have a null character). > A pointer to a string *is* required for a "%s" directive, but the > standard says so only indirectly. I have some quibbles about the wording here, but more importantly I think this is a bad way to take in what the Standard does say. What the Standard does say is that an 's' specifier takes a pointer to an array of character type, which in some situations much include a null character within the array (and a %s specification is one of those). It can be convenient to think of a %s directive as needing a string argument, but the Standard doesn't say anything about strings in its description of 's' specifiers, only arrays of character type. In some cases an array argument needs to contain a string, but the argument is still the array, not the string.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-02-16 14:24 -0800 |
| Message-ID | <87wo8m9nm4.fsf@nosuchdomain.example.com> |
| In reply to | #150040 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> A pointer to a string *is* required for a "%s" directive, but the
>> standard says so only indirectly.
>
> I have some quibbles about the wording here, but more importantly I
> think this is a bad way to take in what the Standard does say. What
> the Standard does say is that an 's' specifier takes a pointer to an
> array of character type, which in some situations much include a
> null character within the array (and a %s specification is one of
> those).
As you know, and as long as we're being precise, it doesn't take a
pointer to an array of character type. It takes a pointer to char (and
the char in question is treated as an element of an array). The
standard defines a "pointer to a string" as a pointer to the initial
element of a string. It has no such special-case definition for a
"pointer to an array", which already has a distinct meaning.
> It can be convenient to think of a %s directive as needing
> a string argument, but the Standard doesn't say anything about
> strings in its description of 's' specifiers, only arrays of
> character type. In some cases an array argument needs to contain a
> string, but the argument is still the array, not the string.
The argument is a pointer to the initial element of the array. Other
than that, I agree, and that was pretty much my point. The requirements
for the argument corresponding to a "%s" are equivalent to requiring a
pointer to a string, though they're not stated that way (and it would
not be particularly useful to state them that way).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-02-22 08:13 -0800 |
| Message-ID | <86imjyd2hl.fsf@linuxsc.com> |
| In reply to | #150060 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > > [...] > >>> A pointer to a string *is* required for a "%s" directive, but the >>> standard says so only indirectly. >> >> I have some quibbles about the wording here, but more importantly I >> think this is a bad way to take in what the Standard does say. What >> the Standard does say is that an 's' specifier takes a pointer to an >> array of character type, which in some situations much include a >> null character within the array (and a %s specification is one of >> those). > > As you know, and as long as we're being precise, it doesn't take a > pointer to an array of character type. It takes a pointer to char (and > the char in question is treated as an element of an array). [...] Yes, I glossed over the distinction between pointing to an array and pointing to the first element of an array. I thought the meaning would be clear from context. I need to add though that 'char' is not really accurate. The Standard says "character type" and I think it means that, not just 'char'. Furthermore if an 'l' length modifier is present then the array elements are assumed to be of type 'wchar_t'. Both the regular character types and wchar_t fall under the common umbrella of "character type". >> It can be convenient to think of a %s directive as needing >> a string argument, but the Standard doesn't say anything about >> strings in its description of 's' specifiers, only arrays of >> character type. In some cases an array argument needs to contain a >> string, but the argument is still the array, not the string. > > The argument is a pointer to the initial element of the array. Other > than that, I agree, and that was pretty much my point. The requirements > for the argument corresponding to a "%s" are equivalent to requiring a > pointer to a string, though they're not stated that way (and it would > not be particularly useful to state them that way). I'm glad we are essentially in agreement.
[toc] | [prev] | [next] | [standalone]
Page 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web