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 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-03-25 19:35 +0000 |
| Message-ID | <slrn3vfsoddhoq.aa0.ike@iceland.freeshell.org> |
| In reply to | #107041 |
On 2017-03-25, David Brown <david.brown@hesbynett.no> wrote:
> "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) ...".
English is not my native language, but at school I was taught that
"x == 3" is not read as "x is three", but as "x equals three", and
to my ears that sounds just as acceptable as "three equals x".
Does the Yoda problem extend to, say, the plus operator as well?
Is "epsilon + 1" ("epsilon plus one") okay, while "1 + epsilon"
("one plus epsilon") sounds awkward?
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-03-25 21:37 +0000 |
| Message-ID | <58d6e239.20514265@news.xs4all.nl> |
| In reply to | #107055 |
Ike Naar <ike@iceland.freeshell.org> wrote:
> Does the Yoda problem extend to, say, the plus operator as well?
> Is "epsilon + 1" ("epsilon plus one") okay, while "1 + epsilon"
> ("one plus epsilon") sounds awkward?
Up to a point. They're both possible, but they read differently, In the
first case, I would expect epsilon to be the main quantity, and 1 to be
an adjustment to its value. In the second, I would expect 1 to be the
main value, and epsilon to be a small value added to it - a true
epsilon, that is. (And I'd be slightly surprised not to find it written
as 1.0 + epsilon.)
Let's give another example. I'd always write
#define MAX_NAME_LENGTH 64
char name_string[MAX_NAME_LENGTH + 1];
and _never_
char name_string[1 + MAX_NAME_LENGTH];
There is a natural order to these things; most people _read_ code, they
don't just process it.
Richard
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-26 08:39 +0100 |
| Message-ID | <ob7r2g$vne$1@dont-email.me> |
| In reply to | #107055 |
On 25/03/17 19:35, Ike Naar wrote: > On 2017-03-25, David Brown <david.brown@hesbynett.no> wrote: >> "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) ...". > > English is not my native language, but at school I was taught that > "x == 3" is not read as "x is three", but as "x equals three", and > to my ears that sounds just as acceptable as "three equals x". Right. > Does the Yoda problem extend to, say, the plus operator as well? I would imagine that, for those people who struggle with "are 3 and x the same?", "1 + epsilon" would also be difficult. Personally, ever since I can remember, I have always considered addition to be commutative. -- 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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-03-25 21:21 +0000 |
| Message-ID | <58d6dd90.19321421@news.xs4all.nl> |
| In reply to | #106961 |
David Brown <david.brown@hesbynett.no> wrote: > 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. Well, except that the main danger of superfluous casts is _not_ that they might introduce bugs in the program. They rarely by accident; at most, an already wildly confused programmer might use them to force a compiler to accept major hackery involving pointer aliasing, but both such code and such programmers are broken, anyway, and the casts are merely a symptom. They don't introduct _new_ bugs. No, the real danger in superfluous casts is that they make the programmer think "oh, yawn, another cast, probably another malloc() call written by a C++ programmer - just ignore it", when what he _should_ think on seeing a cast is "Whoop! Whoop! Red alert! Someone is doing something unusual with the type system! Better be extra certain that what happens here is correct." Note that assigning the void * you get from malloc() to any other type of object pointer is _not_ something unusual with the type system, does _not_ need more attention than any other assignment, and therefore does not warrant the cast. Putting a cast there means depreciating the warning value of all appropriate casts. _That_ is the danger: not in the code, but in the mind of the programmer. Stop the brain rot. Do not cast malloc(). Richard
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-25 16:54 -0500 |
| Message-ID | <ob6oh4$kb7$1@dont-email.me> |
| In reply to | #107074 |
Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> 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. > > Well, except that the main danger of superfluous casts is _not_ that > they might introduce bugs in the program. They rarely by accident; > at most, an already wildly confused programmer might use them to > force a compiler to accept major hackery involving pointer aliasing, > but both such code and such programmers are broken, anyway, and the > casts are merely a symptom. They don't introduct _new_ bugs. > > No, the real danger in superfluous casts is that they make the > programmer think "oh, yawn, another cast, probably another malloc() > call written by a C++ programmer - just ignore it", when what he > _should_ think on seeing a cast is "Whoop! Whoop! Red alert! Someone > is doing something unusual with the type system! Better be extra > certain that what happens here is correct." Note that assigning the > void * you get from malloc() to any other type of object pointer is > _not_ something unusual with the type system, does _not_ need more > attention than any other assignment, and therefore does not warrant > the cast. Putting a cast there means depreciating the warning value > of all appropriate casts. _That_ is the danger: not in the code, but > in the mind of the programmer. > > Stop the brain rot. Do not cast malloc(). > You sort-of, semi-have-to if you're doing a certain class of C things using a C++ compiler. Intermixed code bases exist. I don't remember specifically, but it may be that new/delete work in C code for most C++ compilers, but then that precludes reusing a module with different toolchains. Things like FFTW have casts all over the place, but provide typed mallocs for those who wish to use them. They do not use them in their example code. I haven't seen a bug that would have been improved on by stronger typing in ages. Software defects *are a cultural problem, not a problem of technology*. People decide to trade things like technical debt for other things like money. So it goes. Of course, if you're in a culture where it's expected, then that's different, but there's very little empirical support for it in my book. That's the violation of an arbitrary cultural norm, which is hardly even a venal sin. I can say that here, because I have my C programmer hat on. Sloppy typing is just a way of life in C. The problem is that the C language itself naturally limits team size. That's nature's way of telling you to be humble in what you try to accomplish. > Richard > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-03-25 22:32 +0000 |
| Message-ID | <58d6efa3.23948046@news.xs4all.nl> |
| In reply to | #107079 |
Les Cargill <lcargill99@comcast.com> wrote: > Richard Bos wrote: > > Stop the brain rot. Do not cast malloc(). > > You sort-of, semi-have-to if you're doing a certain class of > C things using a C++ compiler. "Doctor, doctor, it hurts when I poke sticks into my eyes!" > Intermixed code bases exist. Yes, and that's why extern "C" exists. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-26 13:46 -0700 |
| Message-ID | <711f4140-eac3-4c0f-95e9-e1e083ec82df@googlegroups.com> |
| In reply to | #107074 |
On Saturday, March 25, 2017 at 4:21:10 PM UTC-5, Richard Bos wrote: > Well, except that the main danger of superfluous casts is _not_ that > they might introduce bugs in the program. They rarely by accident; at > most, an already wildly confused programmer might use them to force a > compiler to accept major hackery involving pointer aliasing, but both > such code and such programmers are broken, anyway, and the casts are > merely a symptom. They don't introduct _new_ bugs. In some application fields, code using pointer aliasing techniques may be considered broken, but in other fields they merely mean that code will not be portable to all implementations, but merely to implementations suitable for the application fields in question.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-03 17:39 +0000 |
| Message-ID | <58e28868.10501859@news.xs4all.nl> |
| In reply to | #107117 |
supercat@casperkitty.com wrote: > On Saturday, March 25, 2017 at 4:21:10 PM UTC-5, Richard Bos wrote: > > Well, except that the main danger of superfluous casts is _not_ that > > they might introduce bugs in the program. They rarely by accident; at > > most, an already wildly confused programmer might use them to force a > > compiler to accept major hackery involving pointer aliasing, but both > > such code and such programmers are broken, anyway, and the casts are > > merely a symptom. They don't introduct _new_ bugs. > > In some application fields, code using pointer aliasing techniques That is not what casting malloc() is about, so stop trying to force your pseudo-1970s bat out of your belfry and into this thread. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-03 11:42 -0700 |
| Message-ID | <d777360e-2831-49f4-b6a3-3664e056b2c5@googlegroups.com> |
| In reply to | #107680 |
On Monday, April 3, 2017 at 12:39:07 PM UTC-5, Richard Bos wrote: > supercat wrote: > > In some application fields, code using pointer aliasing techniques > > That is not what casting malloc() is about, so stop trying to force your > pseudo-1970s bat out of your belfry and into this thread. Who said anything about casting malloc? I was thinking about code that interprets collections of bits as different types depending upon context. Sometimes this is done because it allows chunking optimizations to perform actions upon multiple objects at once (e.g. if one needs to xor a sequence of bytes with 0xFF, that might be accomplished 4 times as fast using 32-bit operations as using 8-bit ones), sometimes (though less commonly) it is done because it allows read-modify-write sequences to be replaced with simple writes (e.g. if code needs to compute the floor of a bunch of 32-bit values, writing zeroing the lower half-word may be faster than reading each value, and'ing with 0xFFFF0000, and then writing it back), and sometimes it is done because it's necessary to have a new structure type which is compatible with an older one but replaces a "reserved" 32-bit integer with a 32-bit pointer (classic Macintosh OS did this around version 4 when it added support for Quickdraw II; if memory serves, the value in question had been very close to the start of the structure, so implementations would not have been required to honor the CIS for accessing any members beyond, but any compiler that didn't honor the CIS in such cases would have been unsuitable for use writing color graphics applications for the Macintosh OS).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-03 12:10 -0700 |
| Message-ID | <lnk2711f47.fsf@kst-u.example.com> |
| In reply to | #107685 |
supercat@casperkitty.com writes:
> On Monday, April 3, 2017 at 12:39:07 PM UTC-5, Richard Bos wrote:
>> supercat wrote:
>> > In some application fields, code using pointer aliasing techniques
>>
>> That is not what casting malloc() is about, so stop trying to force your
>> pseudo-1970s bat out of your belfry and into this thread.
>
> Who said anything about casting malloc?
That's what this thread was about.
Three articles directly upthread from your response, Richard Bos wrote:
No, the real danger in superfluous casts is that they make the
programmer think "oh, yawn, another cast, probably another malloc() call
written by a C++ programmer - just ignore it", when what he _should_
think on seeing a cast is "Whoop! Whoop! Red alert! Someone is doing
something unusual with the type system! Better be extra certain that
what happens here is correct."
Note that assigning the void * you get from malloc() to any other type
of object pointer is _not_ something unusual with the type system, does
_not_ need more attention than any other assignment, and therefore does
not warrant the cast. Putting a cast there means depreciating the
warning value of all appropriate casts. _That_ is the danger: not in the
code, but in the mind of the programmer.
Stop the brain rot. Do not cast malloc().
You can verify this yourself if your newsreader lets you view the parent
of an article. Please do so.
--
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-04-03 15:22 -0700 |
| Message-ID | <1390ce6f-8b1d-4d85-8250-49d01251beb4@googlegroups.com> |
| In reply to | #107690 |
On Monday, April 3, 2017 at 2:11:00 PM UTC-5, Keith Thompson wrote: > supercat writes: > > On Monday, April 3, 2017 at 12:39:07 PM UTC-5, Richard Bos wrote: > >> supercat wrote: > >> > In some application fields, code using pointer aliasing techniques > >> > >> That is not what casting malloc() is about, so stop trying to force your > >> pseudo-1970s bat out of your belfry and into this thread. > > > > Who said anything about casting malloc? > > That's what this thread was about. Okay; I'd lost track of that, but the post to which I was responding said: On Saturday, March 25, 2017 at 4:21:10 PM UTC-5, Richard Bos wrote: > Well, except that the main danger of superfluous casts is _not_ that > they might introduce bugs in the program. They rarely by accident; at > most, an already wildly confused programmer might use them to force a > compiler to accept major hackery involving pointer aliasing, but both > such code and such programmers are broken, anyway, and the casts are > merely a symptom. They don't introduct _new_ bugs. Did I let myself get trolled? I'm a pretty easy mark I'll admit.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-05 11:01 +0000 |
| Message-ID | <58e4cdae.419375@news.xs4all.nl> |
| In reply to | #107703 |
supercat@casperkitty.com wrote: > On Monday, April 3, 2017 at 2:11:00 PM UTC-5, Keith Thompson wrote: > > supercat writes: > > > On Monday, April 3, 2017 at 12:39:07 PM UTC-5, Richard Bos wrote: > > >> supercat wrote: > > >> > In some application fields, code using pointer aliasing techniques > > >> > > >> That is not what casting malloc() is about, so stop trying to force your > > >> pseudo-1970s bat out of your belfry and into this thread. > > > > > > Who said anything about casting malloc? > > > > That's what this thread was about. > > Okay; I'd lost track of that, but the post to which I was responding said: > > On Saturday, March 25, 2017 at 4:21:10 PM UTC-5, Richard Bos wrote: > > Well, except that the main danger of superfluous casts is _not_ that > > they might introduce bugs in the program. They rarely by accident; at > > most, an already wildly confused programmer might use them to force a > > compiler to accept major hackery involving pointer aliasing, but both > > such code and such programmers are broken, anyway, and the casts are > > merely a symptom. They don't introduct _new_ bugs. > > Did I let myself get trolled? I'm a pretty easy mark I'll admit. No, you (and I'm beginning to think intentionally) got yourself trolled by yourself. You quote-mined to allow you to get your point in (the same point for the three hundreth time in two years), which is always a bad idea. It makes creationists _and_ atheists look foolish, and it does the same to you. Here, let me quote another line from that post you want us to believe said nothing about malloc(): # Stop the brain rot. Do not cast malloc(). Easy to mistake for a general statement about pointer aliasing in "some application fields", isn't it? Richard
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-26 08:45 +0100 |
| Message-ID | <ob7rdo$162$1@dont-email.me> |
| In reply to | #106961 |
On 24/03/17 17:48, David Brown wrote: > And then you can safely cast your pointer if you want C++ compatibility > - the risk of introducing a mistake here is very small. If you are calling malloc, you have already given up C++ compatibility, because that isn't the C++ way of doing things. If you want a dynamically allocated object or fixed size array, you use new, and if you want a resizeable array you use std::vector. -- 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-26 02:35 -0700 |
| Message-ID | <ln1stk8jnu.fsf@kst-u.example.com> |
| In reply to | #107092 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 24/03/17 17:48, David Brown wrote:
>> And then you can safely cast your pointer if you want C++ compatibility
>> - the risk of introducing a mistake here is very small.
>
> If you are calling malloc, you have already given up C++ compatibility,
> because that isn't the C++ way of doing things. If you want a
> dynamically allocated object or fixed size array, you use new, and if
> you want a resizeable array you use std::vector.
Or you use malloc, which is part of the C++ standard library.
Valid reasons to write code that's valid both as C and as C++ are rare,
but they're not nonexistent.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-26 17:19 +0200 |
| Message-ID | <ob8lvn$di3$1@dont-email.me> |
| In reply to | #107095 |
On 26/03/17 11:35, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> On 24/03/17 17:48, David Brown wrote: >>> And then you can safely cast your pointer if you want C++ compatibility >>> - the risk of introducing a mistake here is very small. >> >> If you are calling malloc, you have already given up C++ compatibility, >> because that isn't the C++ way of doing things. Using malloc does not give up C++ compatibility in any way. It means you are writing non-idiomatic C++ code - but you can't write idiomatic C++ code with any hope of keeping C compatibility. > If you want a >> dynamically allocated object or fixed size array, you use new, and if >> you want a resizeable array you use std::vector. > > Or you use malloc, which is part of the C++ standard library. > > Valid reasons to write code that's valid both as C and as C++ are rare, > but they're not nonexistent. > I have had occasion to do so myself - the valid reason being "that's what the customer wanted". There were no mallocs in the code, or any other casts of void*, however. It is very common to want headers to be valid as both C and C++, but I think it is going to be rare to see casts of malloc() in header code.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-27 08:15 +0100 |
| Message-ID | <obae1n$52e$1@dont-email.me> |
| In reply to | #107095 |
On 26/03/17 10:35, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 24/03/17 17:48, David Brown wrote:
>>> And then you can safely cast your pointer if you want C++ compatibility
>>> - the risk of introducing a mistake here is very small.
>>
>> If you are calling malloc, you have already given up C++ compatibility,
>> because that isn't the C++ way of doing things. If you want a
>> dynamically allocated object or fixed size array, you use new, and if
>> you want a resizeable array you use std::vector.
>
> Or you use malloc, which is part of the C++ standard library.
And scanf("%s", s) is part of the C standard library, but that doesn't
make it good practice.
> Valid reasons to write code that's valid both as C and as C++ are rare,
> but they're not nonexistent.
Fair enough - but I hope we don't base general "good practice" advice on
what you have to do in a vanishingly small minority of cases that should
in any case only be tackled by experts (i.e. people who already know
what good practice is, and know too why, just in that one tiny case,
there is a reason why the usually-best way isn't best on that occasion).
*In general*, C++ programmers should not be using malloc, and C
programmers should therefore not be casting malloc "for C++
compatibility". If C++ needs to call C code that contains malloc, well,
that's why we have libraries.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-24 15:12 -0400 |
| Message-ID | <ob3qsu$4r2$2@jstuckle.eternal-september.org> |
| In reply to | #106953 |
On 3/24/2017 1:10 PM, 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. > > 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. > Well, if you think this standard is incorrect, you are quite able to recommend CERT change it. But you need a good *technical* reason to do so. And that I have yet to see from anyone in this group. And yes, CERT is a widely recognized authority on the subject. Much more so than anyone in this newsgroup. CERT's reasoning is quite valid - the type is important, and size is directly dependent on type. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-25 08:41 +1300 |
| Message-ID | <ejlb41FmdulU5@mid.individual.net> |
| In reply to | #106946 |
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. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2017-03-24 16:27 -0600 |
| Message-ID | <1by3vu8g57.fsf@pfeifferfamily.net> |
| In reply to | #106995 |
Ian Collins <ian-news@hotmail.com> writes: > 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. Watching him carefully ignore the fact that the authority he is appealing to in fact accepts the p = malloc(sizeof *p) version is possibly the funniest part of this exchange.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-24 21:36 -0400 |
| Message-ID | <ob4hdp$feg$1@dont-email.me> |
| In reply to | #107011 |
On 03/24/2017 06:27 PM, Joe Pfeiffer wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> 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. > > Watching him carefully ignore the fact that the authority he is > appealing to in fact accepts the p = malloc(sizeof *p) version is > possibly the funniest part of this exchange. To be fair, while Robert Seacord has described this as a "compliant solution", I don't see any way to interpret the wording of the actual recommendation as allowing this construct to be considered compliant, and Stuckle's immediate response when first informed of that comment was to point out that fact: > Which is *noncomplient*. Reasonable or not. Secondly, the current recommendation is not Seacord's. He is listed as the person who created this recommendation, but the recommendation he created was quite different. Seacord himself wrote: "Originally the recommendation was to not cast, which upset a lot of people ... The current recommendation was written by Dan Saks, ...".
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web