Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #71186 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-09-25 04:02 +0200 |
| Last post | 2015-10-02 00:16 +0200 |
| Articles | 20 on this page of 332 — 34 participants |
Back to article view | Back to comp.lang.c
Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 04:02 +0200
Re: Unexpected and difficult to understand SIGSEGV "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-24 19:51 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:09 +0200
Re: Unexpected and difficult to understand SIGSEGV John Gordon <gordon@panix.com> - 2015-09-25 04:32 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:09 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-25 22:07 +0000
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-25 18:46 -0400
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-26 10:57 +1200
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-25 21:40 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-26 16:51 +1200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-26 10:45 +0100
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-26 03:39 -0700
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-26 12:20 +0100
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-26 06:39 -0700
Re: Unexpected and difficult to understand SIGSEGV fir <profesor.fir@gmail.com> - 2015-09-27 01:45 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-26 23:11 +0200
Re: Unexpected and difficult to understand SIGSEGV jacobnavia <jacob@jacob.remcomp.fr> - 2015-09-25 10:28 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-25 10:33 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:05 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-25 16:44 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:08 +0200
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-25 10:55 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:00 +0200
Re: Unexpected and difficult to understand SIGSEGV luser droog <luser.droog@gmail.com> - 2015-09-25 09:40 -0700
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-25 20:25 +0100
Re: Unexpected and difficult to understand SIGSEGV <william@wilbur.25thandClement.com> - 2015-09-25 19:07 -0700
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-26 10:47 +0100
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-26 10:34 -0400
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-26 15:28 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 17:32 -0700
Re: Unexpected and difficult to understand SIGSEGV Noob <root@127.0.0.1> - 2015-09-27 09:59 +0200
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-30 02:52 -0700
Re: Unexpected and difficult to understand SIGSEGV Noob <root@127.0.0.1> - 2015-09-30 20:13 +0200
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:00 -0700
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-28 08:17 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-30 04:00 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-01 09:34 +1300
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-01 19:05 +0000
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-02 08:25 +1300
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:02 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 12:57 +1300
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-06 09:23 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-07 11:18 +1300
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 13:52 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 09:51 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-29 11:07 +0000
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 15:09 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-30 07:34 +0000
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-30 10:33 +0200
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-30 11:14 +0100
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-30 12:26 +0200
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-30 11:58 +0100
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-01 19:16 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:21 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-01 19:27 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 07:58 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-01 21:52 +0200
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:10 -0700
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-27 11:15 +0100
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-28 08:47 +0000
Re: Unexpected and difficult to understand SIGSEGV Andrew Cooper <amc96@cam.ac.uk> - 2015-09-26 00:02 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 00:02 +0200
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-26 23:32 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 22:10 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 17:01 -0400
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-27 22:15 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 23:36 +0200
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 23:33 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 10:40 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 23:58 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 11:08 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 00:25 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 12:50 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:06 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:15 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:20 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:24 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:44 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:50 +1300
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-09-27 23:44 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 20:17 +1300
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-28 01:06 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-28 16:59 +0200
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-28 09:23 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-29 07:47 +1300
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-28 13:46 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-29 07:52 +1300
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:15 +0200
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 09:55 +0000
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-02 11:59 -0400
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-03 11:51 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-03 15:25 -0400
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:50 -0700
Re: Unexpected and difficult to understand SIGSEGV Richard Damon <Richard@Damon-Family.org> - 2015-09-27 18:32 -0400
Re: Unexpected and difficult to understand SIGSEGV asetofsymbols@gmail.com - 2015-09-27 17:37 -0700
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-27 17:50 -0700
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-28 18:18 +0000
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-28 11:31 -0700
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-29 07:37 +0000
Re: Unexpected and difficult to understand SIGSEGV asetofsymbols@gmail.com - 2015-09-27 17:38 -0700
Re: Unexpected and difficult to understand SIGSEGV asetofsymbols@gmail.com - 2015-09-27 17:39 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:42 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:46 +0200
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 09:56 +0000
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 18:20 -0400
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-27 15:54 -0700
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-27 18:23 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 00:33 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 11:42 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:04 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 12:32 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:37 +0200
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-27 16:53 -0700
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-28 00:21 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:30 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-28 00:41 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:52 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 12:59 +1300
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-28 17:07 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-30 11:17 +0000
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-09-30 06:08 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-27 17:09 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:17 +0200
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-28 09:00 -0700
Re: Unexpected and difficult to understand SIGSEGV ais523 <ais523@nethack4.org> - 2015-10-01 14:05 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 16:23 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-01 10:26 -0400
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-01 16:53 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-01 11:26 -0400
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-01 21:57 +0200
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-01 13:30 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 13:57 -0700
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-01 17:19 -0400
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-01 15:38 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 17:14 -0700
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:19 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 15:01 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-04 18:26 -0400
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 17:53 -0700
Re: Unexpected and difficult to understand SIGSEGV Richard Damon <Richard@Damon-Family.org> - 2015-10-04 18:37 -0400
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-04 19:13 -0400
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 17:57 -0700
Re: Unexpected and difficult to understand SIGSEGV Richard Damon <Richard@Damon-Family.org> - 2015-10-04 21:57 -0400
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 01:53 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-05 09:37 -0700
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 14:10 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-09 14:35 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-10 11:43 +1300
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-12 09:17 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-12 12:32 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-12 14:12 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-12 14:52 -0700
Re: Unexpected and difficult to understand SIGSEGV glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-13 03:00 +0000
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-12 23:34 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-14 11:00 +0000
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-14 08:34 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-14 11:34 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-14 11:57 -0700
Re: Unexpected and difficult to understand SIGSEGV glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-15 00:03 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 10:57 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-20 16:06 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-17 07:32 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-17 07:51 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-17 15:51 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 10:09 +0000
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-02 08:55 -0400
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-02 08:59 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 17:35 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 10:02 -0700
Re: Unexpected and difficult to understand SIGSEGV Robert Wessel <robertwessel2@yahoo.com> - 2015-10-03 16:11 -0500
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-03 17:27 -0400
Re: Unexpected and difficult to understand SIGSEGV Robert Wessel <robertwessel2@yahoo.com> - 2015-10-03 16:58 -0500
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 15:16 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-03 18:21 -0400
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-03 18:23 -0400
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-03 18:52 -0400
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 16:16 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-03 19:13 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 23:34 -0700
Re: Unexpected and difficult to understand SIGSEGV glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-04 07:09 +0000
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 14:43 -0700
Re: Unexpected and difficult to understand SIGSEGV Robert Wessel <robertwessel2@yahoo.com> - 2015-10-04 03:19 -0500
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:48 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 16:26 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 13:21 -0700
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-02 17:05 -0400
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-02 15:11 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 20:55 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 12:00 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-03 16:52 -0700
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:40 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-01 22:02 -0400
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 10:09 +0100
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 08:19 -0700
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-02 03:17 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-02 13:02 +0200
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-01 18:33 -0700
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-01 11:17 -0400
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-01 17:06 +0100
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 11:45 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 10:21 +0000
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 11:36 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 11:44 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 13:24 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 15:31 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 18:04 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 18:21 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 21:04 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-03 08:29 +0200
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-03 16:47 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-03 17:37 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-03 17:54 +0100
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-04 18:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 18:13 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-04 18:22 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 20:17 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-04 21:07 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 22:10 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 09:24 +1300
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 22:15 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 10:38 +1300
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 23:02 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 11:10 +1300
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 23:51 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 11:56 +1300
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 07:38 +1300
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-04 23:51 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 23:44 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 11:52 +1300
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-05 00:09 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 13:00 +1300
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-10-04 17:14 -0700
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-05 09:40 -0700
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-05 18:32 +0100
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-05 21:59 -0700
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 01:13 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-06 17:14 +0000
Re: Unexpected and difficult to understand SIGSEGV Gareth Owen <gwowen@gmail.com> - 2015-10-02 14:56 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 16:31 +0100
Re: Unexpected and difficult to understand SIGSEGV Gareth Owen <gwowen@gmail.com> - 2015-10-02 20:11 +0100
Re: Unexpected and difficult to understand SIGSEGV jadill33@gmail.com - 2015-10-02 09:18 -0700
Re: Unexpected and difficult to understand SIGSEGV Gareth Owen <gwowen@gmail.com> - 2015-10-02 20:14 +0100
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 10:20 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-04 14:03 +0000
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 09:28 -0700
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-10-01 18:53 +0200
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-10-02 06:26 +0200
Generating header files (Was: Unexpected and difficult to understand SIGSEGV) Roberto Waltman <usenet@rwaltman.com> - 2015-10-01 13:40 -0400
Re: Generating header files (Was: Unexpected and difficult to understand SIGSEGV) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 23:58 +0200
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:06 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 21:05 -0400
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:26 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 21:15 -0400
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-28 09:52 -0400
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-28 10:36 -0400
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-28 10:40 -0400
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-28 15:55 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-29 01:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 00:26 +0100
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:34 +0200
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 15:50 +0100
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-29 11:16 -0400
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 16:22 +0100
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-29 13:15 -0400
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 18:56 +0100
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-29 07:04 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 00:07 +0200
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-29 18:13 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-09-29 21:57 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-30 01:57 -0400
Re: Unexpected and difficult to understand SIGSEGV jadill33@gmail.com - 2015-09-30 06:01 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:11 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-30 14:12 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:15 +0200
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-30 08:40 -0700
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 22:28 +0200
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 22:31 +0200
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-30 16:53 -0400
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 23:19 +0200
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 23:32 +0200
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-30 18:17 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 03:19 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-30 22:01 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-02 00:46 +0200
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 17:44 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:51 +1300
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 18:04 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 03:39 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 22:03 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 04:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 15:19 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 04:23 +0200
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 14:11 +0200
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 00:15 +0200
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-29 18:14 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-02 00:41 +0200
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-27 19:58 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:43 +0200
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 00:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-29 15:51 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:37 +0200
Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 09:12 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-09-30 17:34 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 11:29 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-09-30 20:00 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 12:49 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-09-30 22:26 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 16:27 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-10-01 09:56 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 03:08 +0200
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-30 13:10 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Ian Collins <ian-news@hotmail.com> - 2015-10-01 09:23 +1300
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-30 19:02 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Richard Heathfield <rjh@cpax.org.uk> - 2015-10-01 03:12 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-10-01 11:15 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Richard Heathfield <rjh@cpax.org.uk> - 2015-10-01 11:36 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-01 05:49 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) David Brown <david.brown@hesbynett.no> - 2015-10-01 16:41 +0200
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Ian Collins <ian-news@hotmail.com> - 2015-10-01 15:16 +1300
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-30 19:10 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Ian Collins <ian-news@hotmail.com> - 2015-10-01 15:20 +1300
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Philip Lantz <prl@canterey.us> - 2015-10-01 01:26 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-01 02:16 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Martin Shobe <martin.shobe@yahoo.com> - 2015-10-01 08:34 -0500
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 19:06 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 04:18 +0200
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 21:32 -0700
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 07:54 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 17:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-27 11:21 -0400
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 08:59 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-02 00:16 +0200
Page 16 of 17 — ← Prev page 1 … 14 15 [16] 17 Next page →
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-30 16:37 +0200 |
| Message-ID | <mugs2c$jtv$1@speranza.aioe.org> |
| In reply to | #71455 |
On 30.09.2015 00:51, Malcolm McLean wrote: > On Tuesday, September 29, 2015 at 11:16:38 PM UTC+1, Morten W. Petersen wrote: >> On 29.09.2015 10:43, David Brown wrote: >>> On 28/09/15 04:16, Morten W. Petersen wrote: >> [...] >>>> I guess the best way to select functions for inlining would be to >>>> profile the code as it was dealing with real data. Are there tools >>>> that do that? >>> >>> Yes, there are tools to do that. But they are not normally necessary. >>> The compiler will usually do a good job of deciding which functions >>> should be inlined, and which should not. >> >> OK. Can you name any Open Source tools available for that job? >> > gprof. > It runs on Linux. It will tell you how many times each function > was called, how long the program sent in the function itself, > and how long the function spent in the function and all its > subroutines. So it tells you where the bottlenecks are. OK. > However just inlining seldom helps much, because the compiler does > that anyway. What you can often do is avoid calcuating things > twice. For example, if your logic is "replace employee name with > duplicate string, set namelen field to number of characters in > name" you would normally write that as employee.name = strdup(name); > employee.namelen = strlen(name). However strdup is going to > get the length of the name internally, you don't actually need > the second call. Ah yes, good tip to think along those lines since the index will be used on strdup anyway. -Morten
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-30 09:12 -0700 |
| Subject | Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <3792ece5-5d78-4f4b-ac61-ed88f9fd5f74@googlegroups.com> |
| In reply to | #71485 |
On Wednesday, September 30, 2015 at 9:37:18 AM UTC-5, Morten W. Petersen wrote: > On 30.09.2015 00:51, Malcolm McLean wrote: > > ..... For example, if your logic is "replace employee name with > > duplicate string, set namelen field to number of characters in > > name" you would normally write that as employee.name = strdup(name); > > employee.namelen = strlen(name). However strdup is going to > > get the length of the name internally, you don't actually need > > the second call. > > Ah yes, good tip to think along those lines since the index will > be used on strdup anyway. I wonder why nulls are called the "billion dollar mistake". Zero-terminated strings are far worse. While the design for zero-terminated strings could be cranked out in a day, and an equally-versatile design for prefixed strings [using a variety of prefix formats for short strings, long strings, references to dynamically-allocated string buffers, or references to strings stored elsewhere] would probably have taken a month or so, I think the research effort for the latter would have paid off in the intervening years; most of the complexity could be confined to a couple routines (given a pointer to a "string", produce a pointer to the text, its length, and the size of the buffer) and even they needn't be very big or time consuming in a minimal implementation.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-30 17:34 +0100 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <muh2q5$2ke$1@dont-email.me> |
| In reply to | #71488 |
On 30/09/2015 17:12, supercat@casperkitty.com wrote: > On Wednesday, September 30, 2015 at 9:37:18 AM UTC-5, Morten W. Petersen wrote: >> On 30.09.2015 00:51, Malcolm McLean wrote: >>> ..... For example, if your logic is "replace employee name with >>> duplicate string, set namelen field to number of characters in >>> name" you would normally write that as employee.name = strdup(name); >>> employee.namelen = strlen(name). However strdup is going to >>> get the length of the name internally, you don't actually need >>> the second call. >> >> Ah yes, good tip to think along those lines since the index will >> be used on strdup anyway. > > I wonder why nulls are called the "billion dollar mistake". Zero-terminated > strings are far worse. While the design for zero-terminated strings could > be cranked out in a day, and an equally-versatile design for prefixed strings > [using a variety of prefix formats for short strings, long strings, > references to dynamically-allocated string buffers, or references to strings > stored elsewhere] would probably have taken a month or so, I think the > research effort for the latter would have paid off in the intervening years; > most of the complexity could be confined to a couple routines (given a > pointer to a "string", produce a pointer to the text, its length, and the > size of the buffer) and even they needn't be very big or time consuming in > a minimal implementation. No, zero-terminated strings are very, very useful in all sorts of places, not just within C: in interfaces between languages, in file formats, inside ASM code and so on. It suits a language such as C (which is then used to implement something more sophisticated). You've already mentioned some of the problems of not using terminated strings: > [using a variety of prefix formats for short strings, long strings, > references to dynamically-allocated string buffers, or references to > strings stored elsewhere] Every program, language and interface would use its own incompatible scheme. And a scheme that satisfies everyone would probably have unacceptable overheads. And/or you wouldn't just be able to copy a struct containing a flat char[] array to another struct. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-30 11:29 -0700 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <d586c6fc-6669-4763-84a8-2815e912fbd8@googlegroups.com> |
| In reply to | #71490 |
On Wednesday, September 30, 2015 at 11:34:22 AM UTC-5, Bart wrote: > On 30/09/2015 17:12, supercat wrote: > No, zero-terminated strings are very, very useful in all sorts of > places, not just within C: in interfaces between languages, in file > formats, inside ASM code and so on. The primary advantages I've seen cited for zero-terminated strings versus length-prefixed strings are: 1. A pointer to a character within a string may be used as a pointer to the tail (useful occasionally), though no other substrings may be used easily. 2. There's no fixed upper limit on string length. 3. Strings stored in known-size buffers have only one byte of overhead. The approach I'd favor would require slightly more work to create a substring reference, but it would be able to use an arbitrary substring--not just the tail, it would be extensible to any string length up to LONG_MAX, and it would have one byte of overhead for strings *or buffers* up to 63 bytes, two bytes of overhead for up to 4096 bytes, three for strings up to 262,144 bytes, or five for up to 4,294,967,296 bytes. Zero-terminated strings sometimes work kinda-sorta okay as "source operands", but there's no way zero-terminated strings can safely be used as a destination operands for any string operation whose source does not have a known upper-bound on its length unless the code performing the operation knows or is told the size of the destination buffer. > > [using a variety of prefix formats for short strings, long strings, > > references to dynamically-allocated string buffers, or references to > > strings stored elsewhere] > > Every program, language and interface would use its own incompatible > scheme. And a scheme that satisfies everyone would probably have > unacceptable overheads. And/or you wouldn't just be able to copy a > struct containing a flat char[] array to another struct. The extent to which everyone would use other schemes would depend upon whether a scheme was established that could effectively fit needs. Right now if one wants to have a module which can append a bunch of data to either a fixed-sized string buffer or a realloc-on-demand string buffer, it's necessary to have separate functions for those two possibilities, as well as separate functions for any other method of string storage. Further, anything which is going to deal with a fixed-sized string buffer will have to pass the size along with a pointer to the buffer itself (and, for efficiency, will probably also have to pass around the current length of the buffer's contents). What I would like to see would be an API which regarded strings as a mostly abstract concept based around functions to - "format" a range of memory as a string buffer of a certain type (tiny, small, large, or huge); this would write the prefix and possibly some bytes following it). The offset of the text relative to the prefix would be fixed for each category of strings. - take a pointer to an abstract string and return a descriptor holding a header (so the descriptor *itself* could be passed to functions expecting a string) its length, allocated size, and a pointer to the content. Code which wants to pass part of a string to a function could get the descriptor, modify the length or text pointer, and then pass that as though it was a string. - take a pointer to an abstract string and a string descriptor, and adjust the length to either the requested value or the largest possible value given its size and the nature of the allocation [if the string is stored dynamically, the text may get relocated, with the descriptor and the abstract string object both being updated appropriately; if the string is not stored dynamically, the length would be pegged to the allocation size]. - given a pointer to a "dynamic string" structure, turn it into a dynamically resizable string which will use either realloc() or a supplied allocation function as necessary, with support for shareable or unsharable semantics. - given a pointer to a string, release any dynamic allocation associated with it (harmlessly do nothing if the string doesn't have any dynamic allocation) Given those functions as a basis, application code would not have to worry about the exact details of the prefix (which might potentially be different on big-endian and little-endian machines), save for knowing what prefix byte value to use for user-created string-descriptor objects which will be passed as strings. Code may call: str_concat(dest, src); without regard for whether src and dest were fixed-sized buffers, dynamically allocated strings, pointers into the content of other strings, etc. with the caveats that resizing a simple realloc-based string will invalidate any other unsharable string objects that may exist with the same backing store, and will invalidate any string descriptors (but not string objects) associated with a shareable backing store. Although the functions to generate descriptors from string objects, or to update the lengths of string objects, would have a little bit of complexity, most code dealing with strings could be made simpler than is now possible since passing a simple pointer to a string object would implicitly also pass its length and allocated size. Since string content would be copied without regard for whether it contained zeroes, the risk of out-of-bounds memory accesses in things like string-copy operations would be significantly reduced.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-30 20:00 +0100 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <muhbdf$aob$1@dont-email.me> |
| In reply to | #71493 |
On 30/09/2015 19:29, supercat@casperkitty.com wrote: > On Wednesday, September 30, 2015 at 11:34:22 AM UTC-5, Bart wrote: >> On 30/09/2015 17:12, supercat wrote: >> No, zero-terminated strings are very, very useful in all sorts of >> places, not just within C: in interfaces between languages, in file >> formats, inside ASM code and so on. > > The primary advantages I've seen cited for zero-terminated strings versus > length-prefixed strings are: > > 1. A pointer to a character within a string may be used as a pointer to > the tail (useful occasionally), though no other substrings may be > used easily. > > 2. There's no fixed upper limit on string length. > > 3. Strings stored in known-size buffers have only one byte of overhead. > The approach I'd favor would require slightly more work to create a substring > reference, but it would be able to use an arbitrary substring--not just the > tail, it would be extensible to any string length up to LONG_MAX, and it > would have one byte of overhead for strings *or buffers* up to 63 bytes, two > bytes of overhead for up to 4096 bytes, three for strings up to 262,144 bytes, > or five for up to 4,294,967,296 bytes. So, what are you saying? That C should have used counted strings from the start, or that it should support both zero-terminated and counted strings? C already allows counted strings to be used as well as zero-terminated ones. You just have to do-it-yourself. (No one is going to agree to a common scheme anyway.) > Zero-terminated strings sometimes work kinda-sorta okay as "source operands", > but there's no way zero-terminated strings can safely be used as a > destination operands for any string operation whose source does not have > a known upper-bound on its length unless the code performing the operation > knows or is told the size of the destination buffer. That would be the same problem with a fixed-size counted-string buffer. How would a function writing into it know the limit? The buffer would need to be pre-prepared by setting up a dummy string of the maximum length before calling the function. But if going to that much trouble, you can do something similar with a zero-terminated buffer. > What I would like to see would be an API which regarded strings as a mostly > abstract concept based around functions to I think this would be too high-level for C. Don't forget a 'string' can be a 4-byte field inside a struct, or a 4-billion character string representing the contents of a file. You want the simplest possible way of dealing with the first case. > - "format" a range of memory as a string buffer of a certain type (tiny, > small, large, or huge); this would write the prefix and possibly some > bytes following it). The offset of the text relative to the prefix > would be fixed for each category of strings. That would be unacceptable overhead compared with C does now (which can either be to do nothing, or to write a single zero byte at the start. There is still the problem of communicating the maximum capacity of the string buffer, but a similar problem occurs with dynamic arrays, which people will already be familiar with solving. > Code may call: > > str_concat(dest, src); > > without regard for whether src and dest were fixed-sized buffers, dynamically > allocated strings, pointers into the content of other strings, etc. That's great, but for the next language up from C! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-30 12:49 -0700 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <21eed248-359e-4c61-a950-e2ced3e93962@googlegroups.com> |
| In reply to | #71495 |
On Wednesday, September 30, 2015 at 2:01:20 PM UTC-5, Bart wrote:
> C already allows counted strings to be used as well as zero-terminated
> ones. You just have to do-it-yourself. (No one is going to agree to a
> common scheme anyway.)
Unfortunately, C lacks any means of getting a pointer to an inline-
initialized static object of any kind other than zero-terminated
strings. It's possible to define a macro to to create a named
identifier for a pre-initialized prefix string, but such a thing can
only be used at statement scope.
> That would be the same problem with a fixed-size counted-string buffer.
> How would a function writing into it know the limit? The buffer would
> need to be pre-prepared by setting up a dummy string of the maximum
> length before calling the function. But if going to that much trouble,
> you can do something similar with a zero-terminated buffer.
As I would like to see things, preparing an initially-empty tiny string
would require one character store; a small string would require two
character stores or (if aligned) a 16-bit store. Setting up a dummy
zero-terminated string of proper length would by contrast require N
stores.
The problem with not having buffers contain information about their own
size is that any code which passes around a pointer to the buffer must
either
1. Assume that the buffer is going to be large enough for anything that
code might try to put it in it (the C approach), even though many
methods only make sense in cases where code doesn't *know* the size
of the source operand (if code did know, it may as well use memcpy).
2. Be designed to work with a buffer of a particular fixed size, which
works for some kinds of code, but isn't so great for special-purpose
code.
3. Requires that code always pass around information about the buffer's
size along with a pointer to the buffer's content.
I would suggest that being about to pass around one pointer that the
recipient will be able to use to ascertain the present length, allocated
size, and address of the text will in many cases allow more compact code
than requiring that all code working with strings manually pass around
all three values separately.
> I think this would be too high-level for C. Don't forget a 'string' can
> be a 4-byte field inside a struct, or a 4-billion character string
> representing the contents of a file. You want the simplest possible way
> of dealing with the first case.
My approach deals with that just fine. One simple encoding would be to
say that five-byte buffer holding the string "test" would contain
{4,'t','e','s','t'}. A five-byte buffer initialized with "ABC" would be
{0x44,'A','B','C',0}; initialized with "XY" would be {0x44,'X','Y',any,1}.
Initialized empty would be {0x84,any,any,any,any}.
First byte if 0-0x3F indicates a string of the indicated length which fills
the buffer. 0x40-0x7F indicates a buffer of the indicated length whose last
byte indicates the amount of free space, minus one. 0x80-0xBF indicates an
empty buffer of the indicated size.
For medium strings, first-byte values 0xC0-0xCF would, with an extra length
byte, handle strings up to 4095 bytes that fill the buffer; 0xD0-0xDF would handle partially-full buffers [the last byte if zero would indicate that
there was exactly one byte free; if one, the last two bytes were free (the
second-to-last byte could be written with zero if desired). Otherwise the
last two bytes would hold the amount of free space, LSB first, plus 512.
> That would be unacceptable overhead compared with C does now (which can
> either be to do nothing, or to write a single zero byte at the start.
> There is still the problem of communicating the maximum capacity of the
> string buffer, but a similar problem occurs with dynamic arrays, which
> people will already be familiar with solving.
The overhead of storing a byte or short to a struct field is apt to be
pretty well in line with passing an extra "int" argument to a function
[in practice most implementations would be expected to use macros for
the purpose]. So even if there were a version of "strcat" which accepted
a "destination length" parameter, the pattern [after macro expansion]
union {
STRING st[1];
struct { unsigned short mlen; char text[1234]; } dat;
} dest[1];
dest->dat.mlen = (((sizeof foo->dat.text) & 255) << 8) +
((sizeof foo->dat.text) >> 8) | 0xE0;
str_concatx(dest->st, src1->st);
str_concatx(dest->st, src2->st);
would seem more code-space-efficient than
char dest[1234];
safe_strcat(dest, src1, 1234);
safe_strcat(dest, src2, 1234);
and would only require one extra byte of storage for "dest" [a cost which
would be lower than the cost of using an integer somewhere to keep track
of the length of dest].
> That's great, but for the next language up from C!
Actually, Windows has by now evolved BSTR, which trades off a higher
minimum overhead for speed (each string has a four-byte length prefix).
Cutting the overhead for shorter strings would still be useful in embedded
systems, but not so much on mainstream development anymore.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-30 22:26 +0100 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <muhjtv$fio$1@dont-email.me> |
| In reply to | #71497 |
On 30/09/2015 20:49, supercat@casperkitty.com wrote:
> On Wednesday, September 30, 2015 at 2:01:20 PM UTC-5, Bart wrote:
>> C already allows counted strings to be used as well as zero-terminated
>> ones. You just have to do-it-yourself. (No one is going to agree to a
>> common scheme anyway.)
>> That would be the same problem with a fixed-size counted-string buffer.
>> How would a function writing into it know the limit? The buffer would
>> need to be pre-prepared by setting up a dummy string of the maximum
>> length before calling the function. But if going to that much trouble,
>> you can do something similar with a zero-terminated buffer.
>
> As I would like to see things, preparing an initially-empty tiny string
> would require one character store; a small string would require two
> character stores or (if aligned) a 16-bit store. Setting up a dummy
> zero-terminated string of proper length would by contrast require N
> stores.
That's why I said some scheme would have to be used, rather than have to
fill a million-char buffer with spaces followed by a zero, and expect a
function to scan those million characters to work out the size. That
would obviously be crazy. Such a scheme would be just as arbitrary as
the ones you're proposed for counted (or length-indicated) strings.
> I would suggest that being about to pass around one pointer that the
> recipient will be able to use to ascertain the present length, allocated
> size, and address of the text will in many cases allow more compact code
> than requiring that all code working with strings manually pass around
> all three values separately.
That's fine for long strings, but not for short ones.
>> I think this would be too high-level for C. Don't forget a 'string' can
>> be a 4-byte field inside a struct, or a 4-billion character string
>> representing the contents of a file. You want the simplest possible way
>> of dealing with the first case.
>
> My approach deals with that just fine. One simple encoding would be to
> say that five-byte buffer holding the string "test" would contain
> {4,'t','e','s','t'}. A five-byte buffer initialized with "ABC" would be
> {0x44,'A','B','C',0}; initialized with "XY" would be {0x44,'X','Y',any,1}.
> Initialized empty would be {0x84,any,any,any,any}.
>
> First byte if 0-0x3F indicates a string of the indicated length which fills
> the buffer. 0x40-0x7F indicates a buffer of the indicated length whose last
> byte indicates the amount of free space, minus one. 0x80-0xBF indicates an
> empty buffer of the indicated size.
>
> For medium strings, first-byte values 0xC0-0xCF would, with an extra length
> byte, handle strings up to 4095 bytes that fill the buffer; 0xD0-0xDF would handle partially-full buffers [the last byte if zero would indicate that
> there was exactly one byte free; if one, the last two bytes were free (the
> second-to-last byte could be written with zero if desired). Otherwise the
> last two bytes would hold the amount of free space, LSB first, plus 512.
That sounds very complicated indeed. Also it wouldn't really work for
substrings because you can't stick all this length-encoding bytes in the
middle of a bigger strings.
Passing a pointer and a maximum length is far simpler and more
efficient. I generally use one of these three string-handling schemes:
* Use a C-style pointer to a zero-terminated string as is usually done
(adding any available info about lengths and capacity).
* Use a counted scheme consisting of (pointer, length), pointing to any
string or part-string, zero-terminated or not, including any combination
of substrings. But this is for read-only, or for in-place modifications
that do not affect the length.
* When a flexible string is needed that might grow (or shrink), I use a
more elaborate descriptor, that can also deal with any substrings.
None of the above needs any changes to C, or any extra support from C,
other than the built-in zero-terminated strings it already has.
(For short strings forming a field in a struct, I use my own
length-indicated scheme where I can store strings of up to length N
inside a field of N characters. Again done on top of the language.)
Note that both your schemes and mine might have trouble with UTF-8 where
the concepts of bytes, characters and code-points get all mixed up.
Zero-terminated strings will probably fare better here!
>> That would be unacceptable overhead compared with C does now
> The overhead of storing a byte or short to a struct field is apt to be
> pretty well in line with passing an extra "int" argument to a function
You can't compare the two. One's using up extra space *per-string*, and
extra time (especially the byte-decoding needed.) The other is extra
time per function call.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-30 16:27 -0700 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <d6e6b4c5-c8ee-42e1-8e7d-9109ad02532c@googlegroups.com> |
| In reply to | #71506 |
On Wednesday, September 30, 2015 at 4:26:27 PM UTC-5, Bart wrote:
> > I would suggest that being about to pass around one pointer that the
> > recipient will be able to use to ascertain the present length, allocated
> > size, and address of the text will in many cases allow more compact code
> > than requiring that all code working with strings manually pass around
> > all three values separately.
>
> That's fine for long strings, but not for short ones.
In most cases, string descriptors would only exist in automatic variables
so their overall contribution to memory usage would be pretty slight. From
a run-time perspective the approach I'd suggest would be slower than some
other approaches (e.g. requiring strings to be word-aligned and preceding
each string by a four-byte length field, as is done with Windows BSTR) but
the objective would be to minimize storage space for strings which are not
being immediately operated upon.
> That sounds very complicated indeed. Also it wouldn't really work for
> substrings because you can't stick all this length-encoding bytes in the
> middle of a bigger strings.
If one wants to use foo[50] to foo[54] as a five-character string...
// If C89 had anonymous union members, the annoying "dat." could be
// omitted.
STRING_DESCRIPTOR subst;
subst->dat.header = USER_STRING_DESC;
subst->dat.length = 5;
subst->dat.size = 5;
subst->dat.text = foo+50;
Now "subst.st" can be passed to code expecting a string. Defining a
type for "full-length" strings could save the cost of the assignment to
"size", at a slight cost in speed.
> * When a flexible string is needed that might grow (or shrink), I use a
> more elaborate descriptor, that can also deal with any substrings.
> None of the above needs any changes to C, or any extra support from C,
> other than the built-in zero-terminated strings it already has.
The things C would need to add to make the style of strings I'd like work
nicely would be (1) the ability to initialize static data other than
zero-terminated strings in-line and receive pointers to them; (2) the
ability to overlay structure members without having to add annoying levels
of indirection in all the code that uses them. For some reason, C99 added
the ability to initialize automatic data in-line but not static, and C
still has amazingly poor control over structure layout for something that
was designed to be a systems-programming language.
> Note that both your schemes and mine might have trouble with UTF-8 where
> the concepts of bytes, characters and code-points get all mixed up.
> Zero-terminated strings will probably fare better here!
My approach would regard a "string" as a series of arbitrary octets; unlike
z-strings, it will work just fine with UCS-2 and UTF-16 (though the ability
to represent odd numbers of octets would be wasted). I'm not sure why you
think UTF-8 would be more of a problem with strings of arbitrary octets
than with Z-strings.
Indeed, when programming in languages with string support other than C, I
often use strings to hold variable-sized groups of octets which may contain
zeroes; having string-handling functions which are agnostic to the existence
of zero bytes makes them useful for many purposes which cannot be handled
by C's string functions.
> > The overhead of storing a byte or short to a struct field is apt to be
> > pretty well in line with passing an extra "int" argument to a function
>
> You can't compare the two. One's using up extra space *per-string*, and
> extra time (especially the byte-decoding needed.) The other is extra
> time per function call.
Are you objecting to the two bytes for the string header? That seems like
pretty low overhead for strings in the 64-4096 byte range given that passing
a pointer to the string object will allow the recipient to determine the
location of the text, the length, and the allocated size. With regard to
performance, a simple length-prefixed string can be more performant in common
cases, but will necessitate a trade-off between prefix length and maximum
string length.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-01 09:56 +0100 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <muiscb$884$1@dont-email.me> |
| In reply to | #71512 |
On 01/10/2015 00:27, supercat@casperkitty.com wrote: > On Wednesday, September 30, 2015 at 4:26:27 PM UTC-5, Bart wrote: >> That sounds very complicated indeed. Also it wouldn't really work for >> substrings because you can't stick all this length-encoding bytes in the >> middle of a bigger strings. > > If one wants to use foo[50] to foo[54] as a five-character string... > > // If C89 had anonymous union members, the annoying "dat." could be > // omitted. > STRING_DESCRIPTOR subst; > subst->dat.header = USER_STRING_DESC; > subst->dat.length = 5; > subst->dat.size = 5; > subst->dat.text = foo+50; > > Now "subst.st" can be passed to code expecting a string. What's subst.st? And what's the difference between .length and .size? Anyway, a scheme using a pointer plus length would just pass (foo+50,5), just as you'd use (foo+50,5) if you wanted to pass foo[50..54] of a double array to a function expecting a double array. All very simple and compatible with how things are done elsewhere. >> Note that both your schemes and mine might have trouble with UTF-8 where >> the concepts of bytes, characters and code-points get all mixed up. >> Zero-terminated strings will probably fare better here! > > My approach would regard a "string" as a series of arbitrary octets; unlike > z-strings, it will work just fine with UCS-2 and UTF-16 (though the ability > to represent odd numbers of octets would be wasted). I'm not sure why you > think UTF-8 would be more of a problem with strings of arbitrary octets > than with Z-strings. > > Indeed, when programming in languages with string support other than C, I > often use strings to hold variable-sized groups of octets which may contain > zeroes; having string-handling functions which are agnostic to the existence > of zero bytes makes them useful for many purposes which cannot be handled > by C's string functions. Then the 'length' of the string is just the number of bytes. If a program expects to know the number of characters (or code-points or whatever terminology is used), and to be able to access them by index, then it's going to be disappointed. We're really talking about dealing with byte arrays here rather than strings. >>> The overhead of storing a byte or short to a struct field is apt to be >>> pretty well in line with passing an extra "int" argument to a function >> >> You can't compare the two. One's using up extra space *per-string*, and >> extra time (especially the byte-decoding needed.) The other is extra >> time per function call. > > Are you objecting to the two bytes for the string header? That seems like > pretty low overhead for strings in the 64-4096 byte range given that passing > a pointer to the string object will allow the recipient to determine the > location of the text, the length, and the allocated size. With regard to > performance, a simple length-prefixed string can be more performant in common > cases, but will necessitate a trade-off between prefix length and maximum > string length. I'm confused now. Do the overheads your schemes need, involve adding bytes to the start or end of the the strings, or do they involve constructing a separate descriptor which contains a pointer to the string, or some combination? If they need prefix bytes for example, it doesn't look like you can then pass the middle of such a string without switching to an entire different scheme that uses a descriptor. Which scheme is the function being called going to use? Because if it's in someone else's library, then you can't change it! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-10-01 03:08 +0200 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <mui12a$968$1@speranza.aioe.org> |
| In reply to | #71495 |
On 30.09.2015 21:00, Bartc wrote: [...] > So, what are you saying? That C should have used counted strings from > the start, or that it should support both zero-terminated and counted > strings? > > C already allows counted strings to be used as well as zero-terminated > ones. You just have to do-it-yourself. (No one is going to agree to a > common scheme anyway.) And here there is an opportunity to create a library for working with strings, a set of functions that are well tested with regards to security. Create something good, make it public domain or put it under a permissive BSD-license and it could be a hit. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-09-30 13:10 -0700 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <b09d32e8-7fbd-4a09-90e3-125dd1a8d825@googlegroups.com> |
| In reply to | #71490 |
On Wednesday, September 30, 2015 at 5:34:22 PM UTC+1, Bart wrote: > > Every program, language and interface would use its own incompatible > scheme. And a scheme that satisfies everyone would probably have > unacceptable overheads. And/or you wouldn't just be able to copy a > struct containing a flat char[] array to another struct. > That's the real problem. Every man and his dog knocked up a string class in the early days of C++. It's easy enough. Just attach an integer to the string length, overload the array subscript operator and the addition operator, and you've achieved a fast and safe strcat. Except that you're almost certainly allocating memory, so unless your strings are huge, concatenation is likely slower than with strcat(). But no library will accept class mystring. You've got to have a common language for communicating string data between different parts of the program. And that's going to be the C asciiz string. So class mystring is going to have a constructor that takes an asciiz string, and a toasciiz() method of some form or other.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-01 09:23 +1300 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <d72uluFqr3pU29@mid.individual.net> |
| In reply to | #71499 |
Malcolm McLean wrote: > On Wednesday, September 30, 2015 at 5:34:22 PM UTC+1, Bart wrote: >> >> Every program, language and interface would use its own incompatible >> scheme. And a scheme that satisfies everyone would probably have >> unacceptable overheads. And/or you wouldn't just be able to copy a >> struct containing a flat char[] array to another struct. >> > That's the real problem. > Every man and his dog knocked up a string class in the early days > of C++. It's easy enough. Just attach an integer to the string > length, overload the array subscript operator and the addition operator, > and you've achieved a fast and safe strcat. > Except that you're almost certainly allocating memory, so unless > your strings are huge, concatenation is likely slower than with > strcat(). Eh? The cost would be the same under the condition where strcat() is safe (the buffer is large enough for both). > But no library will accept class mystring. You've got to have > a common language for communicating string data between different > parts of the program. Which is why the C++ standard library has strings. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-09-30 19:02 -0700 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <614c2cef-519b-48ca-85f1-da365b158bef@googlegroups.com> |
| In reply to | #71500 |
On Wednesday, September 30, 2015 at 9:23:51 PM UTC+1, Ian Collins wrote:
> Malcolm McLean wrote:
>
> > Every man and his dog knocked up a string class in the early days
> > of C++. It's easy enough. Just attach an integer to the string
> > length, overload the array subscript operator and the addition operator,
> > and you've achieved a fast and safe strcat.
> > Except that you're almost certainly allocating memory, so unless
> > your strings are huge, concatenation is likely slower than with
> > strcat().
>
> Eh? The cost would be the same under the condition where strcat() is
> safe (the buffer is large enough for both).
>
class mystring
{
char *data;
int len;
public:
mystring()
{
data = 0;
len = 0;
}
mystring(const mystring ©)
{
len = copy.len;
data = (char *) malloc(len+1);
for(i=0;i<len;i++)
data[i] = copy.data[i];
data[len] = 0;
}
mystring(char *init)
{
int i;
for(i=0;init[i];i++) /*empty*/ ;
len = i;
data = (char *) malloc(len+1);
for(i=0;i<len+1;i++)
data[i] = init[i];
}
~mystring() {free (data);}
friend mystring operator + (const mystring &a, const mystring &b);
}
mystring operator +(const mystring &a, const mystring &b)
{
mystring x;
x.len = a.len + b.l;
x.data = (char *) malloc(x.len +1);
for(i=0;i<a.len;i++)
x.data[i] = a.data[i];
for(i=0;i<b.len;i++)
x.data[i+a.len] = b.data[i];
x.data[x.len] =0;
return x;
}
There's a C++ mystring.
Now consider this
mystring firstname("Fred");
mystring lastname("Bloggs");
mystring fullname = firstname + mystring(" ") + lastname;
and
char firstname[256];
char lastname[256];
char fullname[1024];
strcpy(firstname, "Fred");
strcpy(lastname, "Bloggs");
strcpy(fullname, firstname);
strcat(fullname, " ");
strcat(fullname, lastname);
which one will execute faster? Which when we start making the
names extremely long?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-01 03:12 +0100 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <mui4m8$2nl$1@dont-email.me> |
| In reply to | #71517 |
On 01/10/15 03:02, Malcolm McLean wrote:
<snip>
> Now consider this
>
> mystring firstname("Fred");
> mystring lastname("Bloggs");
> mystring fullname = firstname + mystring(" ") + lastname;
>
>
> and
>
> char firstname[256];
> char lastname[256];
> char fullname[1024];
>
> strcpy(firstname, "Fred");
> strcpy(lastname, "Bloggs");
> strcpy(fullname, firstname);
> strcat(fullname, " ");
> strcat(fullname, lastname);
>
> which one will execute faster? Which when we start making the
> names extremely long?
The C++ won't compile (not even with a C++ compiler), so that definitely
loses, but the C code could hardly be said to be written for speed. So
they both lose to a customised function that doesn't lose track of the
place to start writing the appended string.
--
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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-01 11:15 +0100 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <muj116$ov7$1@dont-email.me> |
| In reply to | #71519 |
On 01/10/2015 03:12, Richard Heathfield wrote: > On 01/10/15 03:02, Malcolm McLean wrote: >> strcpy(firstname, "Fred"); >> strcpy(lastname, "Bloggs"); >> strcpy(fullname, firstname); >> strcat(fullname, " "); >> strcat(fullname, lastname); >> >> which one will execute faster? Which when we start making the >> names extremely long? > > The C++ won't compile (not even with a C++ compiler), so that definitely > loses, but the C code could hardly be said to be written for speed. So > they both lose to a customised function that doesn't lose track of the > place to start writing the appended string. This is the point: you can't always spend time writing these things for speed or to craft highly customised routines. (And maybe 5 minutes later the you decide to change the requirements.) The use of counted strings automatically gives you an advantage with much less effort. Suppose you had to create a function 'stradd3(dest, a,b,c)' which returns a+b+c in dest; no length info is available (except perhaps the capacity of dest, but then making use of that will slow things down). I've made such a test function, which uses strcpy/strcat, and ran it 10M times with strings of length 175, 63 and 235 characters. And tested it in a few languages. I managed to get an /interpreted/ version outperforming any C compiler version, up to gcc -O2 (not gcc -O3, but the test was after just all a simple loop). Still, interpreted bytecode was faster than, for example, Clang -O3, thanks to the use of counted strings. (I subsequently added pre-determined string lengths to stradd3(), and all C versions were then faster than the bytecode, even unoptimised.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-01 11:36 +0100 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <muj289$shv$2@dont-email.me> |
| In reply to | #71531 |
On 01/10/15 11:15, Bartc wrote: > On 01/10/2015 03:12, Richard Heathfield wrote: >> On 01/10/15 03:02, Malcolm McLean wrote: > >>> strcpy(firstname, "Fred"); >>> strcpy(lastname, "Bloggs"); >>> strcpy(fullname, firstname); >>> strcat(fullname, " "); >>> strcat(fullname, lastname); >>> >>> which one will execute faster? Which when we start making the >>> names extremely long? >> >> The C++ won't compile (not even with a C++ compiler), so that definitely >> loses, but the C code could hardly be said to be written for speed. So >> they both lose to a customised function that doesn't lose track of the >> place to start writing the appended string. > > This is the point: you can't always spend time writing these things for > speed or to craft highly customised routines. (And maybe 5 minutes later > the you decide to change the requirements.) Very true, but Malcolm was specifically asking which solution is the fastest, which strongly suggests that he was concerned primarily about performance. <snip> -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-01 05:49 -0700 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <9e3eef80-1654-43e1-b223-2d990f9d6a0c@googlegroups.com> |
| In reply to | #71532 |
On Thursday, October 1, 2015 at 11:36:57 AM UTC+1, Richard Heathfield wrote: > > Very true, but Malcolm was specifically asking which solution is the > fastest, which strongly suggests that he was concerned primarily about > performance. > Exactly. The counted string is a more complicated object than the C string, so whilst it avoids the inefficiency of recounting the same string three times to produce the concatenation, the advantage is mainly lost because it's doing dynamic memory allocation and freeing to construct and tear down the objects. You can object that that makes the comparison unfair, but it's not really - the class is the obvious and sensible way to attach a length field to a string, just as the C is the obvious and sensible way to construct a short string holding a name (the initialisations are unrealistic because it's a code fragment, in reality the name would be read in from a database somewhere).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-01 16:41 +0200 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <mujgip$l0q$1@dont-email.me> |
| In reply to | #71533 |
On 01/10/15 14:49, Malcolm McLean wrote: > On Thursday, October 1, 2015 at 11:36:57 AM UTC+1, Richard Heathfield wrote: >> >> Very true, but Malcolm was specifically asking which solution is the >> fastest, which strongly suggests that he was concerned primarily about >> performance. >> > Exactly. > The counted string is a more complicated object than the C string, so whilst it > avoids the inefficiency of recounting the same string three times to produce > the concatenation, the advantage is mainly lost because it's doing dynamic > memory allocation and freeing to construct and tear down the objects. > You can object that that makes the comparison unfair, but it's not really - > the class is the obvious and sensible way to attach a length field to a string, > just as the C is the obvious and sensible way to construct a short string > holding a name (the initialisations are unrealistic because it's a code fragment, > in reality the name would be read in from a database somewhere). > The comparison you gave is /clearly/ misleading. If you want to use strings with fixed maximum lengths, such as you are doing in the C code, then you can do it just as well in a C++ class. And if you want to use dynamic allocation for your strings in the C++ class, then you should do so in the C code too. Doing a test with that fixed, you would probably find that with similar requirements here the code speed would be quite similar between a counted length string class and an uncounted C string - because the compiler can optimise the strcpy and strcat calls knowing that you can use the length counts (or end pointer) from one call to make the next one faster.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-01 15:16 +1300 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <d73jc0Fqr3pU31@mid.individual.net> |
| In reply to | #71517 |
Malcolm McLean wrote: > On Wednesday, September 30, 2015 at 9:23:51 PM UTC+1, Ian Collins wrote: >> Malcolm McLean wrote: >> >>> Every man and his dog knocked up a string class in the early days >>> of C++. It's easy enough. Just attach an integer to the string >>> length, overload the array subscript operator and the addition operator, >>> and you've achieved a fast and safe strcat. >>> Except that you're almost certainly allocating memory, so unless >>> your strings are huge, concatenation is likely slower than with >>> strcat(). >> >> Eh? The cost would be the same under the condition where strcat() is >> safe (the buffer is large enough for both). >> <snip> > which one will execute faster? Which when we start making the > names extremely long? You are comparing apples with prawns. I said under the condition where the buffer is large enough for both parts of the string. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-09-30 19:10 -0700 |
| Subject | Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <49873309-8be7-4b58-9209-cf34a09f5612@googlegroups.com> |
| In reply to | #71500 |
On Wednesday, September 30, 2015 at 9:23:51 PM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > On Wednesday, September 30, 2015 at 5:34:22 PM UTC+1, Bart wrote: > >> > >> Every program, language and interface would use its own incompatible > >> scheme. And a scheme that satisfies everyone would probably have > >> unacceptable overheads. And/or you wouldn't just be able to copy a > >> struct containing a flat char[] array to another struct. > >> > > That's the real problem. > > Every man and his dog knocked up a string class in the early days > > of C++. It's easy enough. Just attach an integer to the string > > length, overload the array subscript operator and the addition operator, > > and you've achieved a fast and safe strcat. > > Except that you're almost certainly allocating memory, so unless > > your strings are huge, concatenation is likely slower than with > > strcat(). > > Eh? The cost would be the same under the condition where strcat() is > safe (the buffer is large enough for both). > > > But no library will accept class mystring. You've got to have > > a common language for communicating string data between different > > parts of the program. > > Which is why the C++ standard library has strings. > And they thoughtfully allowed you to specify the underlying character type. So you can use 16 bit unicode strings if you want. But the standard for communicating string data is UTF-8. It's the single most common encoding, and its gaining popularity all the time. And there's no easy way of coaxing a C++ standard string into UTF-8, though of course UTF-8 is so well designed that you can use a UTF-8 naive string almost anywhere. So it's back to mystring classes. That's a snag with O-O programming. It promises flexibility and backwards compatibility, but it doesn't really deliver, it's not tolerant of what, in hindsight, were poor design decisions.
[toc] | [prev] | [next] | [standalone]
Page 16 of 17 — ← Prev page 1 … 14 15 [16] 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web