Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #106814 > unrolled thread
| Started by | acidlategamer@gmail.com |
|---|---|
| First post | 2017-03-23 09:56 -0700 |
| Last post | 2017-03-23 19:02 -0700 |
| Articles | 20 on this page of 213 — 32 participants |
Back to article view | Back to comp.lang.c
My C program does not compile or gives segmentation fault acidlategamer@gmail.com - 2017-03-23 09:56 -0700
Re: My C program does not compile or gives segmentation fault GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-23 18:04 +0100
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-23 17:07 +0000
Re: My C program does not compile or gives segmentation fault acidlategamer@gmail.com - 2017-03-23 10:36 -0700
Re: My C program does not compile or gives segmentation fault acidlategamer@gmail.com - 2017-03-23 10:42 -0700
Re: My C program does not compile or gives segmentation fault GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-23 18:52 +0100
Re: My C program does not compile or gives segmentation fault Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-03-23 12:54 -0600
Re: My C program does not compile or gives segmentation fault GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-24 00:02 +0100
Re: My C program does not compile or gives segmentation fault Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-03-23 17:16 -0600
Re: My C program does not compile or gives segmentation fault GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-24 00:32 +0100
Re: My C program does not compile or gives segmentation fault Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-03-23 11:57 -0600
Re: My C program does not compile or gives segmentation fault acidlategamer@gmail.com - 2017-03-23 11:23 -0700
Re: My C program does not compile or gives segmentation fault Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-03-23 12:53 -0600
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-23 19:00 +0000
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-23 15:59 -0400
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-23 20:40 +0000
Re: My C program does not compile or gives segmentation fault David Brown <david.brown@hesbynett.no> - 2017-03-23 22:06 +0100
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-23 20:43 -0400
Re: My C program does not compile or gives segmentation fault Ian Collins <ian-news@hotmail.com> - 2017-03-24 14:09 +1300
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-23 21:28 -0400
Re: My C program does not compile or gives segmentation fault Ian Collins <ian-news@hotmail.com> - 2017-03-24 14:33 +1300
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 09:23 -0400
Re: My C program does not compile or gives segmentation fault Ian Collins <ian-news@hotmail.com> - 2017-03-25 08:39 +1300
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 20:40 -0400
Re: My C program does not compile or gives segmentation fault Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-03-23 19:48 -0600
Re: My C program does not compile or gives segmentation fault John Bode <jfbode1029@gmail.com> - 2017-03-24 13:32 -0700
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 20:42 -0400
Re: My C program does not compile or gives segmentation fault Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-17 06:30 -0700
Re: My C program does not compile or gives segmentation fault Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-03-23 19:29 -0600
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 10:10 +0000
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 09:26 -0400
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 13:52 +0000
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 10:30 -0400
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 14:37 +0000
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 12:51 -0400
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 18:05 +0000
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 15:09 -0400
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 12:55 -0400
Re: My C program does not compile or gives segmentation fault jameskuyper@verizon.net - 2017-03-24 09:45 -0700
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 12:52 -0400
Re: My C program does not compile or gives segmentation fault jameskuyper@verizon.net - 2017-03-24 10:10 -0700
Re: My C program does not compile or gives segmentation fault David Brown <david.brown@hesbynett.no> - 2017-03-24 18:48 +0100
Re: My C program does not compile or gives segmentation fault James Kuyper <jameskuyper@verizon.net> - 2017-03-24 14:04 -0400
Re: My C program does not compile or gives segmentation fault David Brown <david.brown@hesbynett.no> - 2017-03-24 19:16 +0100
Re: My C program does not compile or gives segmentation fault James Kuyper <jameskuyper@verizon.net> - 2017-03-24 15:10 -0400
Re: My C program does not compile or gives segmentation fault James Kuyper <jameskuyper@verizon.net> - 2017-03-24 15:17 -0400
Re: My C program does not compile or gives segmentation fault David Brown <david.brown@hesbynett.no> - 2017-03-25 00:49 +0100
Re: My C program does not compile or gives segmentation fault James Kuyper <jameskuyper@verizon.net> - 2017-03-24 21:10 -0400
Re: My C program does not compile or gives segmentation fault David Brown <david.brown@hesbynett.no> - 2017-03-25 02:37 +0100
Re: My C program does not compile or gives segmentation fault James Kuyper <jameskuyper@verizon.net> - 2017-03-24 21:45 -0400
Re: My C program does not compile or gives segmentation fault Manfred <noname@invalid.add> - 2017-03-25 15:58 +0100
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-24 12:44 -0700
Re: My C program does not compile or gives segmentation fault supercat@casperkitty.com - 2017-03-24 12:07 -0700
Re: My C program does not compile or gives segmentation fault David Brown <david.brown@hesbynett.no> - 2017-03-25 00:54 +0100
Re: My C program does not compile or gives segmentation fault raltbos@xs4all.nl (Richard Bos) - 2017-03-25 10:16 +0000
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-25 12:32 +0000
Re: My C program does not compile or gives segmentation fault David Brown <david.brown@hesbynett.no> - 2017-03-25 15:17 +0100
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-25 16:32 +0000
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-25 10:15 -0700
Re: My C program does not compile or gives segmentation fault "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-25 14:07 -0400
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-25 18:23 +0000
Re: My C program does not compile or gives segmentation fault Ike Naar <ike@iceland.freeshell.org> - 2017-03-25 18:48 +0000
Re: My C program does not compile or gives segmentation fault Anton Shepelev <anton.txt@gmail.com> - 2017-03-25 23:22 +0300
Re: My C program does not compile or gives segmentation fault Ike Naar <ike@iceland.freeshell.org> - 2017-03-25 20:47 +0000
Re: My C program does not compile or gives segmentation fault Anton Shepelev <anton.txt@gmail.com> - 2017-03-26 15:56 +0300
Re: My C program does not compile or gives segmentation fault Ike Naar <ike@iceland.freeshell.org> - 2017-03-26 18:13 +0000
Re: My C program does not compile or gives segmentation fault David Brown <david.brown@hesbynett.no> - 2017-03-26 17:03 +0200
Re: My C program does not compile or gives segmentation fault Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-25 21:16 +0000
Re: My C program does not compile or gives segmentation fault raltbos@xs4all.nl (Richard Bos) - 2017-03-25 21:28 +0000
Re: My C program does not compile or gives segmentation fault "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-25 19:16 -0400
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-26 08:53 +0100
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-26 02:39 -0700
Re: My C program does not compile or gives segmentation fault Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2017-03-26 11:54 +0200
Re: My C program does not compile or gives segmentation fault Ian Collins <ian-news@hotmail.com> - 2017-03-26 22:57 +1300
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-27 08:18 +0100
Re: My C program does not compile or gives segmentation fault Ike Naar <ike@iceland.freeshell.org> - 2017-03-26 11:37 +0000
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-27 08:19 +0100
Re: My C program does not compile or gives segmentation fault Ike Naar <ike@iceland.freeshell.org> - 2017-03-27 21:53 +0000
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-27 16:22 -0700
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-27 08:18 +0100
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-27 08:49 -0700
Re: My C program does not compile or gives segmentation fault BartC <bc@freeuk.com> - 2017-03-27 16:57 +0100
Re: My C program does not compile or gives segmentation fault GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-27 18:19 +0200
Re: My C program does not compile or gives segmentation fault BartC <bc@freeuk.com> - 2017-03-27 17:47 +0100
Re: My C program does not compile or gives segmentation fault supercat@casperkitty.com - 2017-03-27 09:27 -0700
Re: My C program does not compile or gives segmentation fault BartC <bc@freeuk.com> - 2017-03-27 17:56 +0100
Re: My C program does not compile or gives segmentation fault asetofsymbols@gmail.com - 2017-04-01 12:42 -0700
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-27 09:36 -0700
Re: My C program does not compile or gives segmentation fault scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 17:51 +0000
Re: My C program does not compile or gives segmentation fault "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-27 13:59 -0400
Re: My C program does not compile or gives segmentation fault scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 19:00 +0000
Re: My C program does not compile or gives segmentation fault "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-27 15:13 -0400
Re: My C program does not compile or gives segmentation fault scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 20:05 +0000
Re: My C program does not compile or gives segmentation fault jameskuyper@verizon.net - 2017-03-27 13:14 -0700
Re: My C program does not compile or gives segmentation fault Ike Naar <ike@iceland.freeshell.org> - 2017-03-27 21:28 +0000
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-27 16:21 -0700
Re: My C program does not compile or gives segmentation fault Ian Collins <ian-news@hotmail.com> - 2017-03-28 13:44 +1300
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 08:39 +0100
Re: My C program does not compile or gives segmentation fault raltbos@xs4all.nl (Richard Bos) - 2017-04-03 17:36 +0000
Re: My C program does not compile or gives segmentation fault "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-03 14:02 -0400
Re: My C program does not compile or gives segmentation fault raltbos@xs4all.nl (Richard Bos) - 2017-04-14 11:24 +0000
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-04-14 18:39 +0100
Re: My C program does not compile or gives segmentation fault James Kuyper <jameskuyper@verizon.net> - 2017-04-14 14:38 -0400
Re: My C program does not compile or gives segmentation fault raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:06 +0000
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-04-23 17:38 +0100
Re: My C program does not compile or gives segmentation fault Ken Brody <kenbrody@spamcop.net> - 2017-04-14 13:54 -0400
Re: My C program does not compile or gives segmentation fault James Kuyper <jameskuyper@verizon.net> - 2017-04-14 14:36 -0400
Re: My C program does not compile or gives segmentation fault Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 19:08 -0700
Re: My C program does not compile or gives segmentation fault David Brown <david.brown@hesbynett.no> - 2017-03-26 17:11 +0200
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-27 08:23 +0100
Re: My C program does not compile or gives segmentation fault David Brown <david.brown@hesbynett.no> - 2017-03-27 10:27 +0200
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-27 10:22 +0100
Re: My C program does not compile or gives segmentation fault scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 15:01 +0000
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-27 18:19 +0100
Re: My C program does not compile or gives segmentation fault supercat@casperkitty.com - 2017-03-27 12:37 -0700
Re: My C program does not compile or gives segmentation fault "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-27 15:40 -0400
Re: My C program does not compile or gives segmentation fault Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-27 21:28 +0100
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-27 22:27 +0100
Re: My C program does not compile or gives segmentation fault Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-27 23:37 +0100
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 08:33 +0100
Re: My C program does not compile or gives segmentation fault James Kuyper <jameskuyper@verizon.net> - 2017-03-28 11:21 -0400
Re: My C program does not compile or gives segmentation fault scott@slp53.sl.home (Scott Lurndal) - 2017-03-28 15:38 +0000
Re: My C program does not compile or gives segmentation fault jm.bourguet@gmail.com - 2017-03-28 09:03 -0700
Re: Readabilty of "3 == x" (was: My C program does not compile or gives segmentation fault) Keith Thompson <kst-u@mib.org> - 2017-03-28 09:20 -0700
Re: Readabilty of "3 == x" Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 18:55 +0100
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 18:49 +0100
Re: My C program does not compile or gives segmentation fault "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-28 14:53 -0400
Re: My C program does not compile or gives segmentation fault Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 15:19 -0500
Re: My C program does not compile or gives segmentation fault raltbos@xs4all.nl (Richard Bos) - 2017-04-02 12:49 +0000
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-04-03 17:19 +0100
Re: My C program does not compile or gives segmentation fault jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-03 21:44 +0200
Re: My C program does not compile or gives segmentation fault jameskuyper@verizon.net - 2017-04-03 15:05 -0700
Re: My C program does not compile or gives segmentation fault jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-04 01:19 +0200
Re: My C program does not compile or gives segmentation fault Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-04 00:49 +0100
Re: My C program does not compile or gives segmentation fault jameskuyper@verizon.net - 2017-04-03 18:22 -0700
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-04-04 06:38 +0100
Re: My C program does not compile or gives segmentation fault Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-29 00:16 +0100
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-29 00:26 +0100
Re: My C program does not compile or gives segmentation fault Alla <vitale.alla@gmail.com> - 2017-03-28 12:34 +0300
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 13:28 +0100
Re: My C program does not compile or gives segmentation fault Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-03-28 07:04 -0600
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 14:38 +0100
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-28 10:55 -0400
Re: My C program does not compile or gives segmentation fault jadill33@gmail.com - 2017-03-28 07:27 -0700
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-28 07:58 -0700
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 16:13 +0100
Re: My C program does not compile or gives segmentation fault Alla <vitale.alla@gmail.com> - 2017-03-28 18:49 +0300
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-28 09:15 -0700
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 18:53 +0100
Re: My C program does not compile or gives segmentation fault scott@slp53.sl.home (Scott Lurndal) - 2017-03-28 18:12 +0000
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-28 11:51 -0700
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 19:59 +0100
Re: My C program does not compile or gives segmentation fault Alla <vitale.alla@gmail.com> - 2017-03-28 23:11 +0300
Re: My C program does not compile or gives segmentation fault Alla <vitale.alla@gmail.com> - 2017-04-01 17:20 +0300
Re: My C program does not compile or gives segmentation fault supercat@casperkitty.com - 2017-04-01 08:58 -0700
Re: My C program does not compile or gives segmentation fault GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-01 18:41 +0200
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-04-01 11:37 -0700
Re: My C program does not compile or gives segmentation fault Alla <vitale.alla@gmail.com> - 2017-04-02 22:43 +0300
Re: My C program does not compile or gives segmentation fault David Brown <david.brown@hesbynett.no> - 2017-04-03 08:47 +0200
Re: My C program does not compile or gives segmentation fault Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 07:58 -0700
Re: My C program does not compile or gives segmentation fault Ike Naar <ike@iceland.freeshell.org> - 2017-03-25 19:35 +0000
Re: My C program does not compile or gives segmentation fault raltbos@xs4all.nl (Richard Bos) - 2017-03-25 21:37 +0000
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-26 08:39 +0100
Re: My C program does not compile or gives segmentation fault raltbos@xs4all.nl (Richard Bos) - 2017-03-25 21:21 +0000
Re: My C program does not compile or gives segmentation fault Les Cargill <lcargill99@comcast.com> - 2017-03-25 16:54 -0500
Re: My C program does not compile or gives segmentation fault raltbos@xs4all.nl (Richard Bos) - 2017-03-25 22:32 +0000
Re: My C program does not compile or gives segmentation fault supercat@casperkitty.com - 2017-03-26 13:46 -0700
Re: My C program does not compile or gives segmentation fault raltbos@xs4all.nl (Richard Bos) - 2017-04-03 17:39 +0000
Re: My C program does not compile or gives segmentation fault supercat@casperkitty.com - 2017-04-03 11:42 -0700
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-04-03 12:10 -0700
Re: My C program does not compile or gives segmentation fault supercat@casperkitty.com - 2017-04-03 15:22 -0700
Re: My C program does not compile or gives segmentation fault raltbos@xs4all.nl (Richard Bos) - 2017-04-05 11:01 +0000
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-26 08:45 +0100
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-26 02:35 -0700
Re: My C program does not compile or gives segmentation fault David Brown <david.brown@hesbynett.no> - 2017-03-26 17:19 +0200
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-27 08:15 +0100
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 15:12 -0400
Re: My C program does not compile or gives segmentation fault Ian Collins <ian-news@hotmail.com> - 2017-03-25 08:41 +1300
Re: My C program does not compile or gives segmentation fault Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-03-24 16:27 -0600
Re: My C program does not compile or gives segmentation fault James Kuyper <jameskuyper@verizon.net> - 2017-03-24 21:36 -0400
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 20:44 -0400
Re: My C program does not compile or gives segmentation fault Ian Collins <ian-news@hotmail.com> - 2017-03-25 14:46 +1300
Re: My C program does not compile or gives segmentation fault supercat@casperkitty.com - 2017-03-24 11:24 -0700
Re: My C program does not compile or gives segmentation fault scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 13:52 +0000
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 13:55 +0000
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 10:31 -0400
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 14:39 +0000
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 12:54 -0400
Re: My C program does not compile or gives segmentation fault Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-23 21:56 +0000
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-23 15:18 -0700
Re: My C program does not compile or gives segmentation fault Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-03-23 16:39 -0600
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-23 20:42 -0400
Re: My C program does not compile or gives segmentation fault Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-03-23 16:33 -0600
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-23 20:45 -0400
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 10:01 +0000
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 09:27 -0400
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 13:53 +0000
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 10:32 -0400
Re: My C program does not compile or gives segmentation fault Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 14:42 +0000
Re: My C program does not compile or gives segmentation fault Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-24 12:56 -0400
Re: My C program does not compile or gives segmentation fault supercat@casperkitty.com - 2017-03-24 08:45 -0700
Re: My C program does not compile or gives segmentation fault Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-23 21:14 +0000
Re: My C program does not compile or gives segmentation fault Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-03-23 11:52 -0600
Re: My C program does not compile or gives segmentation fault acidlategamer@gmail.com - 2017-03-23 11:03 -0700
Re: My C program does not compile or gives segmentation fault acidlategamer@gmail.com - 2017-03-23 11:14 -0700
Re: My C program does not compile or gives segmentation fault Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-03-23 12:41 -0600
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-23 11:48 -0700
Re: My C program does not compile or gives segmentation fault acidlategamer@gmail.com - 2017-03-23 11:59 -0700
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-23 12:35 -0700
Re: My C program does not compile or gives segmentation fault acidlategamer@gmail.com - 2017-03-23 12:48 -0700
Re: My C program does not compile or gives segmentation fault Keith Thompson <kst-u@mib.org> - 2017-03-23 13:24 -0700
Re: My C program does not compile or gives segmentation fault scott@slp53.sl.home (Scott Lurndal) - 2017-03-23 20:46 +0000
Re: My C program does not compile or gives segmentation fault Barry Schwarz <schwarzb@dqel.com> - 2017-03-23 19:02 -0700
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-28 11:21 -0400 |
| Message-ID | <obdurm$988$1@dont-email.me> |
| In reply to | #107247 |
On 03/28/2017 03:33 AM, Richard Heathfield wrote: > On 27/03/17 23:37, Ben Bacarisse wrote: ... >> I appears that you don't think the >> readability of 3 vs y is of any consequence yet you mention it. Why? > > I brought up the question of whether x==y or y==x is harder to read, and > someone told me that neither included an integer constant. Since I > wasn't asking (at that time) about integer constants, this surprised me, Why? The only difference between the case you were asking about and the case previously under discussion was the replacement of a constant with a variable. Since the fact that it was a constant was crucial to the reasons given for the supposed "readability" issue (I agree, I see no readability problem), it's reasonable to ask why you made that change. > as I didn't think that the difficulty or otherwise of reading integer > constants was at issue. It's been very explicitly the claim that it's the fact that the constant is on the left hand side rather than the right hand side which is causing the supposed "readability" problem. Not the readability of the constant itself, but the readability of the entire expression when it has a constant in the "wrong" location. You might not understand why people feel that way any more than I do, but it should have been pretty clear that it was the combination of the constantness and the location of the constant that was causing their reading difficulty.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-28 15:38 +0000 |
| Message-ID | <6svCA.96719$xq7.5398@fx03.iad> |
| In reply to | #107266 |
James Kuyper <jameskuyper@verizon.net> writes: >On 03/28/2017 03:33 AM, Richard Heathfield wrote: >> On 27/03/17 23:37, Ben Bacarisse wrote: >... >>> I appears that you don't think the >>> readability of 3 vs y is of any consequence yet you mention it. Why? >> >> I brought up the question of whether x==y or y==x is harder to read, and >> someone told me that neither included an integer constant. Since I >> wasn't asking (at that time) about integer constants, this surprised me, > >Why? The only difference between the case you were asking about and the >case previously under discussion was the replacement of a constant with >a variable. Since the fact that it was a constant was crucial to the >reasons given for the supposed "readability" issue (I agree, I see no >readability problem), it's reasonable to ask why you made that change. > >> as I didn't think that the difficulty or otherwise of reading integer >> constants was at issue. > >It's been very explicitly the claim that it's the fact that the constant >is on the left hand side rather than the right hand side which is >causing the supposed "readability" problem. Not the readability of the >constant itself, but the readability of the entire expression when it >has a constant in the "wrong" location. You might not understand why >people feel that way any more than I do, but it should have been pretty >clear that it was the combination of the constantness and the location >of the constant that was causing their reading difficulty. I wouldn't classify it as a "reading difficulty", but rather "visually jarring". Yes, everyone knows that testing for equality is commutative. And yes, it's a personal preference issue, not a correctness issue. That said, I don't recall seeing constant first in any code written by KT, DMR or Steven Johnson (PCC), which is where I first learned C back in 1979 mucking about in the internals of the V6 C compiler and later porting PCC to a couple of unusual architectures.
[toc] | [prev] | [next] | [standalone]
| From | jm.bourguet@gmail.com |
|---|---|
| Date | 2017-03-28 09:03 -0700 |
| Message-ID | <685d559e-98ad-4f26-a0e5-37e1a4bffa67@googlegroups.com> |
| In reply to | #107266 |
Le mardi 28 mars 2017 17:21:21 UTC+2, James Kuyper a écrit : > You might not understand why > people feel that way any more than I do, but it should have been pretty > clear that it was the combination of the constantness and the location > of the constant that was causing their reading difficulty. There are two aspects. One is simply style, an unfamiliar style is usually more difficult to read than a familiar one. When you find an unfamiliar style which is easier to read than the familiar one, you should quickly adopt its features; it happens -- two examples where I did so: systematically put const after what is const instead of using the special case which allows to put const first; breaking a long line before an operator instead of after -- but we wouldn't have this conversation if it was such a case. Then there is also something else. Even if == is symmetrical, there is often one of the term which is more important than the other, and I tend to put that one first (there are other factors, for instance I prefer lb <= x && x < ub to x >= lb && x < ub), and a constant is rarely the more important term. If it happens, I'll probably do it (but I don't remember having ever met the case). Do you put systematically the constant first in inequality expression? I've met code where it was done for equality but never for inequality, and I wonder why this is not consistent. Yours,
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-28 09:20 -0700 |
| Subject | Re: Readabilty of "3 == x" (was: My C program does not compile or gives segmentation fault) |
| Message-ID | <lnlgrp5q59.fsf@kst-u.example.com> |
| In reply to | #107266 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
[...]
> In my teaching, I sometimes observe that participants oppose
> if heads such as
>
> if( x )
>
> . This seems to be so because in English (in my courses,
> actually, "in German") one cannot just say "if x,", but has
> to say "if x is not equivalent to zero," or some such. So,
> they expect that the rules that govern the English language
> also should apply to C.
That depends on what x is. If a name is used as a condition,
it should probably be a name that makes sense as a condition.
I probably wouldn't literally write
if (x)
but I might write
if (done)
or
if (job_is_completed)
which reads naturally as an English-like phrase. I certainly
wouldn't read `if (done)` as `if done is not equal to zero`.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-28 18:55 +0100 |
| Subject | Re: Readabilty of "3 == x" |
| Message-ID | <obe7s9$8kb$3@dont-email.me> |
| In reply to | #107277 |
On 28/03/17 17:20, Keith Thompson wrote: > ram@zedat.fu-berlin.de (Stefan Ram) writes: > [...] >> In my teaching, I sometimes observe that participants oppose >> if heads such as >> >> if( x ) >> >> . This seems to be so because in English (in my courses, >> actually, "in German") one cannot just say "if x,", but has >> to say "if x is not equivalent to zero," or some such. So, >> they expect that the rules that govern the English language >> also should apply to C. > > That depends on what x is. If a name is used as a condition, > it should probably be a name that makes sense as a condition. > I probably wouldn't literally write > if (x) > but I might write > if (done) > or > if (job_is_completed) > which reads naturally as an English-like phrase. I certainly > wouldn't read `if (done)` as `if done is not equal to zero`. Yes. I'm more likely to write something like while(!done) which I would read not as "while the logical negation of done is not equal to zero" but as "while not done". -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-28 18:49 +0100 |
| Message-ID | <obe7hl$8kb$1@dont-email.me> |
| In reply to | #107266 |
On 28/03/17 16:21, James Kuyper wrote: > On 03/28/2017 03:33 AM, Richard Heathfield wrote: >> On 27/03/17 23:37, Ben Bacarisse wrote: > ... >>> I appears that you don't think the >>> readability of 3 vs y is of any consequence yet you mention it. Why? >> >> I brought up the question of whether x==y or y==x is harder to read, and >> someone told me that neither included an integer constant. Since I >> wasn't asking (at that time) about integer constants, this surprised me, > > Why? The only difference between the case you were asking about and the > case previously under discussion was the replacement of a constant with > a variable. Since the fact that it was a constant was crucial to the > reasons given for the supposed "readability" issue (I agree, I see no > readability problem), it's reasonable to ask why you made that change. I prefer to argue interactively, one step at a time, but okay, since you insist, I'll lay out the whole argument in one piece. I would argue that the following pairs of expressions are just as easy to read as each other: x == y y == x #define z 3 x == z z == x #define B 3 x == B B == x (even though the B looks a bit like a 3) y + 3 == x - 6 x - 6 == y + 3 y + 3 == x x == y + 3 So what is so special about: 3 == x x == 3 Why is the constant suddenly a problem /here/, when it wasn't a problem anywhere else? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-28 14:53 -0400 |
| Message-ID | <da60e95a-3152-9093-6956-7c0aee2a08c2@verizon.net> |
| In reply to | #107283 |
On 03/28/2017 01:49 PM, Richard Heathfield wrote: ... > I prefer to argue interactively, one step at a time, but okay, since you > insist, I'll lay out the whole argument in one piece. > > I would argue that the following pairs of expressions are just as easy > to read as each other: > > x == y > y == x > > #define z 3 > > x == z > z == x > > #define B 3 > > x == B > B == x (even though the B looks a bit like a 3) > > y + 3 == x - 6 > x - 6 == y + 3 I predict that the same people who prefer x == 3 over 3 == x will also prefer the second of the two following forms: > y + 3 == x > x == y + 3 > > So what is so special about: > > 3 == x > x == 3 > > > Why is the constant suddenly a problem /here/, when it wasn't a problem > anywhere else? I would guess that it's precisely because here, and in no previous location, you've got a constant all by itself on one side of the comparison.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-03-28 15:19 -0500 |
| Message-ID | <blgldc5ge7uvrt4ksji00mrmdu753g76cs@4ax.com> |
| In reply to | #107283 |
On Tue, 28 Mar 2017 18:49:26 +0100, Richard Heathfield
<rjh@cpax.org.uk> wrote:
>On 28/03/17 16:21, James Kuyper wrote:
>> On 03/28/2017 03:33 AM, Richard Heathfield wrote:
>>> On 27/03/17 23:37, Ben Bacarisse wrote:
>> ...
>>>> I appears that you don't think the
>>>> readability of 3 vs y is of any consequence yet you mention it. Why?
>>>
>>> I brought up the question of whether x==y or y==x is harder to read, and
>>> someone told me that neither included an integer constant. Since I
>>> wasn't asking (at that time) about integer constants, this surprised me,
>>
>> Why? The only difference between the case you were asking about and the
>> case previously under discussion was the replacement of a constant with
>> a variable. Since the fact that it was a constant was crucial to the
>> reasons given for the supposed "readability" issue (I agree, I see no
>> readability problem), it's reasonable to ask why you made that change.
>
>I prefer to argue interactively, one step at a time, but okay, since you
>insist, I'll lay out the whole argument in one piece.
>
>I would argue that the following pairs of expressions are just as easy
>to read as each other:
>
>x == y
>y == x
>
>#define z 3
>
>x == z
>z == x
>
>#define B 3
>
>x == B
>B == x (even though the B looks a bit like a 3)
>
>y + 3 == x - 6
>x - 6 == y + 3
>
>y + 3 == x
>x == y + 3
>
>So what is so special about:
>
>3 == x
>x == 3
>
>
>Why is the constant suddenly a problem /here/, when it wasn't a problem
>anywhere else?
Personally I don't find either form troubling, although I do have a
preference for the x==3 version. FWIW, there are people here who do
it both ways, and much of the same debate has taken place in slow
motion over the years.
I suspect my preference comes from a distinction between what I
have/want and what I'm comparing it to. So I *have* x, and I'm
comparing it to three, I never "have" three. And I suspect the word
"have" is not quite right. Perhaps it's the "object" of my interest
(just to overload that word some more).
OTOH, if you have two things of interest that you're comparing, it's
less clear, but I'd have preference for the form that bears more on
the desired result. IOW, I'd prefer these:
if (temperaturetoday < temperatureyesterday)
puts("today is colder");
if (temperatureyesterday < temperaturetoday)
puts("yesterday was colder");
over these:
if (temperatureyesterday > temperaturetoday)
puts("today is colder");
if (temperaturetoday > temperatureyesterday)
puts("yesterday was colder");
IOW, the thing I want to determine something about, gets the emphasis
of first position.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-02 12:49 +0000 |
| Message-ID | <58e0f2c9.6173703@news.xs4all.nl> |
| In reply to | #107283 |
Richard Heathfield <rjh@cpax.org.uk> wrote: > y + 3 == x - 6 > x - 6 == y + 3 > > y + 3 == x > x == y + 3 Consider how ridiculous it is that you, you yourself, _consistently_ write y + 3, and not 3 + y; yet cannot get it into your head that other people might have the same attitude towards the equality sign. Of course, you're now going to post an example with "3 + y". And claim that this is just as legible. But you're going to have to acknowledge that _you did not do so naturally_. Richard
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-04-03 17:19 +0100 |
| Message-ID | <obtshg$t0e$1@dont-email.me> |
| In reply to | #107641 |
On 02/04/17 13:49, Richard Bos wrote: > Richard Heathfield <rjh@cpax.org.uk> wrote: > >> y + 3 == x - 6 >> x - 6 == y + 3 >> >> y + 3 == x >> x == y + 3 > > Consider how ridiculous it is that you, you yourself, _consistently_ > write y + 3, and not 3 + y; yet cannot get it into your head that other > people might have the same attitude towards the equality sign. > > Of course, you're now going to post an example with "3 + y". Or its moral equivalent, yes. > And claim > that this is just as legible. But you're going to have to acknowledge > that _you did not do so naturally_. I would have to acknowledge that if I came up with some examples purely for the sake of this discussion. So I'm not going to do that. Instead, I'm going to post some quotes from my source base, all of which pre-date the current discussion. In each case, I have removed quite a few examples that are basically indistinguishable from the ones shown in the respect under discussion. Since these results come from a grep, some lines are not complete C statements. Some show a literal as the left operand of an operator that takes an object identifier (or expression) as its right operand, and others show an operation on the left side of a comparison but a simple one-identifier expression on the right (such as i * 2 + 1 == x): pcl_FbCircle(image, 1000 + x, 1000 + y, CD_VERANDA, PCL_BLACK, 3); rowwidth = (4 * ((buf->width * 24 + 31) / 32)); xv = 1 * 1 * neg * neg * neg * x0 + 153 * m + 2) / 5 + sizeof *p * (1 + Dictionary[len].NumPatterns)); range = 1 + high - low; if(i * 2 + 1 == x) (c) >= 'A' && (c) <= 'f' ? 10 + (c) - 'A' : -1) *NumBytes = 1 + (size_t)(0.1 + ceil(LogBase * N->mag)) + (N->sign < 0); i = ((1 + high - low) * (rand() / (RAND_MAX + 1.0))) + low; To be sure, I have plenty of examples of constants on the right (that is, of the kind x == y + 3) as well. Like I said, I don't see that it matters either way, so I would expect to find examples of both kinds in my source base... and I do. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-04-03 21:44 +0200 |
| Message-ID | <obu8h9$c9d$1@dont-email.me> |
| In reply to | #107675 |
Le 03/04/2017 à 18:19, Richard Heathfield a écrit : > xv = 1 * 1 * neg * neg * neg * x0 + > 153 * m + 2) / 5 + > sizeof *p * (1 + Dictionary[len].NumPatterns)); Mmm that is very difficult to read. The problem is in the third line, in the sizeof expression. > sizeof *p * (1 + Dictionary[len].NumPatterns)); sizeof (*p) * (1+ ...) or sizeof (*p * (1+ ...)) What was the priority of sizeof related to "*" ? After reflection it must be sizeof (*p) but a doubt persists and I am away from trying to understand the code and get into C operators precedence... not what I was doing originally. Of course this doesn't happen to you (you know all that by heart) but to someone that hasn't the C operators priorities in his mind, it means a lookup and a distraction. A bit more parentheses would be indicated for that code.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-04-03 15:05 -0700 |
| Message-ID | <43cd04ca-48f0-456f-b3d4-7e84555f0995@googlegroups.com> |
| In reply to | #107695 |
On Monday, April 3, 2017 at 3:44:36 PM UTC-4, jacobnavia wrote: > Le 03/04/2017 à 18:19, Richard Heathfield a écrit : ... > > sizeof *p * (1 + Dictionary[len].NumPatterns)); > > Mmm that is very difficult to read. > > The problem is in the third line, in the sizeof expression. > > > sizeof *p * (1 + Dictionary[len].NumPatterns)); > > sizeof (*p) * (1+ ...) > > or > > sizeof (*p * (1+ ...)) > > What was the priority of sizeof related to "*" ? sizeof and unary * are both unary operators. Unary operators can only operate on the operand to their right, so, for instance, sizeof +-~!++*&x is parsed as sizeof (+(-(~(!(++(*(&x))))))). Unary operators all have higher precedence than any binary operator, so sizeof *p * (1 + Dictionary[len].NumPatterns)) should be parsed as (sizeof (*p)) * (1 + Dictionary[len].NumPatterns)). This doesn't seem very obscure to me - but then, I've been writing C for nearly four decades, which gives me a different perspective on such things.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-04-04 01:19 +0200 |
| Message-ID | <obul57$pua$1@dont-email.me> |
| In reply to | #107701 |
Le 04/04/2017 à 00:05, jameskuyper@verizon.net a écrit : > This doesn't seem very obscure to me - but then, I've been writing C for nearly > four decades, which gives me a different perspective on such things. Strange, that is the same number of decades as me, but I just didn't feel that memorizing precedence of operators is that important. I just put parentheses. You do not know (in a professional context) who is going to read the code. Making the reader pause just to save some parentheses is not worth in my opinion. Why not write clearly this stuff? I figure it out later but is it really necessary? Why avoid parentheses when they make the code clearer?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-04-04 00:49 +0100 |
| Message-ID | <87zifxvyos.fsf@bsb.me.uk> |
| In reply to | #107708 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 04/04/2017 à 00:05, jameskuyper@verizon.net a écrit : >> This doesn't seem very obscure to me - but then, I've been writing C for nearly >> four decades, which gives me a different perspective on such things. > > Strange, that is the same number of decades as me, but I just didn't > feel that memorizing precedence of operators is that important. I don't think you have to memorise them in this case. In mathematics, and in almost all programming languages, unary operators have the highest precedence. You see examples in school: -3 * 8, ~A & B. As a result, when I learn a programming language like C, all I need to do is to note that there is nothing odd about the prefix operators. The thing that you'd need to learn is a low-precedence unary operator. Admittedly, unlike school maths, C has two kinds of unary operator (prefix and postfix), so there is some stuff to learn if you need to know it all heart, but the example here was not a tricky one. > I just put parentheses. I found the parentheses you added to be very odd. You wondered (if I may simplify a bit) whether sizeof *p * x meant sizeof (*p) * x or sizeof (*p * x) What does the first one tell us? Not much I'd say. The choice is actually between (sizeof *p) * x and sizeof (*p * x) <snip> > Why avoid parentheses when they make the code clearer? But that seems to be what you are doing. Unless I misunderstood, you advocate putting in some parentheses that don't help: sizeof (*p) * x could *still* mean either of (sizeof (*p)) * x sizeof ((*p) * x) So why add these and not the ones that resolve the issue I think you had? The only parse that your parentheses rule out is something very odd like (sizeof *)p * x) which I don't think you were considering as a reasonable option. To show the precedence of sizeof you need to write (sizeof *p) * x and you can add () round *p if you think that too might be misinterpreted. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-04-03 18:22 -0700 |
| Message-ID | <65b516ae-af9f-4f26-b370-9cdb278de559@googlegroups.com> |
| In reply to | #107708 |
On Monday, April 3, 2017 at 7:20:02 PM UTC-4, jacobnavia wrote: > Le 04/04/2017 à 00:05, jameskuyper@verizon.net a écrit : > > This doesn't seem very obscure to me - but then, I've been writing C for nearly > > four decades, which gives me a different perspective on such things. > > Strange, that is the same number of decades as me, but I just didn't > feel that memorizing precedence of operators is that important. It didn't require a lot of effort. Every time I was uncertain about the precedence, I would look it up. Eventually, I didn't have to look it up anymore. It's not very hard. ... > Why avoid parentheses when they make the code clearer? From my point of view, the question is "why waste time putting in parentheses that aren't needed in order to make the code clearer?".
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-04-04 06:38 +0100 |
| Message-ID | <obvbae$7rj$1@dont-email.me> |
| In reply to | #107695 |
On 03/04/17 20:44, jacobnavia wrote: > Le 03/04/2017 à 18:19, Richard Heathfield a écrit : >> xv = 1 * 1 * neg * neg * neg * x0 + >> 153 * m + 2) / 5 + >> sizeof *p * (1 + Dictionary[len].NumPatterns)); > > Mmm that is very difficult to read. > > The problem is in the third line, in the sizeof expression. "Third line" is a moveable feast, since the quoted code fragments are three entirely different fragments from entirely different programs. I'm not sure what problem you have with the sizeof expression. >> sizeof *p * (1 + Dictionary[len].NumPatterns)); > > sizeof (*p) * (1+ ...) > > or > > sizeof (*p * (1+ ...)) > > What was the priority of sizeof related to "*" ? When you consider the idiom in which sizeof *p * n is most commonly used, i.e. "allocate enough memory for n objects", there really can be no question about what was intended. The only question is whether there is, or is not, a bug here. (There isn't.) > After reflection it must be sizeof (*p) but a doubt persists and I am > away from trying to understand the code and get into C operators > precedence... Understanding the code is easy - we're calculating the space required for a malloc or realloc. And we can tell this with almost 100% confidence without even looking at the original code! (And when I /do/ look at the original code, I see that it's part of a call to realloc.) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-03-29 00:16 +0100 |
| Message-ID | <87k279vvpm.fsf@bsb.me.uk> |
| In reply to | #107247 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 27/03/17 23:37, Ben Bacarisse wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: >> >>> On 27/03/17 21:28, Ben Bacarisse wrote: >>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>> >>>>> On 27/03/17 16:01, Scott Lurndal wrote: >>>>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>>> >>>>> <snip> >>>>> >>>>>>> Which of these is easier? >>>>>>> >>>>>>> if(x == y) >>>>>>> if(y == x) >>>>>> >>>>>> Given that neither expression includes an integer constant, >>>>>> methink you're moving the goalposts. >>>>> >>>>> I'd be very surprised to hear that people find integer constants >>>>> harder to read than other identifiers. >>>> >>>> Having moved the goalposts you are now begging the question! >>> >>> No, I don't think so (on either charge). People aren't saying "3" is >>> hard to read. >> >> Then I wonder why you brought it up. > > I didn't. It's right there 8 lines above. You were the first to bring up the idea of integer constants being (or not being) harder to read than identifiers. > I brought up the question of whether x==y or y==x is harder to read, > and someone told me that neither included an integer constant. Since I > wasn't asking (at that time) about integer constants, this surprised > me, as I didn't think that the difficulty or otherwise of reading > integer constants was at issue. Indeed. How very odd, then, to being it up. The issue was, originally, the readability 3==x vs x==3. For some reason, you asked about x==y vs. y==x and appeared to be suggesting that this was a reasonable question because who could think y was any less readable than 3. That's tantamount to begging the question. Apparently that's not what you meant, but that leaves me puzzled by why you should bring it up in response to some suggested that the x==y vs y==x question was quite a different one to the original. > Now you seem to be suggesting that I > think otherwise and that I introduced the subject. I don't see > why. I don't see how you can say you did not introduce the subject. I don't recall any previous mention of the relative readability of integers vs identifiers (though I may have missed one). You certainly introduced the subject in this part of the thread. And no, I am not suggesting that you think it matters. I was suggesting that you brought it up to disarm any complaints about the new question -- asking about x==y vs. y==x must be relevant because 3 and y are just as readable. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-29 00:26 +0100 |
| Message-ID | <ober99$crf$1@dont-email.me> |
| In reply to | #107340 |
On 29/03/17 00:16, Ben Bacarisse wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 27/03/17 23:37, Ben Bacarisse wrote: >>> Richard Heathfield <rjh@cpax.org.uk> writes: >>> >>>> On 27/03/17 21:28, Ben Bacarisse wrote: >>>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>>> >>>>>> On 27/03/17 16:01, Scott Lurndal wrote: >>>>>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>>>> >>>>>> <snip> >>>>>> >>>>>>>> Which of these is easier? >>>>>>>> >>>>>>>> if(x == y) >>>>>>>> if(y == x) >>>>>>> >>>>>>> Given that neither expression includes an integer constant, >>>>>>> methink you're moving the goalposts. >>>>>> >>>>>> I'd be very surprised to hear that people find integer constants >>>>>> harder to read than other identifiers. >>>>> >>>>> Having moved the goalposts you are now begging the question! >>>> >>>> No, I don't think so (on either charge). People aren't saying "3" is >>>> hard to read. >>> >>> Then I wonder why you brought it up. >> >> I didn't. > > It's right there 8 lines above. Scott Lurndal introduced the phrase "integer constant". What I was trying to do was introduce an illustration. But I'm not trying to be confrontational for the sake of it so okay, if it helps you, I'll fold on the subject of who said what about what. In a parallel reply I have laid out the argument I intended to make. Doubtless you will have read it by now, and either you'll see the point I was making (even if you don't agree with it) or you won't. Either way, we're never going to settle this to everybody's satisfaction because there are clearly (at least) two schools of thought that seem to be reasoning from very different assumptions. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Alla <vitale.alla@gmail.com> |
|---|---|
| Date | 2017-03-28 12:34 +0300 |
| Message-ID | <obdalm$45c$1@dont-email.me> |
| In reply to | #107217 |
On 3/28/17 00:27, Richard Heathfield wrote: > On 27/03/17 21:28, Ben Bacarisse wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: >> >>> On 27/03/17 16:01, Scott Lurndal wrote: >>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>> >>> <snip> >>> >>>>> Which of these is easier? >>>>> >>>>> if(x == y) >>>>> if(y == x) >>>> >>>> Given that neither expression includes an integer constant, >>>> methink you're moving the goalposts. >>> >>> I'd be very surprised to hear that people find integer constants >>> harder to read than other identifiers. >> >> Having moved the goalposts you are now begging the question! > > No, I don't think so (on either charge). People aren't saying "3" is > hard to read. They are saying "3==x" is harder to read than "x==3". What > I'm curious to know is /why/. > > To that end, I asked whether people have more trouble reading x==y than > y==x (or indeed more trouble reading y==x than x==y). If so, why? And if > not, then why would they have more trouble reading 3==x than x==3? > I will dare to jump into this discussion only for a brief comment, if I may. I have merely skimmed through the whole topic, and I don't understand the point of argument - why would any of you continue arguing on this minor issue at all. Both approaches are correct, and any of you simply use the one you find better for your purposes. Here is my penny into this topic as I surprisingly have not seen this type of explanation, but I do hope I will not kindle another wave of mainly subjective, and not that much C related discussion. x == 3 is a more "readable", or "pleasant", to a human eye way to express the statement, because this is a deeply-bred human convention of how we perceive statements containing variables, and this perception is fostered from childhood when people first encounter math. As x is the variable term here, and 3 is a constant, by writing x == 3 we are stressing that x is the variable under our investigation, and not 3, which is constant and will not change; and as we are questioning the value of x, we put it on the first place, which is a merely visual, lexicographical, or psychological, if you wish, convention of our perception. Only because of such perception (not a rule, not a matter of true or false, but perception) it is not the same to write x == 3, 3 == x and x == y, y == x, because in the latter case both values are not constants, they are variables, and hence x == y and y == x is perceived in the same way (though depending on the context, of course). But again both approaches carry the same logical value, and none is the only correct approach. Hence there is no point of argument here. Respectfully, Alla
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-28 13:28 +0100 |
| Message-ID | <obdko2$4qi$1@dont-email.me> |
| In reply to | #107250 |
On 28/03/17 10:34, Alla wrote: <snip> > But again both approaches carry the same logical value, and none is the > only correct approach. Hence there is no point of argument here. It is precisely because both approaches are correct that we are arguing about them. If one approach or the other were /in/correct, one side could simply point at the Standard and say "see?" and the other side would say "oh, good point", and that would be the end of the matter. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web