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 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-24 20:44 -0400 |
| Message-ID | <ob4ebv$76v$3@jstuckle.eternal-september.org> |
| In reply to | #106995 |
On 3/24/2017 3:41 PM, Ian Collins wrote: > On 03/25/17 05:52 AM, Jerry Stuckle wrote: >>> >> >> And CERT, a highly respected organization, has standards which disagree >> with you. > > "John Bode suggested the following compliant solution". Apparently not. > Yes, he suggested a compliant solution. That does not mean it was accepted as a compliant solution. But you're too dense to understand the difference. -- ================== 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 14:46 +1300 |
| Message-ID | <ejm0g8Frv02U1@mid.individual.net> |
| In reply to | #107025 |
On 03/25/17 01:44 PM, Jerry Stuckle wrote: > On 3/24/2017 3:41 PM, Ian Collins wrote: >> On 03/25/17 05:52 AM, Jerry Stuckle wrote: >>>> >>> >>> And CERT, a highly respected organization, has standards which disagree >>> with you. >> >> "John Bode suggested the following compliant solution". Apparently not. >> > > Yes, he suggested a compliant solution. That does not mean it was > accepted as a compliant solution. But you're too dense to understand > the difference. Jolly good. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-24 11:24 -0700 |
| Message-ID | <4e5adba6-321b-4a6b-b542-6f00a6b2b2cd@googlegroups.com> |
| In reply to | #106944 |
On Friday, March 24, 2017 at 11:45:43 AM UTC-5, james...@verizon.net wrote:
> On Friday, March 24, 2017 at 10:30:28 AM UTC-4, Jerry Stuckle wrote:
> 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.
Both failure modes include gross localized failures on the part of the
programmer. The former is perhaps more obviously wrong, especially if the
thing being written is a complicated lvalue expression and the sizeof
expression uses a simpler one which *should* have the same type.
The only common situations where I would expect the type of "p" could be
changed without requiring lots of rework would be if all uses of that type
use a common typedef. Given
typedef uint16_t thingIndex;
...
thingIndex *p;
and
p = (thingIndex*)malloc(sizeof (thingIndex*));
Changing the first declaration to:
typedef uint32_t thingIndex;
...
thingIndex *p;
would not require any change to the malloc() code. Changing declarations
to:
typedef uint16_t thingIndex;
...
uint32_t *p;
would break the malloc() code, but it would likely also break a lot of
other code as well--some of it silently. I would not consider the fact
that the latter change wouldn't break the malloc() as an advantage, since
having wrong code generate compiler squawks is a good thing.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-24 13:52 +0000 |
| Message-ID | <nw9BA.93706$mb5.92994@fx19.iad> |
| In reply to | #106904 |
Jerry Stuckle <jstucklex@attglobal.net> writes: >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'm really not sure why you continue to devolve to argumentum ad verecundiam.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-24 13:55 +0000 |
| Message-ID | <ob38bg$1jf$3@dont-email.me> |
| In reply to | #106909 |
On 24/03/17 13:52, Scott Lurndal wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: >> On 3/24/2017 6:10 AM, Richard Heathfield wrote: <snip> >>> 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'm really not sure why you continue to devolve to argumentum ad verecundiam. Are you sure you're not sure why? I'm pretty sure /I/'m sure why. -- 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:31 -0400 |
| Message-ID | <ob3aea$9av$2@jstuckle.eternal-september.org> |
| In reply to | #106909 |
On 3/24/2017 9:52 AM, Scott Lurndal wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: >> 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'm really not sure why you continue to devolve to argumentum ad verecundiam. > Maybe because the real experts on the language know more than the idiots here who spend all day arguing the standard and scope of variables. -- ================== 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:39 +0000 |
| Message-ID | <ob3au5$b77$2@dont-email.me> |
| In reply to | #106916 |
On 24/03/17 14:31, Jerry Stuckle wrote: > On 3/24/2017 9:52 AM, Scott Lurndal wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> 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'm really not sure why you continue to devolve to argumentum ad verecundiam. >> > > Maybe because the real experts on the language know more than the idiots > here who spend all day arguing the standard and scope of variables. You are answering a question about why you appeal to inappropriate authority by appealing to inappropriate authority. Has it ever occurred to you to base your answers on your own understanding of C rather than that of other people? Or is that not an option for you? -- 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:54 -0400 |
| Message-ID | <ob3ipr$7eq$3@jstuckle.eternal-september.org> |
| In reply to | #106919 |
On 3/24/2017 10:39 AM, Richard Heathfield wrote: > On 24/03/17 14:31, Jerry Stuckle wrote: >> On 3/24/2017 9:52 AM, Scott Lurndal wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> 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'm really not sure why you continue to devolve to argumentum ad >>> verecundiam. >>> >> >> Maybe because the real experts on the language know more than the idiots >> here who spend all day arguing the standard and scope of variables. > > You are answering a question about why you appeal to inappropriate > authority by appealing to inappropriate authority. Has it ever occurred > to you to base your answers on your own understanding of C rather than > that of other people? Or is that not an option for you? > The authority in this case is CERT - a world-wide recognized group of experts, who have produced those standards. As opposed to Richard, an idiot who can't do any better than argue standards and quote dictionary definitions. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2017-03-23 21:56 +0000 |
| Message-ID | <slrnod8h4c.1jqn.grahn+nntp@frailea.sa.invalid> |
| In reply to | #106847 |
On Thu, 2017-03-23, 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 > > See recommendation MEM02-C (Memory Management): > https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type > But they seem to nullify it all in the end with: "MEM02-C-EX1: Do not immediately cast the results of malloc() for code that will be compiled using a C90-conforming compiler [...]|" Am I misinterpreting, or do they really say "ignore this advice unless your compiler is more than thirty years old"? I'm not a big fan of coding standards. (But I like that these guys allow and participate in open discussions about their recommendations.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-23 15:18 -0700 |
| Message-ID | <ln8tnvab8n.fsf@kst-u.example.com> |
| In reply to | #106854 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Thu, 2017-03-23, Jerry Stuckle wrote:
[...]
>> 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
>>
>> See recommendation MEM02-C (Memory Management):
>> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type
>>
> But they seem to nullify it all in the end with:
>
> "MEM02-C-EX1: Do not immediately cast the results of malloc() for code
> that will be compiled using a C90-conforming compiler [...]|"
>
> Am I misinterpreting, or do they really say "ignore this advice unless
> your compiler is more than thirty years old"?
Yes, I think that's what they mean.
C90 lets you call a function with no visible declaration, but it
assumes that the function returns int. If you omit the required
`#include <stdlib.h>`, then a call without a cast:
int *p = malloc(sizeof *p);
will cause a diagnostic (assigning an int value to an int* object),
but a call with a cast:
int *p = (int*)malloc(sizeof *p);
likely will not. But the cast will convert the nonexistent int result
to int*, causing undefined behavior.
In C99 and later, you don't have that particular problem, since omitting
`#include <stdlib.h>` should trigger a diagnostic with or without the
cast.
The exception makes sense *if* you think the cast is a good idea.
But if you omit the cast in all cases, you'll have more robust code that
compiles without complaint in C90, C99, or C11. (Pre-ANSI compilers
might complain, but presumably they're rarely an issue.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2017-03-23 16:39 -0600 |
| Message-ID | <1bfui3aa9e.fsf@pfeifferfamily.net> |
| In reply to | #106854 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > On Thu, 2017-03-23, Jerry Stuckle wrote: >> >> See recommendation MEM02-C (Memory Management): >> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type >> > > But they seem to nullify it all in the end with: > > "MEM02-C-EX1: Do not immediately cast the results of malloc() for code > that will be compiled using a C90-conforming compiler [...]|" > > Am I misinterpreting, or do they really say "ignore this advice unless > your compiler is more than thirty years old"? I believe they are saying "you should ignore this advice if your compiler *is* more than thirty years old". > I'm not a big fan of coding standards. (But I like that these guys > allow and participate in open discussions about their > recommendations.)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-23 20:42 -0400 |
| Message-ID | <ob1psg$avm$1@jstuckle.eternal-september.org> |
| In reply to | #106854 |
On 3/23/2017 5:56 PM, Jorgen Grahn wrote: > On Thu, 2017-03-23, 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 >> >> See recommendation MEM02-C (Memory Management): >> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type >> > > But they seem to nullify it all in the end with: > > "MEM02-C-EX1: Do not immediately cast the results of malloc() for code > that will be compiled using a C90-conforming compiler [...]|" > > Am I misinterpreting, or do they really say "ignore this advice unless > your compiler is more than thirty years old"? > > I'm not a big fan of coding standards. (But I like that these guys > allow and participate in open discussions about their > recommendations.) > > /Jorgen > Or maybe they're saying "ignore this advice unless you compiler is less than 27 years old". -- ================== 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 16:33 -0600 |
| Message-ID | <1bk27faai2.fsf@pfeifferfamily.net> |
| In reply to | #106847 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > 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 > > See recommendation MEM02-C (Memory Management): > https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type Demonstrating that CERT gets it wrong sometimes. Note that their noncompliant example is p = malloc(sizeof(gadget)); /* Imminent problem */ The version I had above would be (in CERT's example) p = malloc(sizeof *p); This mitigates their concern about changing the type of p without updating the malloc() to match.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-23 20:45 -0400 |
| Message-ID | <ob1q2f$ber$1@jstuckle.eternal-september.org> |
| In reply to | #106856 |
On 3/23/2017 6:33 PM, Joe Pfeiffer wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> 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 >> >> See recommendation MEM02-C (Memory Management): >> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type > > Demonstrating that CERT gets it wrong sometimes. > > Note that their noncompliant example is > > p = malloc(sizeof(gadget)); /* Imminent problem */ > > The version I had above would be (in CERT's example) > > p = malloc(sizeof *p); > > This mitigates their concern about changing the type of p without > updating the malloc() to match. > Or, maybe demonstrating YOU have it wrong. But CERT would NEVER be more aware than you! ROFLMAO! -- ================== 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 10:01 +0000 |
| Message-ID | <ob2qjq$fjb$1@dont-email.me> |
| In reply to | #106856 |
On 23/03/17 22:33, Joe Pfeiffer wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> 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 >> >> See recommendation MEM02-C (Memory Management): >> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type > > Demonstrating that CERT gets it wrong sometimes. CERT came here a few years ago to ask people here to review their proposed coding standard. Some of us did that. They (for the most part) ignored the result, as a result of which the CERT Standard contains serious flaws. And then they wrote some of us up in their acknowledgements page, as if we somehow endorse the result. -- 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:27 -0400 |
| Message-ID | <ob36m1$rre$2@jstuckle.eternal-september.org> |
| In reply to | #106880 |
On 3/24/2017 6:01 AM, Richard Heathfield wrote: > On 23/03/17 22:33, Joe Pfeiffer wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> 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 >>> >>> >>> See recommendation MEM02-C (Memory Management): >>> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type >>> >> >> Demonstrating that CERT gets it wrong sometimes. > > CERT came here a few years ago to ask people here to review their > proposed coding standard. > > Some of us did that. > > They (for the most part) ignored the result, as a result of which the > CERT Standard contains serious flaws. > > And then they wrote some of us up in their acknowledgements page, as if > we somehow endorse the result. > > Yes, they accepted some of the ideas. But they didn't accept the idiotic ones. -- ================== 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:53 +0000 |
| Message-ID | <ob387t$1jf$2@dont-email.me> |
| In reply to | #106905 |
On 24/03/17 13:27, Jerry Stuckle wrote: > On 3/24/2017 6:01 AM, Richard Heathfield wrote: >> On 23/03/17 22:33, Joe Pfeiffer wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> 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 >>>> >>>> >>>> See recommendation MEM02-C (Memory Management): >>>> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type >>>> >>> >>> Demonstrating that CERT gets it wrong sometimes. >> >> CERT came here a few years ago to ask people here to review their >> proposed coding standard. >> >> Some of us did that. >> >> They (for the most part) ignored the result, as a result of which the >> CERT Standard contains serious flaws. >> >> And then they wrote some of us up in their acknowledgements page, as if >> we somehow endorse the result. > > Yes, they accepted some of the ideas. But they didn't accept the > idiotic ones. Technical arguments only, please. Calling an idea idiotic doesn't make it idiotic. If you want to convince people, you have to show *why* it's idiotic. "It's idiotic because CERT disagrees" is not convincing. -- 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:32 -0400 |
| Message-ID | <ob3age$9av$3@jstuckle.eternal-september.org> |
| In reply to | #106910 |
On 3/24/2017 9:53 AM, Richard Heathfield wrote: > On 24/03/17 13:27, Jerry Stuckle wrote: >> On 3/24/2017 6:01 AM, Richard Heathfield wrote: >>> On 23/03/17 22:33, Joe Pfeiffer wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> See recommendation MEM02-C (Memory Management): >>>>> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type >>>>> >>>>> >>>> >>>> Demonstrating that CERT gets it wrong sometimes. >>> >>> CERT came here a few years ago to ask people here to review their >>> proposed coding standard. >>> >>> Some of us did that. >>> >>> They (for the most part) ignored the result, as a result of which the >>> CERT Standard contains serious flaws. >>> >>> And then they wrote some of us up in their acknowledgements page, as if >>> we somehow endorse the result. >> >> Yes, they accepted some of the ideas. But they didn't accept the >> idiotic ones. > > Technical arguments only, please. Calling an idea idiotic doesn't make > it idiotic. If you want to convince people, you have to show *why* it's > idiotic. "It's idiotic because CERT disagrees" is not convincing. > > You have yet to provide ANY technical argument as to why they are wrong. And I'm not calling the idea idiotic - I'm calling the people here who spend all day arguing the standard and the scope of variables idiots. -- ================== 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:42 +0000 |
| Message-ID | <ob3b3r$ca8$1@dont-email.me> |
| In reply to | #106917 |
On 24/03/17 14:32, Jerry Stuckle wrote: > On 3/24/2017 9:53 AM, Richard Heathfield wrote: >> On 24/03/17 13:27, Jerry Stuckle wrote: >>> On 3/24/2017 6:01 AM, Richard Heathfield wrote: >>>> On 23/03/17 22:33, Joe Pfeiffer wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> See recommendation MEM02-C (Memory Management): >>>>>> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type >>>>>> >>>>>> >>>>> >>>>> Demonstrating that CERT gets it wrong sometimes. >>>> >>>> CERT came here a few years ago to ask people here to review their >>>> proposed coding standard. >>>> >>>> Some of us did that. >>>> >>>> They (for the most part) ignored the result, as a result of which the >>>> CERT Standard contains serious flaws. >>>> >>>> And then they wrote some of us up in their acknowledgements page, as if >>>> we somehow endorse the result. >>> >>> Yes, they accepted some of the ideas. But they didn't accept the >>> idiotic ones. >> >> Technical arguments only, please. Calling an idea idiotic doesn't make >> it idiotic. If you want to convince people, you have to show *why* it's >> idiotic. "It's idiotic because CERT disagrees" is not convincing. >> >> > > You have yet to provide ANY technical argument as to why they are wrong. Not so, but I'll reiterate. They're wrong to attempt to mandate a style that introduces unnecessary code without benefit. They're wrong to attempt to mandate a style that can hide a C90 bug. And they're wrong to attempt to mandate a style that is less robust than the obvious alternative in the face of changing requirements. > And I'm not calling the idea idiotic - I'm calling the people here who > spend all day arguing the standard and the scope of variables idiots. Still no technical arguments, then. Okay. -- 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:56 -0400 |
| Message-ID | <ob3iu2$7eq$5@jstuckle.eternal-september.org> |
| In reply to | #106920 |
On 3/24/2017 10:42 AM, Richard Heathfield wrote: > On 24/03/17 14:32, Jerry Stuckle wrote: >> On 3/24/2017 9:53 AM, Richard Heathfield wrote: >>> On 24/03/17 13:27, Jerry Stuckle wrote: >>>> On 3/24/2017 6:01 AM, Richard Heathfield wrote: >>>>> On 23/03/17 22:33, Joe Pfeiffer wrote: >>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> See recommendation MEM02-C (Memory Management): >>>>>>> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Demonstrating that CERT gets it wrong sometimes. >>>>> >>>>> CERT came here a few years ago to ask people here to review their >>>>> proposed coding standard. >>>>> >>>>> Some of us did that. >>>>> >>>>> They (for the most part) ignored the result, as a result of which the >>>>> CERT Standard contains serious flaws. >>>>> >>>>> And then they wrote some of us up in their acknowledgements page, >>>>> as if >>>>> we somehow endorse the result. >>>> >>>> Yes, they accepted some of the ideas. But they didn't accept the >>>> idiotic ones. >>> >>> Technical arguments only, please. Calling an idea idiotic doesn't make >>> it idiotic. If you want to convince people, you have to show *why* it's >>> idiotic. "It's idiotic because CERT disagrees" is not convincing. >>> >>> >> >> You have yet to provide ANY technical argument as to why they are wrong. > > Not so, but I'll reiterate. They're wrong to attempt to mandate a style > that introduces unnecessary code without benefit. They're wrong to > attempt to mandate a style that can hide a C90 bug. And they're wrong to > attempt to mandate a style that is less robust than the obvious > alternative in the face of changing requirements. > >> And I'm not calling the idea idiotic - I'm calling the people here who >> spend all day arguing the standard and the scope of variables idiots. > > Still no technical arguments, then. Okay. > You haven't produced any. But widely recognized experts disagree with the great Richard, who can't do more than argue standards and dictionary definitions. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web