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 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-24 14:33 +1300 |
| Message-ID | <ejjbbdFmdulU3@mid.individual.net> |
| In reply to | #106865 |
On 03/24/17 02:28 PM, Jerry Stuckle wrote: > On 3/23/2017 9:09 PM, Ian Collins wrote: >> On 03/24/17 01:43 PM, Jerry Stuckle wrote: >>> On 3/23/2017 4:40 PM, Richard Heathfield wrote: >>>> On 23/03/17 19:59, Jerry Stuckle wrote: >>>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote: >>>>>> On 23/03/17 18:53, Joe Pfeiffer wrote: >>>>>> <snip> >>>>>>> >>>>>>> Many people would prefer to see >>>>>>> >>>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct >>>>>>> Queue)); >>>>>>> >>>>>>> replaced with >>>>>>> >>>>>>> struct Queue *q = malloc(sizeof *q); >>>>>>> >>>>>>> on the grounds that it is simpler, the cast is unnecessary, and >>>>>>> changing >>>>>>> the type of q at some point in the future automatically still works >>>>>>> without remembering to change the argument to sizeof. >>>>>> >>>>>> It's also much easier to read, and easier to see that it's correct. >>>>>> >>>>>>> Others regard the >>>>>>> longer version as being a bit of self-documentation. >>>>>> >>>>>> And, like all documentation, it runs the danger of becoming outdated. >>>>>> >>>>> >>>>> It is also recommended by the SEI CERT C Coding Standard at >>>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >>>>> >>>>> >>>> >>>> Yes, I know. But it's still a bad idea. >>>> >>> >>> So you know more than CERT. ROFLMAO! >> >> The authour agrees with the consensus here in a later comment: >> >> "Much earlier, John Bode suggested the following compliant solution: >> widget *p; >> ... >> p = malloc(sizeof *p); >> >> as well as the use of Abstract Data Types (ADT). The ADT discussion is >> probably orthogonal to this guideline, but the approach of taking the >> sizeof *p seems to be a reasonable compliant solution that would seem to >> be noncompliant given the title of this rule." >> > > Which is *noncomplient*. Reasonable or not. So you claim Robert Seacord is contradicting himself? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-24 09:23 -0400 |
| Message-ID | <ob36dr$qc8$1@jstuckle.eternal-september.org> |
| In reply to | #106867 |
On 3/23/2017 9:33 PM, Ian Collins wrote: > On 03/24/17 02:28 PM, Jerry Stuckle wrote: >> On 3/23/2017 9:09 PM, Ian Collins wrote: >>> On 03/24/17 01:43 PM, Jerry Stuckle wrote: >>>> On 3/23/2017 4:40 PM, Richard Heathfield wrote: >>>>> On 23/03/17 19:59, Jerry Stuckle wrote: >>>>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote: >>>>>>> On 23/03/17 18:53, Joe Pfeiffer wrote: >>>>>>> <snip> >>>>>>>> >>>>>>>> Many people would prefer to see >>>>>>>> >>>>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct >>>>>>>> Queue)); >>>>>>>> >>>>>>>> replaced with >>>>>>>> >>>>>>>> struct Queue *q = malloc(sizeof *q); >>>>>>>> >>>>>>>> on the grounds that it is simpler, the cast is unnecessary, and >>>>>>>> changing >>>>>>>> the type of q at some point in the future automatically still works >>>>>>>> without remembering to change the argument to sizeof. >>>>>>> >>>>>>> It's also much easier to read, and easier to see that it's correct. >>>>>>> >>>>>>>> Others regard the >>>>>>>> longer version as being a bit of self-documentation. >>>>>>> >>>>>>> And, like all documentation, it runs the danger of becoming >>>>>>> outdated. >>>>>>> >>>>>> >>>>>> It is also recommended by the SEI CERT C Coding Standard at >>>>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >>>>>> >>>>>> >>>>>> >>>>> >>>>> Yes, I know. But it's still a bad idea. >>>>> >>>> >>>> So you know more than CERT. ROFLMAO! >>> >>> The authour agrees with the consensus here in a later comment: >>> >>> "Much earlier, John Bode suggested the following compliant solution: >>> widget *p; >>> ... >>> p = malloc(sizeof *p); >>> >>> as well as the use of Abstract Data Types (ADT). The ADT discussion is >>> probably orthogonal to this guideline, but the approach of taking the >>> sizeof *p seems to be a reasonable compliant solution that would seem to >>> be noncompliant given the title of this rule." >>> >> >> Which is *noncomplient*. Reasonable or not. > > So you claim Robert Seacord is contradicting himself? > Nope. But I already know you don't read so well. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-25 08:39 +1300 |
| Message-ID | <ejlb09FmdulU4@mid.individual.net> |
| In reply to | #106903 |
On 03/25/17 02:23 AM, Jerry Stuckle wrote: > On 3/23/2017 9:33 PM, Ian Collins wrote: >> On 03/24/17 02:28 PM, Jerry Stuckle wrote: >>> On 3/23/2017 9:09 PM, Ian Collins wrote: >>>> On 03/24/17 01:43 PM, Jerry Stuckle wrote: >>>>> On 3/23/2017 4:40 PM, Richard Heathfield wrote: >>>>>> On 23/03/17 19:59, Jerry Stuckle wrote: >>>>>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote: >>>>>>>> On 23/03/17 18:53, Joe Pfeiffer wrote: >>>>>>>> <snip> >>>>>>>>> >>>>>>>>> Many people would prefer to see >>>>>>>>> >>>>>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct >>>>>>>>> Queue)); >>>>>>>>> >>>>>>>>> replaced with >>>>>>>>> >>>>>>>>> struct Queue *q = malloc(sizeof *q); >>>>>>>>> >>>>>>>>> on the grounds that it is simpler, the cast is unnecessary, and >>>>>>>>> changing >>>>>>>>> the type of q at some point in the future automatically still works >>>>>>>>> without remembering to change the argument to sizeof. >>>>>>>> >>>>>>>> It's also much easier to read, and easier to see that it's correct. >>>>>>>> >>>>>>>>> Others regard the >>>>>>>>> longer version as being a bit of self-documentation. >>>>>>>> >>>>>>>> And, like all documentation, it runs the danger of becoming >>>>>>>> outdated. >>>>>>>> >>>>>>> >>>>>>> It is also recommended by the SEI CERT C Coding Standard at >>>>>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Yes, I know. But it's still a bad idea. >>>>>> >>>>> >>>>> So you know more than CERT. ROFLMAO! >>>> >>>> The authour agrees with the consensus here in a later comment: >>>> >>>> "Much earlier, John Bode suggested the following compliant solution: >>>> widget *p; >>>> ... >>>> p = malloc(sizeof *p); >>>> >>>> as well as the use of Abstract Data Types (ADT). The ADT discussion is >>>> probably orthogonal to this guideline, but the approach of taking the >>>> sizeof *p seems to be a reasonable compliant solution that would seem to >>>> be noncompliant given the title of this rule." >>>> >>> >>> Which is *noncomplient*. Reasonable or not. >> >> So you claim Robert Seacord is contradicting himself? >> > > Nope. But I already know you don't read so well. Did you fail to read "John Bode suggested the following compliant solution"? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-24 20:40 -0400 |
| Message-ID | <ob4e4s$76v$1@jstuckle.eternal-september.org> |
| In reply to | #106994 |
On 3/24/2017 3:39 PM, Ian Collins wrote: > On 03/25/17 02:23 AM, Jerry Stuckle wrote: >> On 3/23/2017 9:33 PM, Ian Collins wrote: >>> On 03/24/17 02:28 PM, Jerry Stuckle wrote: >>>> On 3/23/2017 9:09 PM, Ian Collins wrote: >>>>> On 03/24/17 01:43 PM, Jerry Stuckle wrote: >>>>>> On 3/23/2017 4:40 PM, Richard Heathfield wrote: >>>>>>> On 23/03/17 19:59, Jerry Stuckle wrote: >>>>>>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote: >>>>>>>>> On 23/03/17 18:53, Joe Pfeiffer wrote: >>>>>>>>> <snip> >>>>>>>>>> >>>>>>>>>> Many people would prefer to see >>>>>>>>>> >>>>>>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct >>>>>>>>>> Queue)); >>>>>>>>>> >>>>>>>>>> replaced with >>>>>>>>>> >>>>>>>>>> struct Queue *q = malloc(sizeof *q); >>>>>>>>>> >>>>>>>>>> on the grounds that it is simpler, the cast is unnecessary, and >>>>>>>>>> changing >>>>>>>>>> the type of q at some point in the future automatically still >>>>>>>>>> works >>>>>>>>>> without remembering to change the argument to sizeof. >>>>>>>>> >>>>>>>>> It's also much easier to read, and easier to see that it's >>>>>>>>> correct. >>>>>>>>> >>>>>>>>>> Others regard the >>>>>>>>>> longer version as being a bit of self-documentation. >>>>>>>>> >>>>>>>>> And, like all documentation, it runs the danger of becoming >>>>>>>>> outdated. >>>>>>>>> >>>>>>>> >>>>>>>> It is also recommended by the SEI CERT C Coding Standard at >>>>>>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Yes, I know. But it's still a bad idea. >>>>>>> >>>>>> >>>>>> So you know more than CERT. ROFLMAO! >>>>> >>>>> The authour agrees with the consensus here in a later comment: >>>>> >>>>> "Much earlier, John Bode suggested the following compliant solution: >>>>> widget *p; >>>>> ... >>>>> p = malloc(sizeof *p); >>>>> >>>>> as well as the use of Abstract Data Types (ADT). The ADT >>>>> discussion is >>>>> probably orthogonal to this guideline, but the approach of taking the >>>>> sizeof *p seems to be a reasonable compliant solution that would >>>>> seem to >>>>> be noncompliant given the title of this rule." >>>>> >>>> >>>> Which is *noncomplient*. Reasonable or not. >>> >>> So you claim Robert Seacord is contradicting himself? >>> >> >> Nope. But I already know you don't read so well. > > Did you fail to read "John Bode suggested the following compliant > solution"? > I read it. Too bad you don't understand what it's saying. But that's normal for you, Ian. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2017-03-23 19:48 -0600 |
| Message-ID | <1b37e3a1im.fsf@pfeifferfamily.net> |
| In reply to | #106865 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 3/23/2017 9:09 PM, Ian Collins wrote: >> >> "Much earlier, John Bode suggested the following compliant solution: >> widget *p; >> ... >> p = malloc(sizeof *p); >> >> as well as the use of Abstract Data Types (ADT). The ADT discussion is >> probably orthogonal to this guideline, but the approach of taking the >> sizeof *p seems to be a reasonable compliant solution that would seem to >> be noncompliant given the title of this rule." >> > > Which is *noncomplient*. Reasonable or not. Ummm, he said it was "... a reasonable *compliant* solution that would *seem* to be noncompliant given the title..." (emphasis added) Hence my remark elsewhere that the rule (and its title) needs to be modified so we don't have to wade through the comments to discover that the near-consensus here is also compliant.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2017-03-24 13:32 -0700 |
| Message-ID | <387505fd-1cdc-4c98-917b-40d876867d75@googlegroups.com> |
| In reply to | #106865 |
On Thursday, March 23, 2017 at 8:28:51 PM UTC-5, Jerry Stuckle wrote:
> On 3/23/2017 9:09 PM, Ian Collins wrote:
> > On 03/24/17 01:43 PM, Jerry Stuckle wrote:
> >> On 3/23/2017 4:40 PM, Richard Heathfield wrote:
> >>> On 23/03/17 19:59, Jerry Stuckle wrote:
> >>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote:
> >>>>> On 23/03/17 18:53, Joe Pfeiffer wrote:
> >>>>> <snip>
> >>>>>>
> >>>>>> Many people would prefer to see
> >>>>>>
> >>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct
> >>>>>> Queue));
> >>>>>>
> >>>>>> replaced with
> >>>>>>
> >>>>>> struct Queue *q = malloc(sizeof *q);
> >>>>>>
> >>>>>> on the grounds that it is simpler, the cast is unnecessary, and
> >>>>>> changing
> >>>>>> the type of q at some point in the future automatically still works
> >>>>>> without remembering to change the argument to sizeof.
> >>>>>
> >>>>> It's also much easier to read, and easier to see that it's correct.
> >>>>>
> >>>>>> Others regard the
> >>>>>> longer version as being a bit of self-documentation.
> >>>>>
> >>>>> And, like all documentation, it runs the danger of becoming outdated.
> >>>>>
> >>>>
> >>>> It is also recommended by the SEI CERT C Coding Standard at
> >>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard
> >>>>
> >>>>
> >>>
> >>> Yes, I know. But it's still a bad idea.
> >>>
> >>
> >> So you know more than CERT. ROFLMAO!
> >
> > The authour agrees with the consensus here in a later comment:
> >
> > "Much earlier, John Bode suggested the following compliant solution:
> > widget *p;
> > ...
> > p = malloc(sizeof *p);
> >
> > as well as the use of Abstract Data Types (ADT). The ADT discussion is
> > probably orthogonal to this guideline, but the approach of taking the
> > sizeof *p seems to be a reasonable compliant solution that would seem to
> > be noncompliant given the title of this rule."
> >
>
> Which is *noncomplient*. Reasonable or not.
>
T *p = malloc( sizeof *p );
*always* does the right thing. There's no chance of a type or size
mismatch. There's no chance of accidentally allocating the wrong amount
of memory. This idiom will always work everywhere in C. It won't work in
C++, but if you're writing C++ you *shouldn't use malloc()*.
Remember when malloc() returned char * instead of void *? The necessary
casting gymnastics were a *pain in the ass* and caused more problems than
they solved. That's part of why WG14 introduced the void * type IN THE
FIRST PLACE.
The CERT recommendation (and that's all it is, a recommendation) is flawed.
The rule *should* be to always use "sizeof *<target pointer>".
Besides, as of C99 you should *never* declare a pointer to dynamic memory
until you're ready to allocate that memory. Instead of writing
T *p;
// many lines of code
p = malloc( sizeof *p );
you should write
// many lines of code
T *p = malloc( sizeof *p );
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-24 20:42 -0400 |
| Message-ID | <ob4e81$76v$2@jstuckle.eternal-september.org> |
| In reply to | #106998 |
On 3/24/2017 4:32 PM, John Bode wrote: > On Thursday, March 23, 2017 at 8:28:51 PM UTC-5, Jerry Stuckle wrote: >> On 3/23/2017 9:09 PM, Ian Collins wrote: >>> On 03/24/17 01:43 PM, Jerry Stuckle wrote: >>>> On 3/23/2017 4:40 PM, Richard Heathfield wrote: >>>>> On 23/03/17 19:59, Jerry Stuckle wrote: >>>>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote: >>>>>>> On 23/03/17 18:53, Joe Pfeiffer wrote: >>>>>>> <snip> >>>>>>>> >>>>>>>> Many people would prefer to see >>>>>>>> >>>>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct >>>>>>>> Queue)); >>>>>>>> >>>>>>>> replaced with >>>>>>>> >>>>>>>> struct Queue *q = malloc(sizeof *q); >>>>>>>> >>>>>>>> on the grounds that it is simpler, the cast is unnecessary, and >>>>>>>> changing >>>>>>>> the type of q at some point in the future automatically still works >>>>>>>> without remembering to change the argument to sizeof. >>>>>>> >>>>>>> It's also much easier to read, and easier to see that it's correct. >>>>>>> >>>>>>>> Others regard the >>>>>>>> longer version as being a bit of self-documentation. >>>>>>> >>>>>>> And, like all documentation, it runs the danger of becoming outdated. >>>>>>> >>>>>> >>>>>> It is also recommended by the SEI CERT C Coding Standard at >>>>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >>>>>> >>>>>> >>>>> >>>>> Yes, I know. But it's still a bad idea. >>>>> >>>> >>>> So you know more than CERT. ROFLMAO! >>> >>> The authour agrees with the consensus here in a later comment: >>> >>> "Much earlier, John Bode suggested the following compliant solution: >>> widget *p; >>> ... >>> p = malloc(sizeof *p); >>> >>> as well as the use of Abstract Data Types (ADT). The ADT discussion is >>> probably orthogonal to this guideline, but the approach of taking the >>> sizeof *p seems to be a reasonable compliant solution that would seem to >>> be noncompliant given the title of this rule." >>> >> >> Which is *noncomplient*. Reasonable or not. >> > > T *p = malloc( sizeof *p ); > > *always* does the right thing. There's no chance of a type or size > mismatch. There's no chance of accidentally allocating the wrong amount > of memory. This idiom will always work everywhere in C. It won't work in > C++, but if you're writing C++ you *shouldn't use malloc()*. > > Remember when malloc() returned char * instead of void *? The necessary > casting gymnastics were a *pain in the ass* and caused more problems than > they solved. That's part of why WG14 introduced the void * type IN THE > FIRST PLACE. > > The CERT recommendation (and that's all it is, a recommendation) is flawed. > The rule *should* be to always use "sizeof *<target pointer>". > > Besides, as of C99 you should *never* declare a pointer to dynamic memory > until you're ready to allocate that memory. Instead of writing > > T *p; > > // many lines of code > > p = malloc( sizeof *p ); > > you should write > > // many lines of code > > T *p = malloc( sizeof *p ); > YOU say the CERT recommendation is flawed. C experts around the world disagree with you. And you don't always want to allocate memory at the time you declare the pointer. In fact, you may not allocate memory at all. But you may need to declare the pointer earlier for scoping reasons. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-17 06:30 -0700 |
| Message-ID | <kfnbmrv6u0z.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #106998 |
John Bode <jfbode1029@gmail.com> writes: > [...] > > Besides, as of C99 you should *never* declare a pointer to dynamic > memory until you're ready to allocate that memory. Instead of > writing > > T *p; > > // many lines of code > > p = malloc( sizeof *p ); > > you should write > > // many lines of code > > T *p = malloc( sizeof *p ); I cannot agree with this suggestion as an absolute statement. If offered as advice, eg, "As a general rule it is better to ...", then yes, sure, advice worth hearing. But not as an absolute. For one thing, not everyone agrees with the dogmatic rule that variables should always be declared as late as possible (and IMO rightly so). Also, there are circumstances where it is better not to malloc() at the point of declaration, even if one usually follows "don't declare until ready to initialize" rule. One example of that is where allocated memory is being grown using realloc() - in many cases it's better to initialize the pointer to a null value, and just realloc() as needed, rather than use an initial malloc() where the variable is declared.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2017-03-23 19:29 -0600 |
| Message-ID | <1b7f3fa2dw.fsf@pfeifferfamily.net> |
| In reply to | #106864 |
Ian Collins <ian-news@hotmail.com> writes: > On 03/24/17 01:43 PM, Jerry Stuckle wrote: >> >> So you know more than CERT. ROFLMAO! > > The authour agrees with the consensus here in a later comment: > > "Much earlier, John Bode suggested the following compliant solution: > widget *p; > ... > p = malloc(sizeof *p); > > as well as the use of Abstract Data Types (ADT). The ADT discussion > is probably orthogonal to this guideline, but the approach of taking > the sizeof *p seems to be a reasonable compliant solution that would > seem to be noncompliant given the title of this rule." Ah, so I just hadn't read the comments sufficiently, He really ought to (at the very least) point out that solution is another compliant option without making people read the comments.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-24 10:10 +0000 |
| Message-ID | <ob2r5a$ktq$1@dont-email.me> |
| In reply to | #106862 |
On 24/03/17 00:43, Jerry Stuckle wrote: > On 3/23/2017 4:40 PM, Richard Heathfield wrote: >> On 23/03/17 19:59, Jerry Stuckle wrote: >>> On 3/23/2017 3:00 PM, Richard Heathfield wrote: >>>> On 23/03/17 18:53, Joe Pfeiffer wrote: >>>> <snip> >>>>> >>>>> Many people would prefer to see >>>>> >>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct Queue)); >>>>> >>>>> replaced with >>>>> >>>>> struct Queue *q = malloc(sizeof *q); >>>>> >>>>> on the grounds that it is simpler, the cast is unnecessary, and >>>>> changing >>>>> the type of q at some point in the future automatically still works >>>>> without remembering to change the argument to sizeof. >>>> >>>> It's also much easier to read, and easier to see that it's correct. >>>> >>>>> Others regard the >>>>> longer version as being a bit of self-documentation. >>>> >>>> And, like all documentation, it runs the danger of becoming outdated. >>>> >>> >>> It is also recommended by the SEI CERT C Coding Standard at >>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >>> >> >> Yes, I know. But it's still a bad idea. >> > > So you know more than CERT. ROFLMAO! I don't claim to know more than CERT about everything. But I suspect I know more than some of them do about some aspects of C. As for your opinion, it is of no consequence because it is based on authority rather than on facts. Even very knowledgeable people can make mistakes that less knowledgeable people might recognise as mistakes, and so the idea that "expert says this but you say that, therefore you are wrong" is misguided. When an expert says something stupid like "cast malloc", it's as well to recognise that he's saying something stupid despite being an expert. If you want to argue the case on its merits, feel free, but arguing the case purely from an appeal to authority has no value. If you are able to defend your position on *technical* grounds, go ahead. -- 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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-24 09:26 -0400 |
| Message-ID | <ob36ke$rre$1@jstuckle.eternal-september.org> |
| In reply to | #106882 |
On 3/24/2017 6:10 AM, Richard Heathfield wrote: > On 24/03/17 00:43, Jerry Stuckle wrote: >> On 3/23/2017 4:40 PM, Richard Heathfield wrote: >>> On 23/03/17 19:59, Jerry Stuckle wrote: >>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote: >>>>> On 23/03/17 18:53, Joe Pfeiffer wrote: >>>>> <snip> >>>>>> >>>>>> Many people would prefer to see >>>>>> >>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct >>>>>> Queue)); >>>>>> >>>>>> replaced with >>>>>> >>>>>> struct Queue *q = malloc(sizeof *q); >>>>>> >>>>>> on the grounds that it is simpler, the cast is unnecessary, and >>>>>> changing >>>>>> the type of q at some point in the future automatically still works >>>>>> without remembering to change the argument to sizeof. >>>>> >>>>> It's also much easier to read, and easier to see that it's correct. >>>>> >>>>>> Others regard the >>>>>> longer version as being a bit of self-documentation. >>>>> >>>>> And, like all documentation, it runs the danger of becoming outdated. >>>>> >>>> >>>> It is also recommended by the SEI CERT C Coding Standard at >>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >>>> >>>> >>> >>> Yes, I know. But it's still a bad idea. >>> >> >> So you know more than CERT. ROFLMAO! > > I don't claim to know more than CERT about everything. But I suspect I > know more than some of them do about some aspects of C. > > As for your opinion, it is of no consequence because it is based on > authority rather than on facts. Even very knowledgeable people can make > mistakes that less knowledgeable people might recognise as mistakes, and > so the idea that "expert says this but you say that, therefore you are > wrong" is misguided. When an expert says something stupid like "cast > malloc", it's as well to recognise that he's saying something stupid > despite being an expert. > > If you want to argue the case on its merits, feel free, but arguing the > case purely from an appeal to authority has no value. If you are able to > defend your position on *technical* grounds, go ahead. > But these are not just one person's view. They are the consensus of a large number of very knowledgeable people. And a large number of other C experts have known over the years agree with CERT. I would say they know more than the idiots in this newsgroup. But you can't argue the case on its merits, so you have to just dismiss the source. That's because you can't argue your case on technical grounds. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-24 13:52 +0000 |
| Message-ID | <ob384v$1jf$1@dont-email.me> |
| In reply to | #106904 |
On 24/03/17 13:26, Jerry Stuckle wrote: > On 3/24/2017 6:10 AM, Richard Heathfield wrote: >> On 24/03/17 00:43, Jerry Stuckle wrote: >>> On 3/23/2017 4:40 PM, Richard Heathfield wrote: >>>> On 23/03/17 19:59, Jerry Stuckle wrote: >>>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote: >>>>>> On 23/03/17 18:53, Joe Pfeiffer wrote: >>>>>> <snip> >>>>>>> >>>>>>> Many people would prefer to see >>>>>>> >>>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct >>>>>>> Queue)); >>>>>>> >>>>>>> replaced with >>>>>>> >>>>>>> struct Queue *q = malloc(sizeof *q); >>>>>>> >>>>>>> on the grounds that it is simpler, the cast is unnecessary, and >>>>>>> changing >>>>>>> the type of q at some point in the future automatically still works >>>>>>> without remembering to change the argument to sizeof. >>>>>> >>>>>> It's also much easier to read, and easier to see that it's correct. >>>>>> >>>>>>> Others regard the >>>>>>> longer version as being a bit of self-documentation. >>>>>> >>>>>> And, like all documentation, it runs the danger of becoming outdated. >>>>>> >>>>> >>>>> It is also recommended by the SEI CERT C Coding Standard at >>>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >>>>> >>>>> >>>> >>>> Yes, I know. But it's still a bad idea. >>>> >>> >>> So you know more than CERT. ROFLMAO! >> >> I don't claim to know more than CERT about everything. But I suspect I >> know more than some of them do about some aspects of C. >> >> As for your opinion, it is of no consequence because it is based on >> authority rather than on facts. Even very knowledgeable people can make >> mistakes that less knowledgeable people might recognise as mistakes, and >> so the idea that "expert says this but you say that, therefore you are >> wrong" is misguided. When an expert says something stupid like "cast >> malloc", it's as well to recognise that he's saying something stupid >> despite being an expert. >> >> If you want to argue the case on its merits, feel free, but arguing the >> case purely from an appeal to authority has no value. If you are able to >> defend your position on *technical* grounds, go ahead. >> > > But these are not just one person's view. They are the consensus of a > large number of very knowledgeable people. That's not a technical argument. By the way, Robert Seacord came /here/ seeking consensus, and he didn't get it. Several people here put a lot of work into pointing out many of the flaws in the CERT document. You will find those people's names in the Acknowledgements section, but you will not find their corrections in the text because, for the most part, their views were ignored. > And a large number of other > C experts have known over the years agree with CERT. Again, that's not a technical argument. > I would say they know more than the idiots in this newsgroup. Nor is that. > But you can't argue the case on its merits, so you have to just dismiss > the source. That's because you can't argue your case on technical grounds. Projection. I have already argued this case many times on technical grounds. Let me summarise for you: 1) all things being equal, simpler code is better; 2) the cast is unnecessary (and, in C90, could hide a bug, that of failing to #include <stdlib.h>); 3) the code is more robust in the face of type changes. Now, do you have any *technical* arguments to present, or are you going to stick to your unconvincing appeals to dubious authority? -- 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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-24 10:30 -0400 |
| Message-ID | <ob3ace$9av$1@jstuckle.eternal-september.org> |
| In reply to | #106908 |
On 3/24/2017 9:52 AM, Richard Heathfield wrote: > On 24/03/17 13:26, Jerry Stuckle wrote: >> On 3/24/2017 6:10 AM, Richard Heathfield wrote: >>> On 24/03/17 00:43, Jerry Stuckle wrote: >>>> On 3/23/2017 4:40 PM, Richard Heathfield wrote: >>>>> On 23/03/17 19:59, Jerry Stuckle wrote: >>>>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote: >>>>>>> On 23/03/17 18:53, Joe Pfeiffer wrote: >>>>>>> <snip> >>>>>>>> >>>>>>>> Many people would prefer to see >>>>>>>> >>>>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct >>>>>>>> Queue)); >>>>>>>> >>>>>>>> replaced with >>>>>>>> >>>>>>>> struct Queue *q = malloc(sizeof *q); >>>>>>>> >>>>>>>> on the grounds that it is simpler, the cast is unnecessary, and >>>>>>>> changing >>>>>>>> the type of q at some point in the future automatically still works >>>>>>>> without remembering to change the argument to sizeof. >>>>>>> >>>>>>> It's also much easier to read, and easier to see that it's correct. >>>>>>> >>>>>>>> Others regard the >>>>>>>> longer version as being a bit of self-documentation. >>>>>>> >>>>>>> And, like all documentation, it runs the danger of becoming >>>>>>> outdated. >>>>>>> >>>>>> >>>>>> It is also recommended by the SEI CERT C Coding Standard at >>>>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >>>>>> >>>>>> >>>>>> >>>>> >>>>> Yes, I know. But it's still a bad idea. >>>>> >>>> >>>> So you know more than CERT. ROFLMAO! >>> >>> I don't claim to know more than CERT about everything. But I suspect I >>> know more than some of them do about some aspects of C. >>> >>> As for your opinion, it is of no consequence because it is based on >>> authority rather than on facts. Even very knowledgeable people can make >>> mistakes that less knowledgeable people might recognise as mistakes, and >>> so the idea that "expert says this but you say that, therefore you are >>> wrong" is misguided. When an expert says something stupid like "cast >>> malloc", it's as well to recognise that he's saying something stupid >>> despite being an expert. >>> >>> If you want to argue the case on its merits, feel free, but arguing the >>> case purely from an appeal to authority has no value. If you are able to >>> defend your position on *technical* grounds, go ahead. >>> >> >> But these are not just one person's view. They are the consensus of a >> large number of very knowledgeable people. > > That's not a technical argument. By the way, Robert Seacord came /here/ > seeking consensus, and he didn't get it. Several people here put a lot > of work into pointing out many of the flaws in the CERT document. You > will find those people's names in the Acknowledgements section, but you > will not find their corrections in the text because, for the most part, > their views were ignored. > >> And a large number of other >> C experts have known over the years agree with CERT. > > Again, that's not a technical argument. > >> I would say they know more than the idiots in this newsgroup. > > Nor is that. > >> But you can't argue the case on its merits, so you have to just dismiss >> the source. That's because you can't argue your case on technical >> grounds. > > Projection. I have already argued this case many times on technical > grounds. Let me summarise for you: > > 1) all things being equal, simpler code is better; > 2) the cast is unnecessary (and, in C90, could hide a bug, that of > failing to #include <stdlib.h>); > 3) the code is more robust in the face of type changes. > > Now, do you have any *technical* arguments to present, or are you going > to stick to your unconvincing appeals to dubious authority? > > Those are not technical grounds. They are a matter of style. And style only. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-24 14:37 +0000 |
| Message-ID | <ob3aq9$b77$1@dont-email.me> |
| In reply to | #106915 |
On 24/03/17 14:30, Jerry Stuckle wrote: > On 3/24/2017 9:52 AM, Richard Heathfield wrote: >> On 24/03/17 13:26, Jerry Stuckle wrote: >>> On 3/24/2017 6:10 AM, Richard Heathfield wrote: >>>> On 24/03/17 00:43, Jerry Stuckle wrote: >>>>> On 3/23/2017 4:40 PM, Richard Heathfield wrote: >>>>>> On 23/03/17 19:59, Jerry Stuckle wrote: >>>>>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote: >>>>>>>> On 23/03/17 18:53, Joe Pfeiffer wrote: >>>>>>>> <snip> >>>>>>>>> >>>>>>>>> Many people would prefer to see >>>>>>>>> >>>>>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct >>>>>>>>> Queue)); >>>>>>>>> >>>>>>>>> replaced with >>>>>>>>> >>>>>>>>> struct Queue *q = malloc(sizeof *q); >>>>>>>>> >>>>>>>>> on the grounds that it is simpler, the cast is unnecessary, and >>>>>>>>> changing >>>>>>>>> the type of q at some point in the future automatically still works >>>>>>>>> without remembering to change the argument to sizeof. >>>>>>>> >>>>>>>> It's also much easier to read, and easier to see that it's correct. >>>>>>>> >>>>>>>>> Others regard the >>>>>>>>> longer version as being a bit of self-documentation. >>>>>>>> >>>>>>>> And, like all documentation, it runs the danger of becoming >>>>>>>> outdated. >>>>>>>> >>>>>>> >>>>>>> It is also recommended by the SEI CERT C Coding Standard at >>>>>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Yes, I know. But it's still a bad idea. >>>>>> >>>>> >>>>> So you know more than CERT. ROFLMAO! >>>> >>>> I don't claim to know more than CERT about everything. But I suspect I >>>> know more than some of them do about some aspects of C. >>>> >>>> As for your opinion, it is of no consequence because it is based on >>>> authority rather than on facts. Even very knowledgeable people can make >>>> mistakes that less knowledgeable people might recognise as mistakes, and >>>> so the idea that "expert says this but you say that, therefore you are >>>> wrong" is misguided. When an expert says something stupid like "cast >>>> malloc", it's as well to recognise that he's saying something stupid >>>> despite being an expert. >>>> >>>> If you want to argue the case on its merits, feel free, but arguing the >>>> case purely from an appeal to authority has no value. If you are able to >>>> defend your position on *technical* grounds, go ahead. >>>> >>> >>> But these are not just one person's view. They are the consensus of a >>> large number of very knowledgeable people. >> >> That's not a technical argument. By the way, Robert Seacord came /here/ >> seeking consensus, and he didn't get it. Several people here put a lot >> of work into pointing out many of the flaws in the CERT document. You >> will find those people's names in the Acknowledgements section, but you >> will not find their corrections in the text because, for the most part, >> their views were ignored. >> >>> And a large number of other >>> C experts have known over the years agree with CERT. >> >> Again, that's not a technical argument. >> >>> I would say they know more than the idiots in this newsgroup. >> >> Nor is that. >> >>> But you can't argue the case on its merits, so you have to just dismiss >>> the source. That's because you can't argue your case on technical >>> grounds. >> >> Projection. I have already argued this case many times on technical >> grounds. Let me summarise for you: >> >> 1) all things being equal, simpler code is better; >> 2) the cast is unnecessary (and, in C90, could hide a bug, that of >> failing to #include <stdlib.h>); >> 3) the code is more robust in the face of type changes. >> >> Now, do you have any *technical* arguments to present, or are you going >> to stick to your unconvincing appeals to dubious authority? > > Those are not technical grounds. I disagree. A random dictionary search for "technical" reveals these two definitions (no doubt there are more): "relating to a particular subject, art, craft, or its techniques"; "involving or concerned with applied and industrial sciences". My argument certainly qualifies by the first definition. If you disagree with /that/, take it up in an English usage newsgroup. > They are a matter of style. And style only. But that's *not* a technical argument. Not that I was expecting one. -- 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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-24 12:51 -0400 |
| Message-ID | <ob3ilc$7eq$1@jstuckle.eternal-september.org> |
| In reply to | #106918 |
On 3/24/2017 10:37 AM, Richard Heathfield wrote: > On 24/03/17 14:30, Jerry Stuckle wrote: >> On 3/24/2017 9:52 AM, Richard Heathfield wrote: >>> On 24/03/17 13:26, Jerry Stuckle wrote: >>>> On 3/24/2017 6:10 AM, Richard Heathfield wrote: >>>>> On 24/03/17 00:43, Jerry Stuckle wrote: >>>>>> On 3/23/2017 4:40 PM, Richard Heathfield wrote: >>>>>>> On 23/03/17 19:59, Jerry Stuckle wrote: >>>>>>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote: >>>>>>>>> On 23/03/17 18:53, Joe Pfeiffer wrote: >>>>>>>>> <snip> >>>>>>>>>> >>>>>>>>>> Many people would prefer to see >>>>>>>>>> >>>>>>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct >>>>>>>>>> Queue)); >>>>>>>>>> >>>>>>>>>> replaced with >>>>>>>>>> >>>>>>>>>> struct Queue *q = malloc(sizeof *q); >>>>>>>>>> >>>>>>>>>> on the grounds that it is simpler, the cast is unnecessary, and >>>>>>>>>> changing >>>>>>>>>> the type of q at some point in the future automatically still >>>>>>>>>> works >>>>>>>>>> without remembering to change the argument to sizeof. >>>>>>>>> >>>>>>>>> It's also much easier to read, and easier to see that it's >>>>>>>>> correct. >>>>>>>>> >>>>>>>>>> Others regard the >>>>>>>>>> longer version as being a bit of self-documentation. >>>>>>>>> >>>>>>>>> And, like all documentation, it runs the danger of becoming >>>>>>>>> outdated. >>>>>>>>> >>>>>>>> >>>>>>>> It is also recommended by the SEI CERT C Coding Standard at >>>>>>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Yes, I know. But it's still a bad idea. >>>>>>> >>>>>> >>>>>> So you know more than CERT. ROFLMAO! >>>>> >>>>> I don't claim to know more than CERT about everything. But I suspect I >>>>> know more than some of them do about some aspects of C. >>>>> >>>>> As for your opinion, it is of no consequence because it is based on >>>>> authority rather than on facts. Even very knowledgeable people can >>>>> make >>>>> mistakes that less knowledgeable people might recognise as >>>>> mistakes, and >>>>> so the idea that "expert says this but you say that, therefore you are >>>>> wrong" is misguided. When an expert says something stupid like "cast >>>>> malloc", it's as well to recognise that he's saying something stupid >>>>> despite being an expert. >>>>> >>>>> If you want to argue the case on its merits, feel free, but arguing >>>>> the >>>>> case purely from an appeal to authority has no value. If you are >>>>> able to >>>>> defend your position on *technical* grounds, go ahead. >>>>> >>>> >>>> But these are not just one person's view. They are the consensus of a >>>> large number of very knowledgeable people. >>> >>> That's not a technical argument. By the way, Robert Seacord came /here/ >>> seeking consensus, and he didn't get it. Several people here put a lot >>> of work into pointing out many of the flaws in the CERT document. You >>> will find those people's names in the Acknowledgements section, but you >>> will not find their corrections in the text because, for the most part, >>> their views were ignored. >>> >>>> And a large number of other >>>> C experts have known over the years agree with CERT. >>> >>> Again, that's not a technical argument. >>> >>>> I would say they know more than the idiots in this newsgroup. >>> >>> Nor is that. >>> >>>> But you can't argue the case on its merits, so you have to just dismiss >>>> the source. That's because you can't argue your case on technical >>>> grounds. >>> >>> Projection. I have already argued this case many times on technical >>> grounds. Let me summarise for you: >>> >>> 1) all things being equal, simpler code is better; >>> 2) the cast is unnecessary (and, in C90, could hide a bug, that of >>> failing to #include <stdlib.h>); >>> 3) the code is more robust in the face of type changes. >>> >>> Now, do you have any *technical* arguments to present, or are you going >>> to stick to your unconvincing appeals to dubious authority? >> >> Those are not technical grounds. > > I disagree. A random dictionary search for "technical" reveals these two > definitions (no doubt there are more): "relating to a particular > subject, art, craft, or its techniques"; "involving or concerned with > applied and industrial sciences". > ROFLMAO! That doesn't make your argument "technical" - except in your mind. > My argument certainly qualifies by the first definition. If you disagree > with /that/, take it up in an English usage newsgroup. > >> They are a matter of style. And style only. > > But that's *not* a technical argument. Not that I was expecting one. > Nope. I don't argue styles under the guise of "technical". Face it. You just can't stand that someone more intelligent and better at programming C than you disagrees. Well, here's too words for you: tough shit. CERT standards are widely recognized as good programming practices. Richard's standards are recognized by no one except a few in this group. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-24 18:05 +0000 |
| Message-ID | <ob3mv3$nbq$1@dont-email.me> |
| In reply to | #106945 |
On 24/03/17 16:51, Jerry Stuckle wrote: > On 3/24/2017 10:37 AM, Richard Heathfield wrote: >> On 24/03/17 14:30, Jerry Stuckle wrote: <snip> >>> They are a matter of style. And style only. >> >> But that's *not* a technical argument. Not that I was expecting one. >> > > Nope. I don't argue styles under the guise of "technical". > > Face it. You just can't stand that someone more intelligent and better > at programming C than you disagrees. > > Well, here's too words for you: tough shit. > > CERT standards are widely recognized as good programming practices. > Richard's standards are recognized by no one except a few in this group. Again, that's an appeal to authority that does not demonstrate any knowledge of the C language. You have had ample opportunity to provide technical arguments to support your view and have refused every time. I am now getting people complaining at me in email for feeding the troll, so I'm going to leave it there until such time as you come up with something a bit more meaty than "Because a C Programmer at an American University Says So". -- 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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-24 15:09 -0400 |
| Message-ID | <ob3qo3$4r2$1@jstuckle.eternal-september.org> |
| In reply to | #106965 |
On 3/24/2017 2:05 PM, Richard Heathfield wrote: > On 24/03/17 16:51, Jerry Stuckle wrote: >> On 3/24/2017 10:37 AM, Richard Heathfield wrote: >>> On 24/03/17 14:30, Jerry Stuckle wrote: > > <snip> > >>>> They are a matter of style. And style only. >>> >>> But that's *not* a technical argument. Not that I was expecting one. >>> >> >> Nope. I don't argue styles under the guise of "technical". >> >> Face it. You just can't stand that someone more intelligent and better >> at programming C than you disagrees. >> >> Well, here's too words for you: tough shit. >> >> CERT standards are widely recognized as good programming practices. >> Richard's standards are recognized by no one except a few in this group. > > > Again, that's an appeal to authority that does not demonstrate any > knowledge of the C language. You have had ample opportunity to provide > technical arguments to support your view and have refused every time. > > I am now getting people complaining at me in email for feeding the > troll, so I'm going to leave it there until such time as you come up > with something a bit more meaty than "Because a C Programmer at an > American University Says So". > It is an authority which is widely recognized around the world. And when you come up with a technical argument against it, I will be quite happy to discuss it. But you still have not done so. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-24 12:55 -0400 |
| Message-ID | <ob3is0$7eq$4@jstuckle.eternal-september.org> |
| In reply to | #106918 |
On 3/24/2017 10:37 AM, Richard Heathfield wrote: > On 24/03/17 14:30, Jerry Stuckle wrote: >> On 3/24/2017 9:52 AM, Richard Heathfield wrote: >>> On 24/03/17 13:26, Jerry Stuckle wrote: >>>> On 3/24/2017 6:10 AM, Richard Heathfield wrote: >>>>> On 24/03/17 00:43, Jerry Stuckle wrote: >>>>>> On 3/23/2017 4:40 PM, Richard Heathfield wrote: >>>>>>> On 23/03/17 19:59, Jerry Stuckle wrote: >>>>>>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote: >>>>>>>>> On 23/03/17 18:53, Joe Pfeiffer wrote: >>>>>>>>> <snip> >>>>>>>>>> >>>>>>>>>> Many people would prefer to see >>>>>>>>>> >>>>>>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct >>>>>>>>>> Queue)); >>>>>>>>>> >>>>>>>>>> replaced with >>>>>>>>>> >>>>>>>>>> struct Queue *q = malloc(sizeof *q); >>>>>>>>>> >>>>>>>>>> on the grounds that it is simpler, the cast is unnecessary, and >>>>>>>>>> changing >>>>>>>>>> the type of q at some point in the future automatically still >>>>>>>>>> works >>>>>>>>>> without remembering to change the argument to sizeof. >>>>>>>>> >>>>>>>>> It's also much easier to read, and easier to see that it's >>>>>>>>> correct. >>>>>>>>> >>>>>>>>>> Others regard the >>>>>>>>>> longer version as being a bit of self-documentation. >>>>>>>>> >>>>>>>>> And, like all documentation, it runs the danger of becoming >>>>>>>>> outdated. >>>>>>>>> >>>>>>>> >>>>>>>> It is also recommended by the SEI CERT C Coding Standard at >>>>>>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Yes, I know. But it's still a bad idea. >>>>>>> >>>>>> >>>>>> So you know more than CERT. ROFLMAO! >>>>> >>>>> I don't claim to know more than CERT about everything. But I suspect I >>>>> know more than some of them do about some aspects of C. >>>>> >>>>> As for your opinion, it is of no consequence because it is based on >>>>> authority rather than on facts. Even very knowledgeable people can >>>>> make >>>>> mistakes that less knowledgeable people might recognise as >>>>> mistakes, and >>>>> so the idea that "expert says this but you say that, therefore you are >>>>> wrong" is misguided. When an expert says something stupid like "cast >>>>> malloc", it's as well to recognise that he's saying something stupid >>>>> despite being an expert. >>>>> >>>>> If you want to argue the case on its merits, feel free, but arguing >>>>> the >>>>> case purely from an appeal to authority has no value. If you are >>>>> able to >>>>> defend your position on *technical* grounds, go ahead. >>>>> >>>> >>>> But these are not just one person's view. They are the consensus of a >>>> large number of very knowledgeable people. >>> >>> That's not a technical argument. By the way, Robert Seacord came /here/ >>> seeking consensus, and he didn't get it. Several people here put a lot >>> of work into pointing out many of the flaws in the CERT document. You >>> will find those people's names in the Acknowledgements section, but you >>> will not find their corrections in the text because, for the most part, >>> their views were ignored. >>> >>>> And a large number of other >>>> C experts have known over the years agree with CERT. >>> >>> Again, that's not a technical argument. >>> >>>> I would say they know more than the idiots in this newsgroup. >>> >>> Nor is that. >>> >>>> But you can't argue the case on its merits, so you have to just dismiss >>>> the source. That's because you can't argue your case on technical >>>> grounds. >>> >>> Projection. I have already argued this case many times on technical >>> grounds. Let me summarise for you: >>> >>> 1) all things being equal, simpler code is better; >>> 2) the cast is unnecessary (and, in C90, could hide a bug, that of >>> failing to #include <stdlib.h>); >>> 3) the code is more robust in the face of type changes. >>> >>> Now, do you have any *technical* arguments to present, or are you going >>> to stick to your unconvincing appeals to dubious authority? >> >> Those are not technical grounds. > > I disagree. A random dictionary search for "technical" reveals these two > definitions (no doubt there are more): "relating to a particular > subject, art, craft, or its techniques"; "involving or concerned with > applied and industrial sciences". > > My argument certainly qualifies by the first definition. If you disagree > with /that/, take it up in an English usage newsgroup. > >> They are a matter of style. And style only. > > But that's *not* a technical argument. Not that I was expecting one. > Oh, and BTW - your definition of technical is nothing more than a quote of an authority. So according to you, it is meaningless. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-03-24 09:45 -0700 |
| Message-ID | <fd4449d0-cadc-4d8a-892b-b685d7dc04d7@googlegroups.com> |
| In reply to | #106915 |
On Friday, March 24, 2017 at 10:30:28 AM UTC-4, Jerry Stuckle wrote:
> On 3/24/2017 9:52 AM, Richard Heathfield wrote:
> > On 24/03/17 13:26, Jerry Stuckle wrote:
> >> On 3/24/2017 6:10 AM, Richard Heathfield wrote:
> >>> On 24/03/17 00:43, Jerry Stuckle wrote:
> >>>> On 3/23/2017 4:40 PM, Richard Heathfield wrote:
> >>>>> On 23/03/17 19:59, Jerry Stuckle wrote:
> >>>>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote:
> >>>>>>> On 23/03/17 18:53, Joe Pfeiffer wrote:
> >>>>>>> <snip>
> >>>>>>>>
> >>>>>>>> Many people would prefer to see
> >>>>>>>>
> >>>>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct
> >>>>>>>> Queue));
> >>>>>>>>
> >>>>>>>> replaced with
> >>>>>>>>
> >>>>>>>> struct Queue *q = malloc(sizeof *q);
> >>>>>>>>
> >>>>>>>> on the grounds that it is simpler, the cast is unnecessary, and
> >>>>>>>> changing
> >>>>>>>> the type of q at some point in the future automatically still works
> >>>>>>>> without remembering to change the argument to sizeof.
> >>>>>>>
> >>>>>>> It's also much easier to read, and easier to see that it's correct.
> >>>>>>>
> >>>>>>>> Others regard the
> >>>>>>>> longer version as being a bit of self-documentation.
> >>>>>>>
> >>>>>>> And, like all documentation, it runs the danger of becoming
> >>>>>>> outdated.
> >>>>>>>
> >>>>>>
> >>>>>> It is also recommended by the SEI CERT C Coding Standard at
> >>>>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> Yes, I know. But it's still a bad idea.
> >>>>>
> >>>>
> >>>> So you know more than CERT. ROFLMAO!
> >>>
> >>> I don't claim to know more than CERT about everything. But I suspect I
> >>> know more than some of them do about some aspects of C.
> >>>
> >>> As for your opinion, it is of no consequence because it is based on
> >>> authority rather than on facts. Even very knowledgeable people can make
> >>> mistakes that less knowledgeable people might recognise as mistakes, and
> >>> so the idea that "expert says this but you say that, therefore you are
> >>> wrong" is misguided. When an expert says something stupid like "cast
> >>> malloc", it's as well to recognise that he's saying something stupid
> >>> despite being an expert.
> >>>
> >>> If you want to argue the case on its merits, feel free, but arguing the
> >>> case purely from an appeal to authority has no value. If you are able to
> >>> defend your position on *technical* grounds, go ahead.
> >>>
> >>
> >> But these are not just one person's view. They are the consensus of a
> >> large number of very knowledgeable people.
> >
> > That's not a technical argument. By the way, Robert Seacord came /here/
> > seeking consensus, and he didn't get it. Several people here put a lot
> > of work into pointing out many of the flaws in the CERT document. You
> > will find those people's names in the Acknowledgements section, but you
> > will not find their corrections in the text because, for the most part,
> > their views were ignored.
> >
> >> And a large number of other
> >> C experts have known over the years agree with CERT.
> >
> > Again, that's not a technical argument.
> >
> >> I would say they know more than the idiots in this newsgroup.
> >
> > Nor is that.
> >
> >> But you can't argue the case on its merits, so you have to just dismiss
> >> the source. That's because you can't argue your case on technical
> >> grounds.
> >
> > Projection. I have already argued this case many times on technical
> > grounds. Let me summarise for you:
> >
> > 1) all things being equal, simpler code is better;
> > 2) the cast is unnecessary (and, in C90, could hide a bug, that of
> > failing to #include <stdlib.h>);
> > 3) the code is more robust in the face of type changes.
> >
> > Now, do you have any *technical* arguments to present, or are you going
> > to stick to your unconvincing appeals to dubious authority?
> >
> >
>
> Those are not technical grounds. They are a matter of style. And style
> only.
Well, no one's claiming that it's not legal to use the unnecessarily obfuscated approach, or that it won't work. We're only arguing that it's a bad idea, and there are sound technical reasons why that's the case.. The second of Richard's arguments is about not hiding a bug, which counts as a technical ground to me, though I'm sure you and I will never agree on the definition of "technical". CERT themselves found that reason sufficiently persuasive to make an exception for code that needs to compile under C90.
The most fundamental reason why
p = malloc(count * sizeof *p);
is better than
p = (int*)malloc(count * sizeof(int));
is that the more obfuscated approach serves only to solve a problem of it's own creation. The type doesn't matter with malloc (which is the key way that it differs from C++'s "new" operator). The memory allocated by malloc() is guaranteed to be correctly aligned for any type, and the return type is void* so it can implicitly be converted to any desired type.
The key thing that does matter to malloc() is the size, not the type. The expression "count *sizeof *p" manifestly gives the right size, as you can easily verify just by looking at that one line of code, without even needing to know the type of p. "count * sizeof(int)" might be the right size, if p is defined as int*, but the only way to be sure is to locate the declaration of p. That declaration might be on the same line, but it could also be on another line far away, particularly if it's a member of struct that's declared in a header file.
The obfuscated approach deals with this problem (which is of it's own creation, since "count * sizeof *p" doesn't have that problem in the first place), by requiring that a matching cast be made to malloc()'s return value, that performs precisely the same conversion that would have occurred anyway, so as to ensure that a diagnostic message will be mandatory if the types aren't compatible.
Note, in particular, that the obfuscated approach creates a breading ground for certain types of errors. For instance, when updating code, a careless coder (and there's plenty of those to go around) could update one of the two types, without updating the other:
p = (int_least64_t*)malloc(count * sizeof(int_least32_t));
The compiler would provide no help at catching this error, assuming that int_least64_t* is the correct type for p. Since the things that don't match are on the same line, it's pretty easy to catch such errors, but despite that fact I have seen precisely this type of mistake committed a couple of time.
The better approach has an analogous failure mode - if the name of a variable changes, a careless coder could leave you with
q = malloc(count * sizeof *p);
However, changes in the name of a variable generally (in my experience) mean that the old variable name is no longer in use, so the compiler will typically be able to point out such errors to you.
I'm not posting this in the expectation of being able to convince you - that would be a ridiculous thing to expect of you. I'm also not expecting this to prompt a discussion of the technical merits of the two approaches, that would be an equally ridiculous expectation. I'm posting for the benefit of more open-minded individuals who might be reading this, because it makes arguments that are somewhat distinct from Richard's.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-24 12:52 -0400 |
| Message-ID | <ob3imv$7eq$2@jstuckle.eternal-september.org> |
| In reply to | #106944 |
On 3/24/2017 12:45 PM, jameskuyper@verizon.net wrote: > On Friday, March 24, 2017 at 10:30:28 AM UTC-4, Jerry Stuckle wrote: >> On 3/24/2017 9:52 AM, Richard Heathfield wrote: >>> On 24/03/17 13:26, Jerry Stuckle wrote: >>>> On 3/24/2017 6:10 AM, Richard Heathfield wrote: >>>>> On 24/03/17 00:43, Jerry Stuckle wrote: >>>>>> On 3/23/2017 4:40 PM, Richard Heathfield wrote: >>>>>>> On 23/03/17 19:59, Jerry Stuckle wrote: >>>>>>>> On 3/23/2017 3:00 PM, Richard Heathfield wrote: >>>>>>>>> On 23/03/17 18:53, Joe Pfeiffer wrote: >>>>>>>>> <snip> >>>>>>>>>> >>>>>>>>>> Many people would prefer to see >>>>>>>>>> >>>>>>>>>> struct Queue *q = (struct Queue*)malloc(sizeof(struct >>>>>>>>>> Queue)); >>>>>>>>>> >>>>>>>>>> replaced with >>>>>>>>>> >>>>>>>>>> struct Queue *q = malloc(sizeof *q); >>>>>>>>>> >>>>>>>>>> on the grounds that it is simpler, the cast is unnecessary, and >>>>>>>>>> changing >>>>>>>>>> the type of q at some point in the future automatically still works >>>>>>>>>> without remembering to change the argument to sizeof. >>>>>>>>> >>>>>>>>> It's also much easier to read, and easier to see that it's correct. >>>>>>>>> >>>>>>>>>> Others regard the >>>>>>>>>> longer version as being a bit of self-documentation. >>>>>>>>> >>>>>>>>> And, like all documentation, it runs the danger of becoming >>>>>>>>> outdated. >>>>>>>>> >>>>>>>> >>>>>>>> It is also recommended by the SEI CERT C Coding Standard at >>>>>>>> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Yes, I know. But it's still a bad idea. >>>>>>> >>>>>> >>>>>> So you know more than CERT. ROFLMAO! >>>>> >>>>> I don't claim to know more than CERT about everything. But I suspect I >>>>> know more than some of them do about some aspects of C. >>>>> >>>>> As for your opinion, it is of no consequence because it is based on >>>>> authority rather than on facts. Even very knowledgeable people can make >>>>> mistakes that less knowledgeable people might recognise as mistakes, and >>>>> so the idea that "expert says this but you say that, therefore you are >>>>> wrong" is misguided. When an expert says something stupid like "cast >>>>> malloc", it's as well to recognise that he's saying something stupid >>>>> despite being an expert. >>>>> >>>>> If you want to argue the case on its merits, feel free, but arguing the >>>>> case purely from an appeal to authority has no value. If you are able to >>>>> defend your position on *technical* grounds, go ahead. >>>>> >>>> >>>> But these are not just one person's view. They are the consensus of a >>>> large number of very knowledgeable people. >>> >>> That's not a technical argument. By the way, Robert Seacord came /here/ >>> seeking consensus, and he didn't get it. Several people here put a lot >>> of work into pointing out many of the flaws in the CERT document. You >>> will find those people's names in the Acknowledgements section, but you >>> will not find their corrections in the text because, for the most part, >>> their views were ignored. >>> >>>> And a large number of other >>>> C experts have known over the years agree with CERT. >>> >>> Again, that's not a technical argument. >>> >>>> I would say they know more than the idiots in this newsgroup. >>> >>> Nor is that. >>> >>>> But you can't argue the case on its merits, so you have to just dismiss >>>> the source. That's because you can't argue your case on technical >>>> grounds. >>> >>> Projection. I have already argued this case many times on technical >>> grounds. Let me summarise for you: >>> >>> 1) all things being equal, simpler code is better; >>> 2) the cast is unnecessary (and, in C90, could hide a bug, that of >>> failing to #include <stdlib.h>); >>> 3) the code is more robust in the face of type changes. >>> >>> Now, do you have any *technical* arguments to present, or are you going >>> to stick to your unconvincing appeals to dubious authority? >>> >>> >> >> Those are not technical grounds. They are a matter of style. And style >> only. > > Well, no one's claiming that it's not legal to use the unnecessarily obfuscated approach, or that it won't work. We're only arguing that it's a bad idea, and there are sound technical reasons why that's the case.. The second of Richard's arguments is about not hiding a bug, which counts as a technical ground to me, though I'm sure you and I will never agree on the definition of "technical". CERT themselves found that reason sufficiently persuasive to make an exception for code that needs to compile under C90. > > The most fundamental reason why > > p = malloc(count * sizeof *p); > > is better than > > p = (int*)malloc(count * sizeof(int)); > > is that the more obfuscated approach serves only to solve a problem of it's own creation. The type doesn't matter with malloc (which is the key way that it differs from C++'s "new" operator). The memory allocated by malloc() is guaranteed to be correctly aligned for any type, and the return type is void* so it can implicitly be converted to any desired type. > > The key thing that does matter to malloc() is the size, not the type. The expression "count *sizeof *p" manifestly gives the right size, as you can easily verify just by looking at that one line of code, without even needing to know the type of p. "count * sizeof(int)" might be the right size, if p is defined as int*, but the only way to be sure is to locate the declaration of p. That declaration might be on the same line, but it could also be on another line far away, particularly if it's a member of struct that's declared in a header file. > > The obfuscated approach deals with this problem (which is of it's own creation, since "count * sizeof *p" doesn't have that problem in the first place), by requiring that a matching cast be made to malloc()'s return value, that performs precisely the same conversion that would have occurred anyway, so as to ensure that a diagnostic message will be mandatory if the types aren't compatible. > > Note, in particular, that the obfuscated approach creates a breading ground for certain types of errors. For instance, when updating code, a careless coder (and there's plenty of those to go around) could update one of the two types, without updating the other: > > p = (int_least64_t*)malloc(count * sizeof(int_least32_t)); > > The compiler would provide no help at catching this error, assuming that int_least64_t* is the correct type for p. Since the things that don't match are on the same line, it's pretty easy to catch such errors, but despite that fact I have seen precisely this type of mistake committed a couple of time. > > The better approach has an analogous failure mode - if the name of a variable changes, a careless coder could leave you with > > q = malloc(count * sizeof *p); > > However, changes in the name of a variable generally (in my experience) mean that the old variable name is no longer in use, so the compiler will typically be able to point out such errors to you. > > I'm not posting this in the expectation of being able to convince you - that would be a ridiculous thing to expect of you. I'm also not expecting this to prompt a discussion of the technical merits of the two approaches, that would be an equally ridiculous expectation. I'm posting for the benefit of more open-minded individuals who might be reading this, because it makes arguments that are somewhat distinct from Richard's. > And CERT, a highly respected organization, has standards which disagree with you. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web