Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #63176 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-06-10 22:32 -0700 |
| Last post | 2015-06-10 23:07 -0700 |
| Articles | 20 on this page of 182 — 25 participants |
Back to article view | Back to comp.lang.c
Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-10 22:32 -0700
Re: Reason for segmentation violation Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2015-06-11 07:52 +0200
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-11 07:19 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 15:46 +0100
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-11 11:23 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-11 12:08 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-11 15:44 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-11 12:55 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-11 16:29 -0400
Re: Reason for segmentation violation gordonb.h0fbo@burditt.org (Gordon Burditt) - 2015-06-17 23:51 -0500
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-17 23:10 -0700
Re: Reason for segmentation violation gordonb.0vo9r@burditt.org (Gordon Burditt) - 2015-06-18 03:30 -0500
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 02:40 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-11 21:00 +0100
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-11 19:58 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-11 23:42 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-12 08:33 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-12 02:36 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-12 11:07 +0100
Re: Reason for segmentation violation gwowen <gwowen@gmail.com> - 2015-06-12 04:55 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-12 13:17 +0100
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-12 13:32 +0100
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-12 13:20 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-13 23:55 -0700
Restrictions on inline functions (Was: Reason for segmentation violation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-14 10:30 +0100
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-12 11:10 -0400
Re: Reason for segmentation violation David Thompson <dave.thompson2@verizon.net> - 2015-06-21 12:46 -0400
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 08:35 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-12 12:21 -0400
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 10:48 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-12 19:12 +0100
Re: Reason for segmentation violation David Kleinecke <dkleinecke@gmail.com> - 2015-06-12 08:49 -0700
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 09:13 -0700
Re: Reason for segmentation violation David Kleinecke <dkleinecke@gmail.com> - 2015-06-13 08:55 -0700
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 08:56 -0700
Re: Reason for segmentation violation glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-12 09:41 +0000
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-12 08:29 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 00:03 -0700
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-14 00:58 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 02:14 -0700
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-14 04:26 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 06:29 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-14 15:06 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 07:25 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-14 16:59 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 11:51 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-14 16:43 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 14:16 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-14 20:35 -0400
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-15 01:19 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 03:57 -0700
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-15 12:26 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 04:47 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 15:02 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 07:08 -0700
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-15 18:56 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 20:09 -0700
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-16 09:31 +0100
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 10:09 +0100
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-16 02:36 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 11:01 +0100
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 12:37 +0100
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-16 08:40 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-16 10:32 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-17 07:54 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 05:28 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-18 00:34 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:13 +0200
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-19 21:17 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-20 23:28 +0200
Re: Reason for segmentation violation "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-15 05:26 -0700
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-15 06:20 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 14:25 +0100
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-15 07:52 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 18:29 +0100
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-15 11:15 -0700
Re: Reason for segmentation violation raltbos@xs4all.nl (Richard Bos) - 2015-06-18 20:41 +0000
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-15 18:48 +0100
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-15 11:04 -0700
Re: Reason for segmentation violation raltbos@xs4all.nl (Richard Bos) - 2015-06-18 20:44 +0000
Re: Reason for segmentation violation David Brown <david.brown@hesbynett.no> - 2015-06-19 10:39 +0200
Re: Reason for segmentation violation gwowen <gwowen@gmail.com> - 2015-06-16 00:58 -0700
Re: Reason for segmentation violation raltbos@xs4all.nl (Richard Bos) - 2015-06-18 20:40 +0000
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-18 17:06 -0400
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 14:56 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 23:04 +0100
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-18 18:18 -0400
Re: Reason for segmentation violation David Brown <david.brown@hesbynett.no> - 2015-06-19 10:26 +0200
Re: Reason for segmentation violation David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 08:57 -0700
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-15 08:54 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 06:24 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 14:32 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 05:43 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-14 23:28 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 16:31 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 01:27 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 05:34 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 15:00 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 20:37 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 09:58 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-16 10:37 -0700
Re: Reason for segmentation violation luser droog <luser.droog@gmail.com> - 2015-06-15 17:51 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 21:02 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-16 00:51 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-15 22:30 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-17 00:35 -0400
Re: Reason for segmentation violation Rosario19 <Ros@invalid.invalid> - 2015-06-19 18:51 +0200
Re: Reason for segmentation violation luser droog <luser.droog@gmail.com> - 2015-06-15 22:40 -0700
Re: Reason for segmentation violation luser droog <luser.droog@gmail.com> - 2015-06-15 23:23 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-16 11:07 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-16 23:54 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 10:51 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 03:46 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 04:17 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 14:02 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 06:15 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 15:34 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 07:58 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 16:04 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 08:16 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 14:57 +0200
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 15:35 +0100
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 15:44 +0100
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 08:18 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 16:42 +0100
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 08:19 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 16:35 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 08:49 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-17 11:56 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:46 +0200
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 09:14 -0700
Re: Reason for segmentation violation gordonb.446bm@burditt.org (Gordon Burditt) - 2015-06-18 01:56 -0500
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:54 +0200
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 09:08 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-22 16:53 +0200
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 16:32 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-22 18:21 +0200
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-22 16:33 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-22 18:20 +0200
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-22 13:05 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-22 19:47 +0200
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 13:52 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 06:05 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 15:39 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 08:02 -0700
Re: Reason for segmentation violation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 16:12 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 10:46 +0200
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-17 16:12 +0100
Re: Reason for segmentation violation Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:28 -0700
Re: Reason for segmentation violation Ian Collins <ian-news@hotmail.com> - 2015-06-18 07:32 +1200
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 22:02 +0200
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 13:16 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 22:32 +0200
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-23 06:52 +0200
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-17 16:16 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 22:44 +0200
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-17 17:39 -0400
Re: Reason for segmentation violation Robert Wessel <robertwessel2@yahoo.com> - 2015-06-18 01:57 -0500
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:29 +0200
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-17 13:57 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 23:10 +0200
Re: Reason for segmentation violation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-17 14:22 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 23:41 +0200
Re: Reason for segmentation violation Richard Damon <Richard@Damon-Family.org> - 2015-06-18 00:40 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 09:18 +0200
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 08:52 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-17 09:27 -0700
Re: Reason for segmentation violation Keith Thompson <kst-u@mib.org> - 2015-06-17 11:00 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 07:48 -0700
Re: Reason for segmentation violation Bartc <bc@freeuk.com> - 2015-06-14 16:53 +0100
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-14 10:59 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 11:45 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-14 20:01 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 12:40 -0700
Re: Reason for segmentation violation Richard Heathfield <rjh@cpax.org.uk> - 2015-06-14 21:00 +0100
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 13:13 -0700
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 13:17 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-14 16:36 -0400
Re: Reason for segmentation violation "Morten W. Petersen" <morphex@gmail.com> - 2015-06-14 13:43 -0700
Re: Reason for segmentation violation James Kuyper <jameskuyper@verizon.net> - 2015-06-14 14:50 -0400
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-12 03:21 -0700
Re: Reason for segmentation violation Barry Schwarz <schwarzb@dqel.com> - 2015-06-10 23:07 -0700
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-12 13:17 +0100 |
| Message-ID | <mleii1$lci$2@dont-email.me> |
| In reply to | #63210 |
On 12/06/15 12:55, gwowen wrote: > On Friday, June 12, 2015 at 11:08:07 AM UTC+1, Richard Heathfield wrote: >> If you stick to the C90 rules on reserved identifiers, you shouldn't >> find yourself bumping into any new identifiers in later standards, as >> long as you don't include any C99 or C11 headers (stdint.h and so on). > > restrict? Good catch. They should have called it _restrict, for pity's sake. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-12 13:32 +0100 |
| Message-ID | <878ubp6r9z.fsf@bsb.me.uk> |
| In reply to | #63211 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 12/06/15 12:55, gwowen wrote: >> On Friday, June 12, 2015 at 11:08:07 AM UTC+1, Richard Heathfield wrote: >>> If you stick to the C90 rules on reserved identifiers, you shouldn't >>> find yourself bumping into any new identifiers in later standards, as >>> long as you don't include any C99 or C11 headers (stdint.h and so on). >> >> restrict? > > Good catch. They should have called it _restrict, for pity's sake. In C90 (and later for that matter) the name _restrict is reserved only as an external identifier, so that would not have been quite enough for you. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-12 13:20 +0100 |
| Message-ID | <87eglh6rtw.fsf@bsb.me.uk> |
| In reply to | #63210 |
gwowen <gwowen@gmail.com> writes: > On Friday, June 12, 2015 at 11:08:07 AM UTC+1, Richard Heathfield wrote: >> If you stick to the C90 rules on reserved identifiers, you shouldn't >> find yourself bumping into any new identifiers in later standards, as >> long as you don't include any C99 or C11 headers (stdint.h and so on). > > restrict? and inline. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-13 23:55 -0700 |
| Message-ID | <d3987809-b0ba-43d3-ba22-dbe5220dd438@googlegroups.com> |
| In reply to | #63212 |
On Friday, June 12, 2015 at 2:20:52 PM UTC+2, Ben Bacarisse wrote: > gwowen <gwowen@gmail.com> writes: > > > On Friday, June 12, 2015 at 11:08:07 AM UTC+1, Richard Heathfield wrote: > >> If you stick to the C90 rules on reserved identifiers, you shouldn't > >> find yourself bumping into any new identifiers in later standards, as > >> long as you don't include any C99 or C11 headers (stdint.h and so on). > > > > restrict? > > and inline. Both of these seem useful to me, with regards to making the code as fast as possible. Speaking of performance, my impression is that generally, compilers put out better assembler code than most developers. Are there some categories of code that are more suited for "hand-optimization" than others? I guess it's possible to define use of these using the pre-processor, how does one go about to do that? I read here: http://www.greenend.org.uk/rjk/tech/inline.html That inline functions can't "refer to static variables or functions elsewhere in the source file where they are declared." - Is the alternative here to use macros within inline functions? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-14 10:30 +0100 |
| Subject | Restrictions on inline functions (Was: Reason for segmentation violation) |
| Message-ID | <87mw024oxz.fsf_-_@bsb.me.uk> |
| In reply to | #63231 |
"Morten W. Petersen" <morphex@gmail.com> writes: <snip> > I read here: > > http://www.greenend.org.uk/rjk/tech/inline.html > > That inline functions can't "refer to static variables or functions > elsewhere in the source file where they are declared." - Is the > alternative here to use macros within inline functions? I've not read that document but the quote is not correct, though it may simply be out of context. The restriction only applies to definitions of inline functions with external linkage, but it also prohibits the definition of modifiable objects with static storage duration within such a function (and, as of C11, the definition of modifiable objects with thread storage duration): "An inline definition of a function with external linkage shall not contain a definition of a modifiable object with static or thread storage duration, and shall not contain a reference to an identifier with internal linkage." Since this is a constraint, you can expect to be told about it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-12 11:10 -0400 |
| Message-ID | <mlesmu$shm$1@dont-email.me> |
| In reply to | #63208 |
On 06/12/2015 06:07 AM, Richard Heathfield wrote: > On 12/06/15 10:36, Morten W. Petersen wrote: ... >> OK. So then the logical thing to do is to develop based on the features available in the C90, and avoid features that work differently in C99 and C11, both in terms of how they work and if they are removed/deprecated. >> >> Is there a document somewhere which covers developing in this way? > > Not as far as I'm aware (although perhaps there should be), but you can > construct one reasonably easily by starting off with C90 (there are, at > the very least, copies of the draft of that Standard kicking around the > Net), and then crossing out in red pen anything that was removed or > deprecated in later standards. Off the top of my head, that would be: > > * implicit int (removed in C99) > * gets (deprecated in C99 and removed by C11) > > ...and, er, I can't think of anything else (have I missed anything, folks?). The use of ungetc() at the start of a file was deprecated in C99. C99 also specified that a return without expression was not permitted in function that returns a value (and vice versa). -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-06-21 12:46 -0400 |
| Message-ID | <60u7oa939r6f13hc0pgf31q013pcjm6rlj@4ax.com> |
| In reply to | #63214 |
On Fri, 12 Jun 2015 11:10:33 -0400, James Kuyper <jameskuyper@verizon.net> wrote: > On 06/12/2015 06:07 AM, Richard Heathfield wrote: > > On 12/06/15 10:36, Morten W. Petersen wrote: > ... > >> OK. So then the logical thing to do is to develop based on the features available in the C90, and avoid features that work differently in C99 and C11, both in terms of how they work and if they are removed/deprecated. > >> > >> Is there a document somewhere which covers developing in this way? > > > > Not as far as I'm aware (although perhaps there should be), but you can > > construct one reasonably easily by starting off with C90 (there are, at > > the very least, copies of the draft of that Standard kicking around the > > Net), and then crossing out in red pen anything that was removed or > > deprecated in later standards. Off the top of my head, that would be: > > > > * implicit int (removed in C99) Also 'implicit function': ident(expr_list_opt) if ident undeclared acted as if declared int ident (/*oldstyle-no-prototype*/) . > > * gets (deprecated in C99 and removed by C11) > > > > ...and, er, I can't think of anything else (have I missed anything, folks?). > > The use of ungetc() at the start of a file was deprecated in C99. > > C99 also specified that a return without expression was not permitted in > function that returns a value (and vice versa). C89/90 prohibited return expr in void function(...) .... *New* in C99 was to prohibit return /*nothing*/ in nonvoid. Note you can still fall off the end of nonvoid in which case it causes UB if "the value ... is used by the caller".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-12 08:35 -0700 |
| Message-ID | <87mw05gcs4.fsf@kst-u.example.com> |
| In reply to | #63208 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 12/06/15 10:36, Morten W. Petersen wrote:
[...]
>> OK. So then the logical thing to do is to develop based on the
>> features available in the C90, and avoid features that work
>> differently in C99 and C11, both in terms of how they work and if
>> they are removed/deprecated.
>>
>> Is there a document somewhere which covers developing in this way?
>
> Not as far as I'm aware (although perhaps there should be), but you
> can construct one reasonably easily by starting off with C90 (there
> are, at the very least, copies of the draft of that Standard kicking
> around the Net), and then crossing out in red pen anything that was
> removed or deprecated in later standards. Off the top of my head, that
> would be:
>
> * implicit int (removed in C99)
> * gets (deprecated in C99 and removed by C11)
>
> ...and, er, I can't think of anything else (have I missed anything, folks?).
I would also avoid old-style (non-prototype) function declarations and
definitions. They're officially "obsolescent" in C90, C99, and C11, but
they've never been removed from the language. Nevertheless, they should
be avoided.
[...]
--
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 Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-12 12:21 -0400 |
| Message-ID | <mlf0sg$e17$1@dont-email.me> |
| In reply to | #63216 |
On 06/12/2015 11:35 AM, Keith Thompson wrote: ... > I would also avoid old-style (non-prototype) function declarations and > definitions. They're officially "obsolescent" in C90, C99, and C11, but > they've never been removed from the language. Nevertheless, they should > be avoided. Still, there are problems with prototype functions. Try declaring a function that takes as an argument a pointer to a function of the same type. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-12 10:48 -0700 |
| Message-ID | <87a8w4hl7m.fsf@kst-u.example.com> |
| In reply to | #63221 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 06/12/2015 11:35 AM, Keith Thompson wrote:
> ...
>> I would also avoid old-style (non-prototype) function declarations and
>> definitions. They're officially "obsolescent" in C90, C99, and C11, but
>> they've never been removed from the language. Nevertheless, they should
>> be avoided.
>
> Still, there are problems with prototype functions. Try declaring a
> function that takes as an argument a pointer to a function of the same type.
Interesting example. I've never had a need to do that myself (which is
not to imply that it's not useful.)
Since all function pointer types are convertible, there is a workaround:
typedef void (func)(void);
void foo(func *param) {
}
int main(void) {
foo((func*)foo);
}
Here "func" is a generic function type. The need for the cast is
unfortunate, and there's no compile-time checking against passing a
pointer to a function of a different type.
On the other hand, how would you do that with old-style declarations?
(I'm slightly too lazy to work it out myself.)
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-12 19:12 +0100 |
| Message-ID | <87ioas6biy.fsf@bsb.me.uk> |
| In reply to | #63222 |
Keith Thompson <kst-u@mib.org> writes:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 06/12/2015 11:35 AM, Keith Thompson wrote:
>> ...
>>> I would also avoid old-style (non-prototype) function declarations and
>>> definitions. They're officially "obsolescent" in C90, C99, and C11, but
>>> they've never been removed from the language. Nevertheless, they should
>>> be avoided.
>>
>> Still, there are problems with prototype functions. Try declaring a
>> function that takes as an argument a pointer to a function of the same type.
>
> Interesting example. I've never had a need to do that myself (which is
> not to imply that it's not useful.)
>
> Since all function pointer types are convertible, there is a workaround:
>
> typedef void (func)(void);
>
> void foo(func *param) {
> }
>
> int main(void) {
> foo((func*)foo);
> }
>
> Here "func" is a generic function type. The need for the cast is
> unfortunate, and there's no compile-time checking against passing a
> pointer to a function of a different type.
>
> On the other hand, how would you do that with old-style declarations?
> (I'm slightly too lazy to work it out myself.)
The problem is side-stepped because there is no need to write the type
of the parameters when writing the type of the parameter (!) To take a
rather trite example:
int f(g, n)
int (*g)();
int n;
{
return n ? n * g(f, n - 1) : 1;
}
f(f, 10) /* may return 3628800 if int is big enough */
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-06-12 08:49 -0700 |
| Message-ID | <79394a6c-fcf7-4f28-a8f5-22be18003741@googlegroups.com> |
| In reply to | #63208 |
On Friday, June 12, 2015 at 3:08:07 AM UTC-7, Richard Heathfield wrote:
> On 12/06/15 10:36, Morten W. Petersen wrote:
> > On Friday, June 12, 2015 at 9:33:53 AM UTC+2, Richard Heathfield wrote:
> >
> >> > Well, this brings up another interesting point. I'd like to keep
> >> > things as simple and portable as possible. What version of C is
> >> > it a good idea to aim for, what version of C has features that it
> >> > would be self-defeating not to make use of?
> >>
> >> Well, around here them's fitin' woids, and you'll get a hundred
> >> different answers, all of them wrong except mine. :-)
> >>
> >> The simplest, portablest(tm) "version" of C is the common subset of C90,
> >> C99, and C11. That's what I use. The features it has that it would be
> >> self-defeating not to make use of are "it works everywhere" and "it
> >> breaks nowhere".
> >
> > :)
> >
> > OK. So then the logical thing to do is to develop based on the features available in the C90, and avoid features that work differently in C99 and C11, both in terms of how they work and if they are removed/deprecated.
> >
> > Is there a document somewhere which covers developing in this way?
>
> Not as far as I'm aware (although perhaps there should be), but you can
> construct one reasonably easily by starting off with C90 (there are, at
> the very least, copies of the draft of that Standard kicking around the
> Net), and then crossing out in red pen anything that was removed or
> deprecated in later standards. Off the top of my head, that would be:
>
> * implicit int (removed in C99)
> * gets (deprecated in C99 and removed by C11)
>
> ...and, er, I can't think of anything else (have I missed anything, folks?).
>
> Those removals are not particularly onerous, since nobody in their right
> mind uses gets(), and implicit int was only a historical oddity.
>
> If you stick to the C90 rules on reserved identifiers, you shouldn't
> find yourself bumping into any new identifiers in later standards, as
> long as you don't include any C99 or C11 headers (stdint.h and so on).
The C90 standard also allows for the old way of function definition
int foo(a) int a; {...}
which I assume disappears in later standards.
I observe that all the rest of the comments seem not to answer the
question but rather to name things that were added later.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-12 09:13 -0700 |
| Message-ID | <87eglghpm3.fsf@kst-u.example.com> |
| In reply to | #63217 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> The C90 standard also allows for the old way of function definition
> int foo(a) int a; {...}
> which I assume disappears in later standards.
No, old-style function definitions and declaration are still
fully supported (but "obsolescent") in the C99 and C11 standards.
I personally hope that they're finally removed from the next standard
(compilers would still be able to support them in a non-conforming
mode to cater to old code), but I'm not holding my breath.
We frequently discuss the more current editions of the C standard here.
It might be worth your while to download the drafts so you can refer to
them.
[...]
--
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 Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-06-13 08:55 -0700 |
| Message-ID | <5ee3412e-a983-4e99-821a-a4433ebb4c42@googlegroups.com> |
| In reply to | #63220 |
On Friday, June 12, 2015 at 9:13:19 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > The C90 standard also allows for the old way of function definition
> > int foo(a) int a; {...}
> > which I assume disappears in later standards.
>
> No, old-style function definitions and declaration are still
> fully supported (but "obsolescent") in the C99 and C11 standards.
> I personally hope that they're finally removed from the next standard
> (compilers would still be able to support them in a non-conforming
> mode to cater to old code), but I'm not holding my breath.
>
> We frequently discuss the more current editions of the C standard here.
> It might be worth your while to download the drafts so you can refer to
> them.
Good advice but I beat you to it. I was just too lazy to check. In fact,
I have a hard time believing it - but this time I did check and it's so.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-12 08:56 -0700 |
| Message-ID | <87ioashqdb.fsf@kst-u.example.com> |
| In reply to | #63205 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 12/06/15 07:42, Morten W. Petersen wrote:
>> On Friday, June 12, 2015 at 4:58:56 AM UTC+2, Barry Schwarz wrote:
>>
>>> >So, for example having a function which returns long, you're
>>> saying that I don't need to cast an integer (presumably) to long?
>>> This will just automagically work?
>>>
>>> Download a copy of the draft C standard (my copy is called n1570) and
>>> read up on "Conversions".
>>
>> Well, this brings up another interesting point. I'd like to keep
>> things as simple and portable as possible. What version of C is
>> it a good idea to aim for, what version of C has features that it
>> would be self-defeating not to make use of?
>
> Well, around here them's fitin' woids, and you'll get a hundred
> different answers, all of them wrong except mine. :-)
>
> The simplest, portablest(tm) "version" of C is the common subset of
> C90, C99, and C11. That's what I use. The features it has that it
> would be self-defeating not to make use of are "it works everywhere"
> and "it breaks nowhere".
[...]
That's certainly a valid approach, but it's not the only one.
I think you said you're using gcc. gcc has good (but probably not
100% complete) support for C99, and some support for C11. Each of
the newer standards includes a foreword that lists the features that
were added relative to the previous standard. If you find those
features useful, you *probably* won't have any problems using them.
As Richard correctly points out, using C99- or C11-specific features
will limit the portability of your code. In practice, the biggest
issue is likelyi to be Microsoft's compiler, which has good support
for C90 but very poor support for C99. Some compilers for embedded
systems might also have poor support for later standards.
You'll have to decide, based on your own requirements, whether the
convenience of any newer features is worth the loss of portability.
Drafts of the C99 and C11 standards are available at no cost.
C99: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
C11: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-06-12 09:41 +0000 |
| Message-ID | <mle9gd$dlt$1@speranza.aioe.org> |
| In reply to | #63204 |
Morten W. Petersen <morphex@gmail.com> wrote: (snip) > When it comes to realloc, looking at that function one can tell > that realloc will keep the memory segment at the same size or > reduce it. > What are the chances that such a call to realloc will fail? If I tell you, will you program differently? If it is 1% or 10%? As far as I know, most unix-like systems have the ability to reduce the size of an allocated block. C tries to be general enough, and it might be that some systems have to allocate new space and copy the data, even to reduce the size, and it could fail on those systems. Do you know that your program will never run on one of those? -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-12 08:29 -0700 |
| Message-ID | <87r3phgd30.fsf@kst-u.example.com> |
| In reply to | #63207 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Morten W. Petersen <morphex@gmail.com> wrote:
> (snip)
>> When it comes to realloc, looking at that function one can tell
>> that realloc will keep the memory segment at the same size or
>> reduce it.
>> What are the chances that such a call to realloc will fail?
>
> If I tell you, will you program differently?
>
> If it is 1% or 10%?
>
> As far as I know, most unix-like systems have the ability to reduce
> the size of an allocated block.
>
> C tries to be general enough, and it might be that some systems
> have to allocate new space and copy the data, even to reduce the
> size, and it could fail on those systems. Do you know that your
> program will never run on one of those?
Or an implementation of realloc() might want to store the new smaller
block at a different location because it makes its internal bookkeeping
easier, and if there isn't enough room to do that it might fail rather
than keeping the original location. (For example, it might maintain one
chunk of memory for large blocks and another for small blocks.)
I have no idea whether any actual implementations do this.
--
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 | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-14 00:03 -0700 |
| Message-ID | <21609ea1-1881-42fa-8e7e-a00870a541e1@googlegroups.com> |
| In reply to | #63215 |
On Friday, June 12, 2015 at 5:29:19 PM UTC+2, Keith Thompson wrote: > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > > Morten W. Petersen <morphex@gmail.com> wrote: > > (snip) > >> When it comes to realloc, looking at that function one can tell > >> that realloc will keep the memory segment at the same size or > >> reduce it. > >> What are the chances that such a call to realloc will fail? > > > > If I tell you, will you program differently? > > > > If it is 1% or 10%? > > > > As far as I know, most unix-like systems have the ability to reduce > > the size of an allocated block. > > > > C tries to be general enough, and it might be that some systems > > have to allocate new space and copy the data, even to reduce the > > size, and it could fail on those systems. Do you know that your > > program will never run on one of those? > > Or an implementation of realloc() might want to store the new smaller > block at a different location because it makes its internal bookkeeping > easier, and if there isn't enough room to do that it might fail rather > than keeping the original location. (For example, it might maintain one > chunk of memory for large blocks and another for small blocks.) > > I have no idea whether any actual implementations do this. It seems stupid or contrived that realloc should fail for whatever reason, if the size of the memory segment is smaller than it was. But, I guess it is the right thing to do, to account for these kinds of examples as well. Would it be OK to check whether the pointer is NULL and exit with a non-zero value, or is it better to use for example assert? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2015-06-14 00:58 -0700 |
| Message-ID | <vccqnahodu5d57bl5qq2v4m6kooc1q0o9l@4ax.com> |
| In reply to | #63232 |
On Sun, 14 Jun 2015 00:03:01 -0700 (PDT), "Morten W. Petersen" <morphex@gmail.com> wrote: >On Friday, June 12, 2015 at 5:29:19 PM UTC+2, Keith Thompson wrote: >> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >> > Morten W. Petersen <morphex@gmail.com> wrote: >> > (snip) >> >> When it comes to realloc, looking at that function one can tell >> >> that realloc will keep the memory segment at the same size or >> >> reduce it. >> >> What are the chances that such a call to realloc will fail? >> > >> > If I tell you, will you program differently? >> > >> > If it is 1% or 10%? >> > >> > As far as I know, most unix-like systems have the ability to reduce >> > the size of an allocated block. >> > >> > C tries to be general enough, and it might be that some systems >> > have to allocate new space and copy the data, even to reduce the >> > size, and it could fail on those systems. Do you know that your >> > program will never run on one of those? >> >> Or an implementation of realloc() might want to store the new smaller >> block at a different location because it makes its internal bookkeeping >> easier, and if there isn't enough room to do that it might fail rather >> than keeping the original location. (For example, it might maintain one >> chunk of memory for large blocks and another for small blocks.) >> >> I have no idea whether any actual implementations do this. > >It seems stupid or contrived that realloc should fail for whatever reason, if the size of the memory segment is smaller than it was. > >But, I guess it is the right thing to do, to account for these kinds of examples as well. > >Would it be OK to check whether the pointer is NULL and exit with a non-zero value, or is it better to use for example assert? One programmer's opinion: assert should be used for development testing. It should not be used in production code. Any function which can detect a failure condition should notify the calling function of that failure. The calling function should determine the severity of the error and the proper response (which may be to pass the error on up to the next higher level function). Utility functions should not terminate an application on their own. Even messages to stderr should be rare. Let the caller deal with the error. The application should decide how to deal with the error. Possible responses include asking the user to choose an option, executing an alternate code path, and termination. If the latter is the choice, the program should clean up after itself (close files, release allocated memory, etc) and inform the user of what is happening and why before exiting. -- Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-14 02:14 -0700 |
| Message-ID | <f9e5e5d8-f1e4-4d3a-962b-fd0b7a7aefab@googlegroups.com> |
| In reply to | #63233 |
On Sunday, June 14, 2015 at 9:58:16 AM UTC+2, Barry Schwarz wrote: > On Sun, 14 Jun 2015 00:03:01 -0700 (PDT), "Morten W. Petersen" > <morphex@gmail.com> wrote: > One programmer's opinion: > > assert should be used for development testing. It should not be used > in production code. Any function which can detect a failure condition > should notify the calling function of that failure. The calling > function should determine the severity of the error and the proper > response (which may be to pass the error on up to the next higher > level function). > > Utility functions should not terminate an application on their own. > Even messages to stderr should be rare. Let the caller deal with the > error. The application should decide how to deal with the error. > Possible responses include asking the user to choose an option, > executing an alternate code path, and termination. If the latter is > the choice, the program should clean up after itself (close files, > release allocated memory, etc) and inform the user of what is > happening and why before exiting. Yes, this makes sense, that calls to a function shouldn't terminate the caller. It is conceivable that a user tries to import a huge XML file, which could ultimately lead to memory issues. Failures to (re)allocate memory is a fatal error, which means that it isn't any use trying to figure things out. Therefore, I'm thinking that a setting a flag somewhere & a message + a goto that jumps directly to the upmost local calling function, for example parse_xml_file could be the right thing to do, because there is no point trying to fix anything. The internal storage structure should be something like a set of linked lists, which means that by using a couple of variables it should be possible to free most (all?) memory allocated using malloc. The only remaining issue then is how the stack etc. looks. ..but now I googled a bit and found that goto was only local and setjmp and longjmp were the things I was looking for. What I'm trying to achieve here is a lazy and simple approach to handling fatal errors like memory errors. -Morten
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web