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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-03-24 10:10 -0700 |
| Message-ID | <c0e06554-eafe-4937-87d5-2b02829a0227@googlegroups.com> |
| In reply to | #106946 |
On Friday, March 24, 2017 at 12:52:38 PM UTC-4, Jerry Stuckle wrote: ... > And CERT, a highly respected organization, has standards which disagree > with you. That's not news. Most standards have defects (ISO C definitely included). In fact, I'd be hard pressed to believe that any standard was perfect. For example, every requirement from MISRA that's been mentioned in this group has been, at best, poorly motivated, and at worst, positively wrong headed. I don't own a copy, so I can't be sure, but I expect it contains a great many reasonable requirements - but it's the others that are disproportionately likely to be discussed here. That's why I'm only interested in the technical reasons you will never be able to give for this preference, not the argument from authority which is the only thing you ever bother to give. I read the explanation CERT gave for their requirement, and that was based entirely upon the unstated but incorrect assumption that the type, rather than the size, was important.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-24 18:48 +0100 |
| Message-ID | <ob3m0b$jtr$1@dont-email.me> |
| In reply to | #106953 |
On 24/03/17 18:10, jameskuyper@verizon.net wrote: > On Friday, March 24, 2017 at 12:52:38 PM UTC-4, Jerry Stuckle wrote: > ... >> And CERT, a highly respected organization, has standards which disagree >> with you. > > That's not news. Most standards have defects (ISO C definitely included). In > fact, I'd be hard pressed to believe that any standard was perfect. For example, > every requirement from MISRA that's been mentioned in this group has been, at > best, poorly motivated, and at worst, positively wrong headed. I don't own a > copy, so I can't be sure, but I expect it contains a great many reasonable > requirements - but it's the others that are disproportionately likely to be > discussed here. I do have a copy of MISRA, and I'd guess very roughly that 60% of the rules are quite good ideas, 20% are not particularly helpful, and 20% are downright bad. Many of the good ones are pretty obvious (like "do not rely on undefined behaviour"). Many of the ones I consider bad had are motivated by poor tools - a developer (especially for the kinds of software where MISRA is appropriate) should get better tools rather than write less clear code. And some are a matter of style and opinion. > > That's why I'm only interested in the technical reasons you will never be able > to give for this preference, not the argument from authority which is the only > thing you ever bother to give. > > I read the explanation CERT gave for their requirement, and that was based > entirely upon the unstated but incorrect assumption that the type, rather than > the size, was important. > While malloc only cares about the size of the allocation, I think the type /is/ important here. If you have "widget *p; p = malloc(sizeof gadget);", then the code almost certainly has a big bug even if "gadget" and "widget" are the same size. The allocation will be fine, but you've got a logical bug somewhere. In my opinion, the problem does not lie in casting or not casting the result of malloc - it lies in the separation of the definition of "p" from its assignment. And the solution is to write your mallocs in the form "widget *p = malloc(sizeof *p);" - then there is no doubt about your types, your sizes, or what you are actually dealing with at that point in the code. And then you can safely cast your pointer if you want C++ compatibility - the risk of introducing a mistake here is very small. People who let their compilers use implicit declarations of functions without proper #includes and without warnings should find themselves a new career. You can also write "sizeof(widget)" without worrying about surprises if types change, because you have no choice but to change it on that line anyway. That saves the risk of the typo "malloc(sizeof p)".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-24 14:04 -0400 |
| Message-ID | <ob3mt6$n5v$1@dont-email.me> |
| In reply to | #106961 |
On 03/24/2017 01:48 PM, David Brown wrote: ... > While malloc only cares about the size of the allocation, I think the > type /is/ important here. If you have "widget *p; p = malloc(sizeof > gadget);", then the code almost certainly has a big bug even if "gadget" > and "widget" are the same size. The allocation will be fine, but you've > got a logical bug somewhere. Yes, but "sizeof *p" avoids that problem perfectly, without making any mention of the type. > In my opinion, the problem does not lie in casting or not casting the > result of malloc - it lies in the separation of the definition of "p" > from its assignment. And the solution is to write your mallocs in the > form "widget *p = malloc(sizeof *p);" - then there is no doubt about > your types, your sizes, or what you are actually dealing with at that > point in the code. The minute you're talking about variables which are members of structs (a VERY common case), it's generally not reasonable to put the definition and the assignment in the same place. ... > You can also write "sizeof(widget)" without worrying about surprises if > types change, because you have no choice but to change it on that line > anyway. ... "no choice"?? I've seen people make precisely that choice, and obviously, the compiler didn't object. It did cause problems during testing, of course (but only if the incorrect size was too small).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-24 19:16 +0100 |
| Message-ID | <ob3nkf$pnc$1@dont-email.me> |
| In reply to | #106964 |
On 24/03/17 19:04, James Kuyper wrote:
> On 03/24/2017 01:48 PM, David Brown wrote:
> ...
>> While malloc only cares about the size of the allocation, I think the
>> type /is/ important here. If you have "widget *p; p = malloc(sizeof
>> gadget);", then the code almost certainly has a big bug even if "gadget"
>> and "widget" are the same size. The allocation will be fine, but you've
>> got a logical bug somewhere.
>
> Yes, but "sizeof *p" avoids that problem perfectly, without making any
> mention of the type.
No, it makes this bug even harder to find.
If the user writes "p = malloc(sizeof gadget)" when p is declared as
"widget *", then you can see that they are mixing up gadgets and
widgets. If the user, with the same logical mixup, writes "p =
malloc(*p)", then it is harder to spot the logical flaw.
The point is, there is a bug somewhere. If you are lucky, the compiler
can help find it. Less lucky, you can see it from the code.
I am not saying that writing "malloc(sizeof gadget)" is necessarily a
good idea overall - but it may have some merits.
>
>> In my opinion, the problem does not lie in casting or not casting the
>> result of malloc - it lies in the separation of the definition of "p"
>> from its assignment. And the solution is to write your mallocs in the
>> form "widget *p = malloc(sizeof *p);" - then there is no doubt about
>> your types, your sizes, or what you are actually dealing with at that
>> point in the code.
>
> The minute you're talking about variables which are members of structs
> (a VERY common case), it's generally not reasonable to put the
> definition and the assignment in the same place.
>
Agreed, that makes things a little different.
However, it may well make sense to write:
widget *p = malloc(sizeof *p);
if (p) {
s.widget_ptr = p;
// ...
} else {
panic();
}
The "best" choice can depend on the code in question.
And as has also been mentioned, factory functions or creator functions
of some kind could easily be a better solution.
> ...
>> You can also write "sizeof(widget)" without worrying about surprises if
>> types change, because you have no choice but to change it on that line
>> anyway. ...
>
> "no choice"?? I've seen people make precisely that choice, and
> obviously, the compiler didn't object. It did cause problems during
> testing, of course (but only if the incorrect size was too small).
>
Fair enough - people can always find ways to choose to write incorrect code!
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-24 15:10 -0400 |
| Message-ID | <ob3qpb$4tv$1@dont-email.me> |
| In reply to | #106967 |
On 03/24/2017 02:16 PM, David Brown wrote:
> On 24/03/17 19:04, James Kuyper wrote:
>> On 03/24/2017 01:48 PM, David Brown wrote:
>> ...
>>> While malloc only cares about the size of the allocation, I think the
>>> type /is/ important here. If you have "widget *p; p = malloc(sizeof
>>> gadget);", then the code almost certainly has a big bug even if "gadget"
I just realized that your example is a syntax error unless gadget is the
name of a variable. I had thought it was meant to be a typedef name. Had
you intended to write
p = malloc(sizeof(gadget));
>>> and "widget" are the same size. The allocation will be fine, but you've
>>> got a logical bug somewhere.
>>
>> Yes, but "sizeof *p" avoids that problem perfectly, without making any
>> mention of the type.
>
> No, it makes this bug even harder to find.
>
> If the user writes "p = malloc(sizeof gadget)" when p is declared as
> "widget *", then you can see that they are mixing up gadgets and
> widgets. If the user, with the same logical mixup, writes "p =
> malloc(*p)", then it is harder to spot the logical flaw.
The only thing wrong with
p = malloc(*p);
is the missing sizeof operator. It would seem to me that the analogous
error with the other approach would be:
p = (widget*)malloc(widget);
I have to agree - malloc(widget) is always a syntax error, while
malloc(*p) is only a syntax error is *p doesn't have arithmetic type, so
that's a very minor argument in favor of using the type rather than the
expression, depending upon how likely you are to forget the "sizeof"
operator.
I don't see how the "same logical mixup" could lead to both
p = malloc(sizeof gadget);
and
p = malloc(*p);
The first comes from forgetting the type of *p, an error that's not
particular unusual in code that has a large number of user-defined
types. The second comes from forgetting to type sizeof, a very different
type of error, and one I would not describe as a "logical mixup".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-24 15:17 -0400 |
| Message-ID | <ob3r6b$6k5$1@dont-email.me> |
| In reply to | #106986 |
On 03/24/2017 03:10 PM, James Kuyper wrote: ... > malloc(*p) is only a syntax error is *p doesn't have arithmetic type, so That should have been "constraint violation", not "syntax error".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-25 00:49 +0100 |
| Message-ID | <ob4b5d$vi8$1@dont-email.me> |
| In reply to | #106986 |
On 24/03/17 20:10, James Kuyper wrote: > On 03/24/2017 02:16 PM, David Brown wrote: >> On 24/03/17 19:04, James Kuyper wrote: >>> On 03/24/2017 01:48 PM, David Brown wrote: >>> ... >>>> While malloc only cares about the size of the allocation, I think the >>>> type /is/ important here. If you have "widget *p; p = malloc(sizeof >>>> gadget);", then the code almost certainly has a big bug even if "gadget" > > I just realized that your example is a syntax error unless gadget is the > name of a variable. I had thought it was meant to be a typedef name. Had > you intended to write > > p = malloc(sizeof(gadget)); Yes, that was my intention. Sorry for the mistake. > >>>> and "widget" are the same size. The allocation will be fine, but you've >>>> got a logical bug somewhere. >>> >>> Yes, but "sizeof *p" avoids that problem perfectly, without making any >>> mention of the type. >> >> No, it makes this bug even harder to find. >> >> If the user writes "p = malloc(sizeof gadget)" when p is declared as >> "widget *", then you can see that they are mixing up gadgets and >> widgets. If the user, with the same logical mixup, writes "p = >> malloc(*p)", then it is harder to spot the logical flaw. > > The only thing wrong with > > p = malloc(*p); > > is the missing sizeof operator. Another silly mistake from me. I must have made that post in a rush. p = malloc(sizeof *p); is not /wrong/. I just wonder if it would make it harder to spot a logical flaw in the program if the user has got his types mixed up. > It would seem to me that the analogous > error with the other approach would be: > > p = (widget*)malloc(widget); > > I have to agree - malloc(widget) is always a syntax error, while > malloc(*p) is only a syntax error is *p doesn't have arithmetic type, so > that's a very minor argument in favor of using the type rather than the > expression, depending upon how likely you are to forget the "sizeof" > operator. > > I don't see how the "same logical mixup" could lead to both > > p = malloc(sizeof gadget); > > and > > p = malloc(*p); > > The first comes from forgetting the type of *p, an error that's not > particular unusual in code that has a large number of user-defined > types. The second comes from forgetting to type sizeof, a very different > type of error, and one I would not describe as a "logical mixup". > I'm sorry that I totally failed to make my point, due to silly syntax errors.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-24 21:10 -0400 |
| Message-ID | <ob4fse$c04$1@dont-email.me> |
| In reply to | #107017 |
On 03/24/2017 07:49 PM, David Brown wrote: > On 24/03/17 20:10, James Kuyper wrote: >> On 03/24/2017 02:16 PM, David Brown wrote: >>> On 24/03/17 19:04, James Kuyper wrote: >>>> On 03/24/2017 01:48 PM, David Brown wrote: >>>> ... >>>>> While malloc only cares about the size of the allocation, I think the >>>>> type /is/ important here. If you have "widget *p; p = malloc(sizeof >>>>> gadget);", then the code almost certainly has a big bug even if "gadget" >> >> I just realized that your example is a syntax error unless gadget is the >> name of a variable. I had thought it was meant to be a typedef name. Had >> you intended to write >> >> p = malloc(sizeof(gadget)); > > Yes, that was my intention. Sorry for the mistake. ... > Another silly mistake from me. I must have made that post in a rush. I assumed as much - I just had no idea what your example would have looked like if written as intended. > p = malloc(sizeof *p); > > is not /wrong/. I just wonder if it would make it harder to spot a > logical flaw in the program if the user has got his types mixed up. I don't see how. A type mix-up is guaranteed to not be a problem with this version of the code; once the user realizes that, it frees him to pay more attention to lines of code that might actually be affected by such a mixup.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-25 02:37 +0100 |
| Message-ID | <ob4hg2$fj3$1@dont-email.me> |
| In reply to | #107026 |
On 25/03/17 02:10, James Kuyper wrote: > On 03/24/2017 07:49 PM, David Brown wrote: >> On 24/03/17 20:10, James Kuyper wrote: >>> On 03/24/2017 02:16 PM, David Brown wrote: >>>> On 24/03/17 19:04, James Kuyper wrote: >>>>> On 03/24/2017 01:48 PM, David Brown wrote: >>>>> ... >>>>>> While malloc only cares about the size of the allocation, I think the >>>>>> type /is/ important here. If you have "widget *p; p = malloc(sizeof >>>>>> gadget);", then the code almost certainly has a big bug even if "gadget" >>> >>> I just realized that your example is a syntax error unless gadget is the >>> name of a variable. I had thought it was meant to be a typedef name. Had >>> you intended to write >>> >>> p = malloc(sizeof(gadget)); >> >> Yes, that was my intention. Sorry for the mistake. > ... >> Another silly mistake from me. I must have made that post in a rush. > > I assumed as much - I just had no idea what your example would have > looked like if written as intended. > >> p = malloc(sizeof *p); >> >> is not /wrong/. I just wonder if it would make it harder to spot a >> logical flaw in the program if the user has got his types mixed up. > > I don't see how. A type mix-up is guaranteed to not be a problem with > this version of the code; once the user realizes that, it frees him to > pay more attention to lines of code that might actually be affected by > such a mixup. > My point was that if the user thinks he is dealing with a pointer-to-gadget when he in fact has a pointer-to-widget, then his code is going to be wrong even if the allocation happens to be safe. Longer distance between the parts of the code that mention the types can make it harder to see what has gone wrong. Of course, there are many other methods to make such mistakes easier to avoid or find - better choice of variable names, shorter functions, declaring variables only when you are going to initialise them, using factory or creator functions, etc. Having the name of the type in the malloc line might be a help too. Whether that is a useful enough point to make it worth putting the type name there is another matter - but it /might/ make code clearer to some people.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-24 21:45 -0400 |
| Message-ID | <ob4hv8$go2$1@dont-email.me> |
| In reply to | #107031 |
On 03/24/2017 09:37 PM, David Brown wrote: > On 25/03/17 02:10, James Kuyper wrote: >> On 03/24/2017 07:49 PM, David Brown wrote: ... >>> p = malloc(sizeof *p); >>> >>> is not /wrong/. I just wonder if it would make it harder to spot a >>> logical flaw in the program if the user has got his types mixed up. >> >> I don't see how. A type mix-up is guaranteed to not be a problem with >> this version of the code; once the user realizes that, it frees him to >> pay more attention to lines of code that might actually be affected by >> such a mixup. >> > > My point was that if the user thinks he is dealing with a > pointer-to-gadget when he in fact has a pointer-to-widget, then his code > is going to be wrong even if the allocation happens to be safe. The parts of his code which are actually wrong is where he should be expecting to get a warning message, and if he doesn't, he should concentrate on writing them in such a way as to get that warning. Writing this line of code in a sub-optimal way just to get a warning that should properly be attached to some other line of code is not the best way to go about it.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2017-03-25 15:58 +0100 |
| Message-ID | <ob60j7$hrp$1@gioia.aioe.org> |
| In reply to | #107031 |
On 3/25/2017 2:37 AM, David Brown wrote:
> On 25/03/17 02:10, James Kuyper wrote:
>> On 03/24/2017 07:49 PM, David Brown wrote:
>>> On 24/03/17 20:10, James Kuyper wrote:
>>>> On 03/24/2017 02:16 PM, David Brown wrote:
>>>>> On 24/03/17 19:04, James Kuyper wrote:
>>>>>> On 03/24/2017 01:48 PM, David Brown wrote:
>>>>>> ...
>>>>>>> While malloc only cares about the size of the allocation, I think
>>>>>>> the
>>>>>>> type /is/ important here. If you have "widget *p; p = malloc(sizeof
>>>>>>> gadget);", then the code almost certainly has a big bug even if
>>>>>>> "gadget"
>>>>
>>>> I just realized that your example is a syntax error unless gadget is
>>>> the
>>>> name of a variable. I had thought it was meant to be a typedef name.
>>>> Had
>>>> you intended to write
>>>>
>>>> p = malloc(sizeof(gadget));
>>>
>>> Yes, that was my intention. Sorry for the mistake.
>> ...
>>> Another silly mistake from me. I must have made that post in a rush.
>>
>> I assumed as much - I just had no idea what your example would have
>> looked like if written as intended.
>>
>>> p = malloc(sizeof *p);
>>>
>>> is not /wrong/. I just wonder if it would make it harder to spot a
>>> logical flaw in the program if the user has got his types mixed up.
>>
>> I don't see how. A type mix-up is guaranteed to not be a problem with
>> this version of the code; once the user realizes that, it frees him to
>> pay more attention to lines of code that might actually be affected by
>> such a mixup.
>>
>
<snip>
>
> Having the name of the type in the malloc line might be a help too.
> Whether that is a useful enough point to make it worth putting the type
> name there is another matter - but it /might/ make code clearer to some
> people.
>
>
I, FWIW, tend to prefer p = malloc(sizeof *p); for the reasons that both
Richard and James pointed out. However, you have some point in this last
part - I regard type safety as highly valued.
That said, looking closely at this point, I think that p =
malloc(sizeof(widget)); still does not best answer your point. To me it
looks that, aiming to make the type this explicit, the programmer should
go for
widget* p = malloc(sizeof *p);
i.e. avoid malloc as assignment, and use it for initialization instead
(which has by definition built-in type declaration)
If this requires changing a few extra lines of code, IMHO this is work
well spent.
In a situation where it would be redundant to re-declare the type, as in
void create_widget(widget** pp)
{
*pp = malloc(sizeof **pp);
...
}
then the declaration of pp (as here being an argument) should be close
enough to avoid confusion about its type. Furthermore, a valid
alternative is also
void create_widget(widget** pp)
{
widget *p = malloc(sizeof *p);
...
*pp = p;
}
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-24 12:44 -0700 |
| Message-ID | <lnr31m8nok.fsf@kst-u.example.com> |
| In reply to | #106967 |
David Brown <david.brown@hesbynett.no> writes:
> On 24/03/17 19:04, James Kuyper wrote:
>> On 03/24/2017 01:48 PM, David Brown wrote:
>> ...
>>> While malloc only cares about the size of the allocation, I think the
>>> type /is/ important here. If you have "widget *p; p = malloc(sizeof
>>> gadget);", then the code almost certainly has a big bug even if "gadget"
>>> and "widget" are the same size. The allocation will be fine, but you've
>>> got a logical bug somewhere.
>>
>> Yes, but "sizeof *p" avoids that problem perfectly, without making any
>> mention of the type.
>
> No, it makes this bug even harder to find.
>
> If the user writes "p = malloc(sizeof gadget)" when p is declared as
> "widget *", then you can see that they are mixing up gadgets and
> widgets. If the user, with the same logical mixup, writes "p =
> malloc(*p)", then it is harder to spot the logical flaw.
I don't understand. Did you mean to omit the "sizeof" keyword in your
example?
If you write
p = malloc(*p);
then that's almost certainly a bug, and one that the compiler probably
won't catch if *p has a numeric type. But if you write
p = malloc(sizeof *p);
then you *can't* mix up gadgets and widgets. If p is a pointer to
gadget, it allocates space for one gadget; if p is a pointer to widget,
it allocates space for one widget.
> The point is, there is a bug somewhere. If you are lucky, the compiler
> can help find it. Less lucky, you can see it from the code.
>
> I am not saying that writing "malloc(sizeof gadget)" is necessarily a
> good idea overall - but it may have some merits.
If gadget is a type, this has to be `malloc(sizeof (gadget))`.
I presume that you're making a valid point, but I'm unable to determine
what it is. Can you clarify?
[...]
There is one valid point I can think of here. It's reasonable to argue
that this:
p = (gadget*)malloc(sizeof (gadget));
is safer than:
p = malloc(sizeof (gadget));
If p is of type gadget*, both are correct. If p is of type widget*,
then both are incorrect, but only the first will be caught by the
compiler. So *if* you use `sizeof (type_name)` rather than `sizeof
*pointer_object`, and *if* you manage to keep the two references to the
type name consistent, then a cast can help the compiler detect errors
that it would not detect without the cast.
But I still maintain that
p = malloc(sizeof *p);
is better than either. It doesn't includes a reminder that p points to
a widget, but no such reminder is needed at that point. If you need to
remember what p points to, look at its declaration, or at the code that
uses it.
Similarly, I can write
n ++;
without having to specify which numeric type n has. I could remind
myself that it's, say, an unsigned int by writing:
n = (unsigned int)(n + 1);
but that's hardly an improvement. There's a simple way to write it that
doesn't require specifying the type. (This case is admittedly different
because, unlike pointers, numeric types can be implicitly converted, so
the above probably won't be diagnosed even if n is a signed char.)
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-24 12:07 -0700 |
| Message-ID | <1b709495-03da-462d-926f-3ee2be0a7ab5@googlegroups.com> |
| In reply to | #106961 |
On Friday, March 24, 2017 at 12:48:53 PM UTC-5, David Brown wrote:
> I do have a copy of MISRA, and I'd guess very roughly that 60% of the
> rules are quite good ideas, 20% are not particularly helpful, and 20%
> are downright bad. Many of the good ones are pretty obvious (like "do
> not rely on undefined behaviour"). Many of the ones I consider bad had
> are motivated by poor tools - a developer (especially for the kinds of
> software where MISRA is appropriate) should get better tools rather than
> write less clear code. And some are a matter of style and opinion.
A fair portion of the rules stem from the fact that the C Standard makes
no effort to require that all implementations be suitable for purposes
served by MISRA, and thus affords compilers a degree of flexibility which
is counter-productive toward such aims.
MISRA, for example, takes the view that all computations should involve
precisely-sized operators, and programmers should perform all type
conversions manually, but C has no such concept. Given:
uint16_t x,y;
code needing the mod-65536 product of x and y can't simply multiply them,
nor even multiply them and cast the result to uint16_t. To be assured of
reliable operation one would need to do something like (uint16_t)(1u*x*y).
MISRA doesn't like the type "unsigned", but using the unsigned constant
1u is probably the least-bad way of preventing 32-bit compilers from
malfunctioning in cases where x*y would exceed 2147483647 without
encouraging 16-bit compilers to performing a silly 32x32 multiply.
Also, while it's easy to take the attitude that lower-quality tools should
be replaced, replacing a tool may often require requalifying all code that
was processed using it. If the code in question has been working 100%
reliably for decades, there can be significant advantages to continuing to
use the existing code and tooling.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-25 00:54 +0100 |
| Message-ID | <ob4bek$j4$1@dont-email.me> |
| In reply to | #106983 |
On 24/03/17 20:07, supercat@casperkitty.com wrote: > On Friday, March 24, 2017 at 12:48:53 PM UTC-5, David Brown wrote: >> I do have a copy of MISRA, and I'd guess very roughly that 60% of the >> rules are quite good ideas, 20% are not particularly helpful, and 20% >> are downright bad. Many of the good ones are pretty obvious (like "do >> not rely on undefined behaviour"). Many of the ones I consider bad had >> are motivated by poor tools - a developer (especially for the kinds of >> software where MISRA is appropriate) should get better tools rather than >> write less clear code. And some are a matter of style and opinion. > > Also, while it's easy to take the attitude that lower-quality tools should > be replaced, replacing a tool may often require requalifying all code that > was processed using it. If the code in question has been working 100% > reliably for decades, there can be significant advantages to continuing to > use the existing code and tooling. > Replacing your /compiler/ can certainly be a big tasks, requiring requalifying code. And for some targets, decent compilers may not be available. But there are plenty of other tools available for static error checking. There is /no/ excuse for writing Yoda-style conditionals such as "if (3 == x) ... " to satisfy MISRA's reasoning that it catches typos like "if (x = 3) ...". If your compiler cannot warn you that "if (x = 3) ..." is suspicious code, run your code through a different compiler for checking - or use "pc-lint" or similar programs.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-03-25 10:16 +0000 |
| Message-ID | <58d642e0.2297265@news.xs4all.nl> |
| In reply to | #107018 |
David Brown <david.brown@hesbynett.no> wrote: > But there are plenty of other tools available for static error checking. > There is /no/ excuse for writing Yoda-style conditionals such as "if > (3 == x) ... " to satisfy MISRA's reasoning that it catches typos like > "if (x = 3) ...". If your compiler cannot warn you that "if (x = 3) > ..." is suspicious code, run your code through a different compiler for > checking - or use "pc-lint" or similar programs. It's even worse than that. Many (maybe most, I can't be gluteused to check) comparisons are between objects, not one object and one constant. People who write if (3 == x) think they're safe, and then they write if (y = x) by accident. People who write if (x == 3) check out of habit, and therefore will not write if (x = y) unless they intend to. Richard
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-25 12:32 +0000 |
| Message-ID | <ob5nrt$9bt$1@dont-email.me> |
| In reply to | #107038 |
On 25/03/17 10:16, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> But there are plenty of other tools available for static error checking. >> There is /no/ excuse for writing Yoda-style conditionals such as "if >> (3 == x) (David: how is that "Yoda style"? The applicable grammar here is C, not English. Do you think comparison imposes a grammatical ordering on comparands?) > ... " to satisfy MISRA's reasoning that it catches typos like >> "if (x = 3) ...". If your compiler cannot warn you that "if (x = 3) >> ..." is suspicious code, run your code through a different compiler for >> checking - or use "pc-lint" or similar programs. > > It's even worse than that. Many (maybe most, I can't be gluteused to > check) comparisons are between objects, not one object and one constant. > People who write if (3 == x) think they're safe, Not all of them. > and then they write if (y = x) by accident. And then they search their C source for = to ensure that every assignment is supposed to be an assignment and every comparison is meant to be a comparison, just like those who write x == 3. In fact, the only difference between the x == 3-er and the 3 == x-er (all else being equal) is that the 3 == x-er gains the benefit of the compiler's help if he happened to miss something (and indeed many compilers will in any case flag up x = 3 anyway). > People who write if (x == 3) check out of habit, Except, of course, for those who don't check. Likewise, people who write if(3 == x) check out of habit, except for those who don't. > and therefore will not write if (x = y) unless they intend to. Well, they might not. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-25 15:17 +0100 |
| Message-ID | <ob5u0k$so5$1@dont-email.me> |
| In reply to | #107040 |
On 25/03/17 13:32, Richard Heathfield wrote: > On 25/03/17 10:16, Richard Bos wrote: >> David Brown <david.brown@hesbynett.no> wrote: >> >>> But there are plenty of other tools available for static error checking. >>> There is /no/ excuse for writing Yoda-style conditionals such as "if >>> (3 == x) > > (David: how is that "Yoda style"? The applicable grammar here is C, not > English. Do you think comparison imposes a grammatical ordering on > comparands?) "Yoda style" means writing things in an odd order for some imagined safety or efficiency benefit. It is normal (for English speakers, anyway) to say "if x is 3 then ...". Thus the clearest and most natural C equivalent is "if (x == 3) ...". If like Yoda you want to talk, and to say "if 3 is x ..." you prefer, then "if (3 == x)" you write. > >> ... " to satisfy MISRA's reasoning that it catches typos like >>> "if (x = 3) ...". If your compiler cannot warn you that "if (x = 3) >>> ..." is suspicious code, run your code through a different compiler for >>> checking - or use "pc-lint" or similar programs. >> >> It's even worse than that. Many (maybe most, I can't be gluteused to >> check) comparisons are between objects, not one object and one constant. >> People who write if (3 == x) think they're safe, > > Not all of them. > >> and then they write if (y = x) by accident. > > And then they search their C source for = to ensure that every > assignment is supposed to be an assignment and every comparison is meant > to be a comparison, just like those who write x == 3. In fact, the only > difference between the x == 3-er and the 3 == x-er (all else being > equal) is that the 3 == x-er gains the benefit of the compiler's help if > he happened to miss something (and indeed many compilers will in any > case flag up x = 3 anyway). The difference is that "if (x == 3)" is more natural to write (and read) - and thus better than "if (3 == x)". Writing "if (3 == x)" has a benefit /only/ if you have poor tools (or don't know how to use them correctly) which are unable to warn you if you write "if (x = 3)". > >> People who write if (x == 3) check out of habit, > > Except, of course, for those who don't check. Likewise, people who write > if(3 == x) check out of habit, except for those who don't. > >> and therefore will not write if (x = y) unless they intend to. > > Well, they might not. >
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-25 16:32 +0000 |
| Message-ID | <ob65u2$mi8$1@dont-email.me> |
| In reply to | #107041 |
On 25/03/17 14:17, David Brown wrote: > On 25/03/17 13:32, Richard Heathfield wrote: >> On 25/03/17 10:16, Richard Bos wrote: >>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>> But there are plenty of other tools available for static error >>>> checking. >>>> There is /no/ excuse for writing Yoda-style conditionals such as "if >>>> (3 == x) >> >> (David: how is that "Yoda style"? The applicable grammar here is C, not >> English. Do you think comparison imposes a grammatical ordering on >> comparands?) > > "Yoda style" means writing things in an odd order for some imagined > safety or efficiency benefit. It is normal (for English speakers, > anyway) to say "if x is 3 then ...". Thus the clearest and most natural > C equivalent is "if (x == 3) ...". > > If like Yoda you want to talk, and to say "if 3 is x ..." you prefer, > then "if (3 == x)" you write. You are still confusing English and C. x == y doesn't mean "x is y". Nor does it mean "y is x". It means that its two operands evaluate to the same value. > Writing "if (3 == x)" has a benefit /only/ if you have poor tools (or > don't know how to use them correctly) which are unable to warn you if > you write "if (x = 3)". Writing if(3 == x) does indeed have at least that benefit. Writing if(x == 3) has no commensurate benefit. -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-25 10:15 -0700 |
| Message-ID | <lnefxl8eh0.fsf@kst-u.example.com> |
| In reply to | #107044 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 25/03/17 14:17, David Brown wrote:
>> On 25/03/17 13:32, Richard Heathfield wrote:
>>> On 25/03/17 10:16, Richard Bos wrote:
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>
>>>>> But there are plenty of other tools available for static error
>>>>> checking.
>>>>> There is /no/ excuse for writing Yoda-style conditionals such as "if
>>>>> (3 == x)
>>>
>>> (David: how is that "Yoda style"? The applicable grammar here is C, not
>>> English. Do you think comparison imposes a grammatical ordering on
>>> comparands?)
>>
>> "Yoda style" means writing things in an odd order for some imagined
>> safety or efficiency benefit. It is normal (for English speakers,
>> anyway) to say "if x is 3 then ...". Thus the clearest and most natural
>> C equivalent is "if (x == 3) ...".
>>
>> If like Yoda you want to talk, and to say "if 3 is x ..." you prefer,
>> then "if (3 == x)" you write.
>
> You are still confusing English and C.
>
> x == y doesn't mean "x is y". Nor does it mean "y is x". It means that
> its two operands evaluate to the same value.
`x == y` means "x is equal to y" (I think that's a good English
rendition of the C semantics).
>> Writing "if (3 == x)" has a benefit /only/ if you have poor tools (or
>> don't know how to use them correctly) which are unable to warn you if
>> you write "if (x = 3)".
>
> Writing if(3 == x) does indeed have at least that benefit. Writing if(x
> == 3) has no commensurate benefit.
Of course `x == 3` and `3 == x` mean exactly the same thing in C. But
for me, and for a *lot* of people, `x == 3` is the natural way to write
it, and `3 == x` is almost painfully awkward. If you don't find it
awkward, that's great, but a lot of us do.
In English, the meaning of "Found someone you have I would say, hmm?" is
perfectly clear, but we don't talk that way unless we're specifically
imitating Yoda, because it's awkward. I find `3 == x` equally awkward.
--
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 | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-25 14:07 -0400 |
| Message-ID | <ca174a1a-8727-c000-269b-1244ddb98b9b@verizon.net> |
| In reply to | #107046 |
On 03/25/2017 01:15 PM, Keith Thompson wrote: ... > In English, the meaning of "Found someone you have I would say, hmm?" is > perfectly clear, but we don't talk that way unless we're specifically > imitating Yoda, because it's awkward. I find `3 == x` equally awkward. There's a key difference - Yoda's use of "English" (obviously he's speaking some other language, represented as English in the movies) is not merely awkward, it often violates English grammar rules. The words themselves contain enough information for us to reconstruct what a grammatically correct version of the same statement would look like - but that's probably only because the writers would not have bothered presenting us with any of the cases where Yoda's preferred word ordering is so different from that of "English" as to render his meaning incomprehensible. Possibly Yoda himself has learned to avoid those cases. 3==x does not violate C's grammar rules, so I can't see the two examples as "equally awkward".
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web