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 1 of 10 [1] 2 3 … 10 Next page →
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-10 22:32 -0700 |
| Subject | Reason for segmentation violation |
| Message-ID | <869bae8d-e318-4e1c-865b-3c5890304279@googlegroups.com> |
Hi there. I'm a seasoned Python programmer and web developer, that's currently dabbling with C and assembler mostly for fun. I've been working on an XML parser, and have gotten to the point where I have to dynamically allocate memory to store data.. I don't have much experience with pointers, memory management and so on, so if there are any good documents describing how to dynamically allocate memory in functions I'd like (...) pointers to those. The code in question is here: https://github.com/morphex/smash_xml/blob/master/decode_xml.c It fails on line 406, and why it fails I have no idea. Regards, Morten
[toc] | [next] | [standalone]
| From | Xavier Roche <xroche@free.fr.NOSPAM.invalid> |
|---|---|
| Date | 2015-06-11 07:52 +0200 |
| Message-ID | <mlb7n0$3pp$1@news.httrack.net> |
| In reply to | #63176 |
Le 11/06/2015 07:32, Morten W. Petersen a écrit :
> It fails on line 406, and why it fails I have no idea.
unsigned long* attribute = NULL;
"attribute" is NULL here
long size = run_attribute_name(buffer, 7*4, attribute);
you pass the NULL pointer to run_attribute_name (ie. the "attribute" value is COPIED as argument to run_attribute_name()
long index = *(attribute);
"attribute" is still NULL here, and dereferencing it will probably cause unforeseen consequences
In C, everything is passed by value in functions, not by reference (C++ has &) - passed arguments are only local variables. If you want "attribute" to be changed, you have to change the (dereferenced) lvalue, ie. use a ... pointer. (Not sure if I am totally clear)
Therefore, rather than using:
inline long run_attribute_name(char* buffer, unsigned long position, unsigned long *attribute)
use:
inline long run_attribute_name(char* buffer, unsigned long position, unsigned long **attribute)
and
*attribute = malloc(sizeof(char)*MAXIMUM_NAME_SIZE_BYTES);
...
long size = run_attribute_name(buffer, 7*4, &attribute);
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-11 07:19 -0700 |
| Message-ID | <b5ef8bf1-2e74-4d78-b69e-2ccd12f7eccd@googlegroups.com> |
| In reply to | #63177 |
Hi Xavier, OK. I understand the concept of pointers but I guess it takes time to get used to handling pointers, pointers to pointers etc. and its semantics in C. I uploaded a new version of decode_xml.c here https://github.com/morphex/smash_xml/blob/b75d7e46164a306542be62c78c52627e18884a26/decode_xml.c If I run the program, the code on line 411 prints the correct first character, and after that it's just garbage. Which tells me that things are almost correct. Looking at line 328, the correct values are displayed, except for the last statement, attribute[index], which is the same garbage as above. So it looks like that the pointer is correct, but there is something wrong with how the unicode character at position 1 and following are added. Also, calling free on line 413 results in a segmentation violation, same with the realloc on line 336. Regards, Morten On Thursday, June 11, 2015 at 7:52:43 AM UTC+2, Xavier Roche wrote: > Le 11/06/2015 07:32, Morten W. Petersen a écrit : > > It fails on line 406, and why it fails I have no idea. > > unsigned long* attribute = NULL; > > "attribute" is NULL here > > long size = run_attribute_name(buffer, 7*4, attribute); > > you pass the NULL pointer to run_attribute_name (ie. the "attribute" value is COPIED as argument to run_attribute_name() > > long index = *(attribute); > > "attribute" is still NULL here, and dereferencing it will probably cause unforeseen consequences > > In C, everything is passed by value in functions, not by reference (C++ has &) - passed arguments are only local variables. If you want "attribute" to be changed, you have to change the (dereferenced) lvalue, ie. use a ... pointer. (Not sure if I am totally clear) > > Therefore, rather than using: > > inline long run_attribute_name(char* buffer, unsigned long position, unsigned long *attribute) > > use: > inline long run_attribute_name(char* buffer, unsigned long position, unsigned long **attribute) > > and > > *attribute = malloc(sizeof(char)*MAXIMUM_NAME_SIZE_BYTES); > ... > > long size = run_attribute_name(buffer, 7*4, &attribute);
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-11 15:46 +0100 |
| Message-ID | <mlc6to$q8p$1@dont-email.me> |
| In reply to | #63186 |
On 11/06/15 15:19, Morten W. Petersen wrote:
> Hi Xavier,
>
> OK. I understand the concept of pointers but I guess it takes time to get used to handling pointers, pointers to pointers etc. and its semantics in C.
>
> I uploaded a new version of decode_xml.c here
>
> https://github.com/morphex/smash_xml/blob/b75d7e46164a306542be62c78c52627e18884a26/decode_xml.c
Think about types.
Line 411 looks like this:
printf("%c %lx\n", &attribute[index], &attribute[index]);
%c is the printf conversion specifier for a single character (actually
an int, oddly enough, but the idea is to print a text character), so the
matching argument should be a char (or an int).
&attribute[index] is, however, neither a char nor an int.
attribute has type long * (i.e. a pointer to a long). attribute[index]
is shorthand for *(attribute + index). Pointer arithmetic is type-aware,
so (attribute + index) means "pointer to the indexth long after
attribute" - i.e. attribute + 0 is the same as attribute, attribute+1 is
one long along the row, so to speak, and attribute+2 is two longs along
the row, and so on.
&attribute[index] is the address of the long int at that position in
memory, and has type long *. It's a pointer, whereas what you need is a
character. Even if you (correctly) remove the & (and it shows every sign
of being a knee-jerk addition after learning about pass-by-value), you
will still have a long int, not a character.
Having fixed that problem, you will need to remove the & from the second
&attribute[index] as well, to give printf a decent crack at printing
your long int for you.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2015-06-11 11:23 -0700 |
| Message-ID | <aehjna51mdp2kdvi22q5em5k979m5gr0j1@4ax.com> |
| In reply to | #63186 |
On Thu, 11 Jun 2015 07:19:27 -0700 (PDT), "Morten W. Petersen"
<morphex@gmail.com> wrote:
>OK. I understand the concept of pointers but I guess it takes time to get used to handling pointers, pointers to pointers etc. and its semantics in C.
>
>I uploaded a new version of decode_xml.c here
>
>https://github.com/morphex/smash_xml/blob/b75d7e46164a306542be62c78c52627e18884a26/decode_xml.c
In addition to the problems others have pointed out:
For some reason, you seem to be infatuated with casts. Most are
useless (e.g., lines 60 & 309). Others have a potentially detrimental
impact on performance (e.g., lines 264-277). At the very least, they
are misleading to the reader. You are also inconsistent in the use of
these casts (e.g., lines 307/311/322/333/ but 337).
You have numerous mismatches in your calls to printf between the
conversion specification and the corresponding argument. Some are
possibly harmless mismatches in sign (e.g., lines 70 & 94). Others
are major type mismatches that lead to undefined behavior (e.g., lines
211, 328, & 405)
In lines 343-345, why is buffer dynamically allocated? Will an
array of 1024 char overflow your available storage?
Line 349 stores your sentinel one byte too far into buffer.
Furthermore, if your file contains 1023 bytes or more, this will cause
undefined behavior.
You free buffer in line 423. Why do you not free attribute?
In run_attribute_name, you changed the type of attribute to
unsigned long ** and made some of the necessary corresponding changes
where the parameter is used. You missed several (lines 310, 321, 326,
328, & 332)
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-11 12:08 -0700 |
| Message-ID | <f4c57e09-7ff9-46ad-85ba-e032442a9192@googlegroups.com> |
| In reply to | #63192 |
Hi there Barry. On Thursday, June 11, 2015 at 8:23:32 PM UTC+2, Barry Schwarz wrote: > On Thu, 11 Jun 2015 07:19:27 -0700 (PDT), "Morten W. Petersen" > <morphex@gmail.com> wrote: > > >OK. I understand the concept of pointers but I guess it takes time to get used to handling pointers, pointers to pointers etc. and its semantics in C. > > > >I uploaded a new version of decode_xml.c here > > > >https://github.com/morphex/smash_xml/blob/b75d7e46164a306542be62c78c52627e18884a26/decode_xml.c > > In addition to the problems others have pointed out: > > For some reason, you seem to be infatuated with casts. Most are > useless (e.g., lines 60 & 309). Others have a potentially detrimental > impact on performance (e.g., lines 264-277). At the very least, they > are misleading to the reader. You are also inconsistent in the use of > these casts (e.g., lines 307/311/322/333/ but 337). OK. Well, I'm learning about these casts, and to me it seems that to be explicit is better than implicit. I'd like this to run well on any platform. 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? > You have numerous mismatches in your calls to printf between the > conversion specification and the corresponding argument. Some are > possibly harmless mismatches in sign (e.g., lines 70 & 94). Others > are major type mismatches that lead to undefined behavior (e.g., lines > 211, 328, & 405) Yep. These printf statements are just a quick and dirty way to see what's going on. > In lines 343-345, why is buffer dynamically allocated? Will an > array of 1024 char overflow your available storage? This is the first "serious" C program I'm doing, and I added that line to get a bit more familiar with malloc. > Line 349 stores your sentinel one byte too far into buffer. > Furthermore, if your file contains 1023 bytes or more, this will cause > undefined behavior. Ah yes, right you are. > You free buffer in line 423. Why do you not free attribute? I think things are OK now, see the new code here: https://github.com/morphex/smash_xml/blob/9bb574365a1307ecf196d4eb64de76f207563158/decode_xml.c > In run_attribute_name, you changed the type of attribute to > unsigned long ** and made some of the necessary corresponding changes > where the parameter is used. You missed several (lines 310, 321, 326, > 328, & 332) Yep. I googled for some solutions and found that I could work on a "local" dynamic character buffer, and then towards the end update the pointer to a pointer to point towards this place. I assume that free works based on memory address, which should be the same for attribute_storage and attribute? Regards, Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-11 15:44 -0400 |
| Message-ID | <5579E504.5090404@verizon.net> |
| In reply to | #63194 |
On 06/11/2015 03:08 PM, Morten W. Petersen wrote: > Hi there Barry. > > On Thursday, June 11, 2015 at 8:23:32 PM UTC+2, Barry Schwarz wrote: >> On Thu, 11 Jun 2015 07:19:27 -0700 (PDT), "Morten W. Petersen" >> <morphex@gmail.com> wrote: >> >>> OK. I understand the concept of pointers but I guess it takes time to get used to handling pointers, pointers to pointers etc. and its semantics in C. >>> >>> I uploaded a new version of decode_xml.c here >>> >>> https://github.com/morphex/smash_xml/blob/b75d7e46164a306542be62c78c52627e18884a26/decode_xml.c >> >> In addition to the problems others have pointed out: >> >> For some reason, you seem to be infatuated with casts. Most are >> useless (e.g., lines 60 & 309). Others have a potentially detrimental >> impact on performance (e.g., lines 264-277). At the very least, they >> are misleading to the reader. You are also inconsistent in the use of >> these casts (e.g., lines 307/311/322/333/ but 337). > > OK. Well, I'm learning about these casts, and to me it seems that to be explicit is better than implicit. I'd like this to run well on any platform. That's the problem. Implicit conversions are implicit precisely because they are generally safe. Conversions that can only be done explicitly are generally more dangerous. When you explicit request a conversion, the compiler must assume that you understand what the risks are, and accept responsibility for making sure that they are properly dealt with. As a result, by using a cast, you're disabling lots of important warning messages that you might otherwise get. As a general rule, if a conversion will occur implicitly, you should let it do so. You should insert a cast only when necessary, and you should think carefully about what the cast will do before inserting it. Whenever you find a cast in code you are reading, you should consider it a danger point, and if you have any responsibility for the quality of that code, you should carefully consider what that cast will do, and give the people responsible for it a suitable warning if you think it was incorrect. Because casts can be danger points, they deserve special attention. I you over-use them, then it's hard to give them the special attention that they deserve. Therefore, avoid using them except when they're actually necessary. > 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? If you have a function that returns a long, and you save that return value in an int, it will be implicitly converted. However, there's a possibility that the value is too large to be stored in an int. If you let the conversion occur implicitly, the compiler will often warn you about that possibility. If you use a cast, the compiler will generally not warn you about it - which is why it's a bad idea to use a cast. >> You have numerous mismatches in your calls to printf between the >> conversion specification and the corresponding argument. Some are >> possibly harmless mismatches in sign (e.g., lines 70 & 94). Others >> are major type mismatches that lead to undefined behavior (e.g., lines >> 211, 328, & 405) > > Yep. These printf statements are just a quick and dirty way to see what's going on. Well, they're so quick and dirty that they might not even work - they could cause your program to abort - or worse, print the wrong value with no indication of the fact that it is the wrong value. Is that acceptable? If not, I'd recommend writing code that is a little slower and cleaner.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-11 12:55 -0700 |
| Message-ID | <18f33ef3-65da-4c28-ba45-a99456326509@googlegroups.com> |
| In reply to | #63195 |
> > Yep. These printf statements are just a quick and dirty way to see what's going on. > > Well, they're so quick and dirty that they might not even work - they > could cause your program to abort - or worse, print the wrong value with > no indication of the fact that it is the wrong value. Is that > acceptable? If not, I'd recommend writing code that is a little slower > and cleaner. Yep, I should probably learn more about printf and formatting. These printf statements were intended to give debug information, and removed after that. But I guess it's useful to leave some of these printf statements as statements that are run in a debug mode. As for casting things, I'm working on 32-bit Unicode symbols, and I guess the simplest architecture this code will run on, is 32 bits. Therefore I'm using the unsigned long statement in different places. It looks like this is something I should keep doing, and instead rely more on the compiler for implicit casts in other places. -Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-11 16:29 -0400 |
| Message-ID | <5579EFB0.2020605@verizon.net> |
| In reply to | #63196 |
On 06/11/2015 03:55 PM, Morten W. Petersen wrote: >>> Yep. These printf statements are just a quick and dirty way to see what's going on. >> >> Well, they're so quick and dirty that they might not even work - they >> could cause your program to abort - or worse, print the wrong value with >> no indication of the fact that it is the wrong value. Is that >> acceptable? If not, I'd recommend writing code that is a little slower >> and cleaner. > > Yep, I should probably learn more about printf and formatting. These printf statements were intended to give debug information, and removed after that. Key points: 1. You want those statements to give you debugging information. Therefore, I presume it is unacceptable for them to fail to give you that information, by reason of the function call aborting your program? 2. You want to use that debugging information for some purpose. Therefore, I presume it's unacceptable for the statements to print out misleadingly incorrect information? The concepts of "quick and dirty" and "debug mode" can be used to justify inefficient ways of doing the right thing, and they can be used to justify getting information that is only an approximation to the right information - as long as you're well aware that it is only an approximation. What you're doing here doesn't fall into either category. Those concepts cannot be used to justify doing things in ways that are just plain wrong, which is the case when there's a mis-match between the format specifier and the corresponding argument to printf().
[toc] | [prev] | [next] | [standalone]
| From | gordonb.h0fbo@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2015-06-17 23:51 -0500 |
| Message-ID | <us-dnYqA7vnT0x_InZ2dnUU7-N2dnZ2d@posted.internetamerica> |
| In reply to | #63196 |
> As for casting things, I'm working on 32-bit Unicode symbols, and Unicode actually needs only an unsigned 21-bit integer and doesn't even use the full range of that (0 - 0x10ffff). 32 bits is convenient on many processors but not required. > I guess the simplest architecture this code will run on, is 32 bits. *ALL* C implementations should have the unsigned long type, and on all of them it should be a minimum of 32 bits. Yes, it should even work on the infamous Atmel 8-bit AVR processors. The low end of that line doesn't have a 16-bit add instruction nor any multiply instruction. Multi-precision arithmetic permits 32-bit integer arithmetic. It will be slow, but then any 16MHz processor or below will be slow. The implementation does a reasonable approximation of 32-bit IEEE floating point, although perhaps not all the corner cases. These processors do tend to be very short on RAM, though. > Therefore I'm using the unsigned long statement in different places. > It looks like this is something I should keep doing, and instead > rely more on the compiler for implicit casts in other places. You might consider whether or not the wide-character support built in to the implementation is guaranteed to be Unicode or not. C does not make such a guarantee. If you must have Unicode and not all platforms guarantee it, you might write your Unicode support independently of the wide-character support, and don't use the wide-character support. It's possible all you need is internal Unicode converted to and from UTF-8 for I/O.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-17 23:10 -0700 |
| Message-ID | <2aa3702a-88f6-4f95-a39d-4eff26d2c72c@googlegroups.com> |
| In reply to | #63474 |
On Thursday, June 18, 2015 at 5:51:35 AM UTC+1, Gordon Burditt wrote: > > You might consider whether or not the wide-character support built > in to the implementation is guaranteed to be Unicode or not. C > does not make such a guarantee. If you must have Unicode and > not all platforms guarantee it, you might write your Unicode support > independently of the wide-character support, and don't use the > wide-character support. It's possible all you need is internal > Unicode converted to and from UTF-8 for I/O. > UTF-8 really comes into its own for internal string handling by C programs. English language ASCII strings are also UTF-8 strings, so you can mix and match ascii functions and unicode. For example, if you're parsing an IFF file, it's likely that the tags will be returned to you as 8 bit ascii strings from the general purpose loader. So you can just pass them through to the UFT-8 string handling routines for output, say on a dynamic webpage, without messing about with little conversion routines. Then, mostly, C functions don't care what a string means, and where they do care, what they care about is the embedded numbers. So most of the code works transparently in UTF-8.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.0vo9r@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2015-06-18 03:30 -0500 |
| Message-ID | <QJWdnQ2QlJEuHB_InZ2dnUU7-eWdnZ2d@posted.internetamerica> |
| In reply to | #63478 |
>> You might consider whether or not the wide-character support built >> in to the implementation is guaranteed to be Unicode or not. C >> does not make such a guarantee. If you must have Unicode and >> not all platforms guarantee it, you might write your Unicode support >> independently of the wide-character support, and don't use the >> wide-character support. It's possible all you need is internal >> Unicode converted to and from UTF-8 for I/O. >> > UTF-8 really comes into its own for internal string handling by C > programs. English language ASCII strings are also UTF-8 strings, > so you can mix and match ascii functions and unicode. For example, The context of this was a *PARSER* (for XML). A parser needs to recognize typically at least certain punctuation as special ( < and >, for example), and some of those might be Unicode characters, for example, allowing Microsoft 'smart quotes' as another way of quoting a text string. How many "white space" characters are there in Unicode? I think at least U+A0 (non-breaking space) counts. I think there's about 15 more. Also, something like backslash quotes the next character, not the next byte. A parser would seem to involve a lot of getting the Unicode code point and looking up the properties of that code point. > if you're parsing an IFF file, it's likely that the tags will be Is that some kind of audio file tagging format? If what you are parsing isn't really Unicode (it's a binary tag structure containing some fields with Unicode in them) except for the strings, yes, you can often interpret the strings as bytes you can ship out on a web page or to stdout. If your output charset is UTF-8, (and I try to set up xterms that way, with lots and lots of fonts) you can ship it unconverted. But if you have to hunt through the strings to get at the structure of the data, things can be very different. > returned to you as 8 bit ascii strings from the general purpose > loader. So you can just pass them through to the UFT-8 string > handling routines for output, say on a dynamic webpage, without > messing about with little conversion routines. > Then, mostly, C functions don't care what a string means, and where > they do care, what they care about is the embedded numbers. So > most of the code works transparently in UTF-8. Consider what happens if you have to interpret all Unicode characters with general category 'Nd' (decimal number) as parts of a number. As of Unicode 6.3, I think there are 460 of them, probably more by now. I'm not sure how you tell the difference between a left-to-right decimal number and a right-to-left decimal number. It may also have to deal with an identifier, which is an alphabetic character followed by zero or more alphanumeric characters. There are 15248 characters in Unicode 6.3 that seem to qualify as 'letters', including over a thousand Egyption hieroglyphs.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-06-18 02:40 -0700 |
| Message-ID | <a78d06ac-521c-430e-861e-081736a21cde@googlegroups.com> |
| In reply to | #63493 |
On Thursday, June 18, 2015 at 9:30:51 AM UTC+1, Gordon Burditt wrote: > > > UTF-8 really comes into its own for internal string handling by C > > programs. English language ASCII strings are also UTF-8 strings, > > so you can mix and match ascii functions and unicode. For example, > > The context of this was a *PARSER* (for XML). A parser needs to > recognize typically at least certain punctuation as special ( < and > >, for example), and some of those might be Unicode characters, for > example, allowing Microsoft 'smart quotes' as another way of quoting > a text string. How many "white space" characters are there in > Unicode? I think at least U+A0 (non-breaking space) counts. I > think there's about 15 more. Also, something like backslash quotes > the next character, not the next byte. A parser would seem to > involve a lot of getting the Unicode code point and looking up the > properties of that code point. > I'm not sure. A unicode naive xml parser works well enough when fed UTF-8, in the sense that the vast majority of real inputs will produce the expected and wanted output. But whether there are some gotchas in the XML specification that make this incorrect, I don't know. The formal official XML specification is hopelessly broken anyway, because it allows for recursive token definitions that open the way to the "barrel of laughs" exploit. A parser that rejects this part of the standard is more useful in practice. > > > if you're parsing an IFF file, it's likely that the tags will be > > Is that some kind of audio file tagging format? If what you are > parsing isn't really Unicode (it's a binary tag structure containing > some fields with Unicode in them) except for the strings, yes, you > can often interpret the strings as bytes you can ship out on a web > page or to stdout. If your output charset is UTF-8, (and I try to > set up xterms that way, with lots and lots of fonts) you can ship > it unconverted. > IFF is a general format for binary files. You have 32 bit tags consisting of 4 ascii characters, followed by a length filed. The idea is that IFF files can be extended, with the reader simply skipping over any chunks it doesn't recognise. So you can add a "HASH" tag at a late state that, for example, signs the file with a cryptographic hash. Existing parsers that have no security can still read the file. > So the hypothetical but not unrealistic case is where you want to pull out the unrecognised tags and report them to the user. > > Consider what happens if you have to interpret all Unicode characters > with general category 'Nd' (decimal number) as parts of a number. > As of Unicode 6.3, I think there are 460 of them, probably more by > now. I'm not sure how you tell the difference between a left-to-right > decimal number and a right-to-left decimal number. It may also > have to deal with an identifier, which is an alphabetic character > followed by zero or more alphanumeric characters. There are 15248 > characters in Unicode 6.3 that seem to qualify as 'letters', including > over a thousand Egyption hieroglyphs. > Arabic numerals, by which I mean the numerals used by Arabs, have different glyphs to Western numerals. Hebrew numerals are also letters, you have to know by context whether a word or a number is being represented. However both cultures tend to use the Western digits for numerically intensive work, even we the rest of the document is in Hebrew or Arabic.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-11 21:00 +0100 |
| Message-ID | <87r3pi6mnm.fsf@bsb.me.uk> |
| In reply to | #63194 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> Hi there Barry.
>
> On Thursday, June 11, 2015 at 8:23:32 PM UTC+2, Barry Schwarz wrote:
>> On Thu, 11 Jun 2015 07:19:27 -0700 (PDT), "Morten W. Petersen"
>> <morphex@gmail.com> wrote:
>>
>> >OK. I understand the concept of pointers but I guess it takes time
>> > to get used to handling pointers, pointers to pointers etc. and
>> > its semantics in C.
>> >
>> >I uploaded a new version of decode_xml.c here
>> >
>> >https://github.com/morphex/smash_xml/blob/b75d7e46164a306542be62c78c52627e18884a26/decode_xml.c
>>
>> In addition to the problems others have pointed out:
>>
>> For some reason, you seem to be infatuated with casts. Most are
>> useless (e.g., lines 60 & 309). Others have a potentially detrimental
>> impact on performance (e.g., lines 264-277). At the very least, they
>> are misleading to the reader. You are also inconsistent in the use of
>> these casts (e.g., lines 307/311/322/333/ but 337).
>
> OK. Well, I'm learning about these casts, and to me it seems that to
> be explicit is better than implicit.
C is full so full of implicit type conversions that it's just not worth
trying to document them all with casts! Let's look at just one case:
inline long is_attribute_value_start(char* buffer, long offset) {
unsigned long character = read_unicode_character(buffer, offset);
if (character == (long) 0x22 || character == (long) 0x27) {
return character;
} else {
return 0;
}
}
Here you cast 0x22 to a long, but it's converted immediately to an
unsigned long. The return value from read_unicode_character is also
being converted as are the two expressions in the return statements. I
count five conversions but only two casts.
The real question is why are the types different in the first place? To
avoid the implicit conversions you could have written this:
inline unsigned long is_attribute_value_start(char* buffer, long offset) {
unsigned long character = read_unicode_character(buffer, offset);
if (character == 0x22ul || character == 0x27ul) {
return character;
} else {
return 0ul;
}
}
and I'd change read_unicode_character to return an unsigned long.
But I would not bother, in general, trying to remove them all. Just
accept that you will (eventually) have to learn C's baroque implicit
type conversions (they have a certain logic to them, just like the
Baroque). Use the fact that you have casts to find those places where
you have artificial type mismatches (like the above), but otherwise
remove most of them. As for "natural" type mismatches, I'd leave 0x22
and 0 alone. The obvious conversion is safe.
Compiler options can also be used to tell you more about these
conversions than you probably want, but it's a good idea to use the from
time to time, just to review any conversions might be problematic.
> I'd like this to run well on any
> platform.
I just took a look and the most significant non-portable element I say
was the use of a union to get the "packed" Unicode value from some
collection of bytes (i.e. in read_unicode_character). It all looks
rather odd since it looks like the array is treated as an array of 4-byte
codes rather than a char array. Anyway, depending on what you do with
it, the union is likely to behave differently on different platforms.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2015-06-11 19:58 -0700 |
| Message-ID | <b7hkna9ee41jvrqejb2q9ncta2iuhchsag@4ax.com> |
| In reply to | #63194 |
On Thu, 11 Jun 2015 12:08:18 -0700 (PDT), "Morten W. Petersen"
<morphex@gmail.com> wrote:
>Hi there Barry.
>
>On Thursday, June 11, 2015 at 8:23:32 PM UTC+2, Barry Schwarz wrote:
<snip>
>> For some reason, you seem to be infatuated with casts. Most are
>> useless (e.g., lines 60 & 309). Others have a potentially detrimental
>> impact on performance (e.g., lines 264-277). At the very least, they
>> are misleading to the reader. You are also inconsistent in the use of
>> these casts (e.g., lines 307/311/322/333/ but 337).
>
>OK. Well, I'm learning about these casts, and to me it seems that to be explicit is better than implicit. I'd like this to run well on any platform.
Others have explained how excessive casting causes the opposite.
>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".
>> You have numerous mismatches in your calls to printf between the
>> conversion specification and the corresponding argument. Some are
>> possibly harmless mismatches in sign (e.g., lines 70 & 94). Others
>> are major type mismatches that lead to undefined behavior (e.g., lines
>> 211, 328, & 405)
>
>Yep. These printf statements are just a quick and dirty way to see what's going on.
Since the behavior is undefined, you have no idea if what you see
reflects what is going on.
<snip>
>> You free buffer in line 423. Why do you not free attribute?
>
>I think things are OK now, see the new code here:
>
>https://github.com/morphex/smash_xml/blob/9bb574365a1307ecf196d4eb64de76f207563158/decode_xml.c
Things are only slightly better.
In line 409, you attempt to print the address of attribute. Since
attribute is an automatic variable in main, that address is
irrelevant. What you want to print is the address contained in
attribute which came to you from run_attribute_name. Whenever you
want to print any address value, use %p and cast the address to void*.
(Yes, this is one of the times you NEED a cast.)
In lines 336-339, you never test if realloc() succeeded. As a
result, it is possible for size to be positive and attribute to be
NULL in lines 411-415. Just some more undefined behavior.
While probably not a problem, line 414 contains an extraneous
argument.
>> In run_attribute_name, you changed the type of attribute to
>> unsigned long ** and made some of the necessary corresponding changes
>> where the parameter is used. You missed several (lines 310, 321, 326,
>> 328, & 332)
>
>Yep. I googled for some solutions and found that I could work on a "local" dynamic character buffer, and then
>towards the end update the pointer to a pointer to point towards this place.
>
>I assume that free works based on memory address, which should be the same for attribute_storage and attribute?
Yes, the name of the variable you pass to free is irrelevant. It is
the value that counts.
By the way, int is defined to be the "natural" integer for the system.
By using long almost everywhere, you are forcing the compiler to
generate possibly inefficient code in violation of your intent to have
it run well everywhere.
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-11 23:42 -0700 |
| Message-ID | <df87df99-138c-4f76-b6fc-02f890dd778b@googlegroups.com> |
| In reply to | #63203 |
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? I guess gcc is ported to just about any platform that has potential and might make this point irrelevant but it is interesting nonetheless. > In lines 336-339, you never test if realloc() succeeded. As a > result, it is possible for size to be positive and attribute to be > NULL in lines 411-415. Just some more undefined behavior. 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? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-12 08:33 +0100 |
| Message-ID | <mle1ua$t29$1@dont-email.me> |
| In reply to | #63204 |
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". <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? As it turns out, this is the wrong question. The right question is "is it a good idea, whenever asking the host environment any question, to ensure that the answer is what I hoped and expected it to be?" And the answer is "yes". It's an excellent habit to get into. Ignore it at your peril (or rather, the inconvenience of your users). Whenever you are manipulating a file stream (whether to read data, write data, or just to jump around within the file), whenever you are requesting a new memory block or adjusting the size of an existing one, or whatever it is that you are doing that relies on the environment behaving "normally", make sure that the behaviour is indeed what you expect. -- 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 | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-06-12 02:36 -0700 |
| Message-ID | <aed15de4-60b1-4daa-96c7-8fb5f2f1d6a2@googlegroups.com> |
| In reply to | #63205 |
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? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-12 11:07 +0100 |
| Message-ID | <mleavh$rl6$1@dont-email.me> |
| In reply to | #63206 |
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). -- 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 | gwowen <gwowen@gmail.com> |
|---|---|
| Date | 2015-06-12 04:55 -0700 |
| Message-ID | <d56bde4f-b4e3-48be-9813-c29639a7c5ba@googlegroups.com> |
| In reply to | #63208 |
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?
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web