Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #35286 > unrolled thread
| Started by | Raj Pashwar <raj121190@hotmail.NOSPAM.com> |
|---|---|
| First post | 2013-08-13 18:43 +0000 |
| Last post | 2013-08-14 16:03 -0400 |
| Articles | 20 on this page of 232 — 24 participants |
Back to article view | Back to comp.lang.c
size of Raj Pashwar <raj121190@hotmail.NOSPAM.com> - 2013-08-13 18:43 +0000
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-13 13:46 -0500
Re: size of Raj Pashwar <raj121190@hotmail.NOSPAM.com> - 2013-08-16 22:06 +0000
Re: size of Azazel <azazel@remove.azazel.net> - 2013-08-16 17:32 -0500
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-16 18:10 -0500
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-16 17:11 -0700
Re: size of Raj Pashwar <raj121190@hotmail.NOSPAM.com> - 2013-08-17 09:11 +0000
Re: size of Shao Miller <sha0.miller@gmail.com> - 2013-08-17 05:38 -0400
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-17 09:00 -0400
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-16 21:43 -0400
Re: size of Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-16 22:36 -0400
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-17 03:08 -0700
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-17 08:57 -0400
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-17 13:35 -0700
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-17 15:17 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-17 17:06 -0700
Re: size of Richard Damon <Richard@Damon-Family.org> - 2013-08-17 18:27 -0400
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-21 00:29 -0700
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-21 02:03 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-23 10:27 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-23 10:38 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-24 17:25 -0700
Re: size of Kelsey Bjarnason <kbjarnason@gmail.com> - 2013-08-26 20:20 -0700
Re: size of gazelle@shell.xmission.com (Kenny McCormack) - 2013-08-21 16:05 +0000
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-23 10:26 -0700
Re: size of Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-21 12:20 -0600
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-13 11:50 -0700
Re: size of Ike Naar <ike@iceland.freeshell.org> - 2013-08-13 21:52 +0000
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-13 15:49 -0700
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-14 08:22 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-14 10:38 -0700
Re: size of Kelsey Bjarnason <kbjarnason@gmail.com> - 2013-08-14 20:20 +0000
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-14 14:57 -0700
Re: size of Ken Brody <kenbrody@spamcop.net> - 2013-08-15 10:14 -0400
Re: size of Azazel <azazel@remove.azazel.net> - 2013-08-15 10:11 -0500
Re: size of Ken Brody <kenbrody@spamcop.net> - 2013-08-16 13:13 -0400
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-15 08:54 -0700
Re: size of Kelsey Bjarnason <kbjarnason@gmail.com> - 2013-08-16 16:03 +0000
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-16 14:36 -0700
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-16 17:42 -0400
Re: size of Kelsey Bjarnason <kbjarnason@gmail.com> - 2013-08-17 04:50 +0000
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-17 03:21 -0700
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-17 09:33 -0500
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-17 07:58 -0700
Re: size of Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-17 20:17 +0100
Re: size of Rosario1903 <Rosario@invalid.invalid> - 2013-08-18 09:22 +0200
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-19 20:42 -0500
Re: size of Rosario1903 <Rosario@invalid.invalid> - 2013-08-20 09:03 +0200
Re: size of Rosario1903 <Rosario@invalid.invalid> - 2013-08-20 09:06 +0200
Re: size of Ian Collins <ian-news@hotmail.com> - 2013-08-20 20:49 +1200
Re: size of Rosario1903 <Rosario@invalid.invalid> - 2013-08-20 10:57 +0200
Re: size of Rosario1903 <Rosario@invalid.invalid> - 2013-08-20 12:40 +0200
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-20 07:58 -0500
Re: size of Rosario1903 <Rosario@invalid.invalid> - 2013-08-20 18:27 +0200
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-20 12:27 -0500
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-20 12:20 -0700
Re: size of Ike Naar <ike@iceland.freeshell.org> - 2013-08-20 21:02 +0000
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-20 16:10 -0700
Re: size of Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-23 10:50 +0300
Re: size of Rosario1903 <Rosario@invalid.invalid> - 2013-08-21 07:39 +0200
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-22 13:15 -0500
Re: size of Barry Schwarz <schwarzb@dqel.com> - 2013-08-20 15:17 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-20 16:18 -0700
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-20 20:47 -0500
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-20 23:31 -0400
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-20 23:38 -0500
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-21 07:01 -0400
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-22 21:54 -0500
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-23 00:26 -0400
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-24 04:45 -0500
Re: size of Richard Damon <Richard@Damon-Family.org> - 2013-08-24 08:55 -0400
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-24 11:54 -0500
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-24 13:27 -0400
Re: size of Robert Wessel <robertwessel2@yahoo.com> - 2013-08-24 14:12 -0500
Re: size of Richard Damon <Richard@Damon-Family.org> - 2013-08-24 18:01 -0400
Re: size of glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-26 01:46 +0000
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-24 13:23 -0400
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-24 14:33 -0500
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-24 22:47 -0400
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-25 04:34 -0500
Re: size of glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-26 01:49 +0000
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-21 09:04 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-20 23:07 -0700
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-21 07:06 -0400
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-21 09:06 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-20 23:03 -0700
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-22 13:34 -0500
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-22 15:06 -0400
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-22 14:42 -0500
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-22 12:40 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-22 14:57 -0700
Re: size of Robert Wessel <robertwessel2@yahoo.com> - 2013-08-22 20:30 -0500
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-22 22:24 -0400
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-22 21:42 -0500
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-23 00:10 -0400
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-22 21:36 -0500
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-24 14:53 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-22 23:30 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-24 10:48 -0700
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-24 14:23 -0500
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-24 15:42 -0700
Re: size of Richard Damon <Richard@Damon-Family.org> - 2013-08-24 20:09 -0400
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-24 17:52 -0700
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-24 22:53 -0400
Re: size of Richard Damon <Richard@Damon-Family.org> - 2013-08-25 08:44 -0400
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-26 14:27 -0700
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-26 15:35 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-26 16:08 -0700
Re: size of Robert Wessel <robertwessel2@yahoo.com> - 2013-08-27 12:29 -0500
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-27 10:45 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-27 14:46 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-29 02:10 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-29 11:38 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-09-01 09:43 -0700
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-09-01 16:14 -0700
Re: size of Ian Collins <ian-news@hotmail.com> - 2013-09-02 11:42 +1200
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-09-01 20:32 -0400
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-09-03 08:13 -0700
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-09-03 08:31 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-09-22 10:35 -0700
Re: size of Richard Damon <Richard@Damon-Family.org> - 2013-08-26 23:48 -0400
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-26 21:50 -0700
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-27 06:46 -0400
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-27 08:39 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-28 14:10 -0700
Re: size of glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-28 21:46 +0000
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-29 10:15 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-28 17:09 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-29 10:43 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-25 10:49 -0700
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-25 11:15 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-24 14:39 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-25 18:32 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-25 19:48 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-27 01:19 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-27 12:34 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-21 00:19 -0700
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-20 18:28 -0500
Re: size of Barry Schwarz <schwarzb@dqel.com> - 2013-08-20 22:02 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-20 23:13 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-24 08:48 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-24 14:12 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-24 20:35 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-24 09:16 -0700
Re: size of Barry Schwarz <schwarzb@dqel.com> - 2013-08-24 15:14 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-24 15:51 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-24 19:39 -0700
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-24 11:48 -0500
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-24 13:36 -0400
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-24 14:24 -0500
Re: size of Barry Schwarz <schwarzb@dqel.com> - 2013-08-24 15:14 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-24 15:46 -0700
Re: size of Barry Schwarz <schwarzb@dqel.com> - 2013-08-24 21:42 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-25 01:41 -0700
Re: size of Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-25 13:46 -0600
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-25 13:33 -0700
Re: size of Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-25 18:18 -0600
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-26 18:27 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-26 21:21 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-27 00:55 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-27 08:27 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-26 18:43 -0700
Re: size of Richard Damon <Richard@Damon-Family.org> - 2013-08-25 16:52 -0400
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-25 18:34 -0400
Re: size of Barry Schwarz <schwarzb@dqel.com> - 2013-08-25 16:20 -0700
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-25 21:01 -0400
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-25 19:33 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-26 23:36 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-27 09:15 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-29 00:36 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-29 11:27 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-31 21:42 -0700
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-24 23:08 -0400
Re: size of Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-25 13:44 -0600
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-25 13:31 -0700
Re: size of Barry Schwarz <schwarzb@dqel.com> - 2013-08-25 16:20 -0700
Re: size of Richard Damon <Richard@Damon-Family.org> - 2013-08-25 21:48 -0400
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-25 19:30 -0700
Re: size of Ian Collins <ian-news@hotmail.com> - 2013-08-26 14:45 +1200
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-25 20:08 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-26 18:53 -0700
Re: size of Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-26 22:08 -0600
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-26 23:13 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-27 08:47 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-28 23:54 -0700
Re: size of Rosario1903 <Rosario@invalid.invalid> - 2013-08-27 09:18 +0200
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-29 09:46 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-24 15:08 -0700
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-24 16:39 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-24 17:48 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-24 17:55 -0700
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-20 01:02 -0700
Re: size of Ian Collins <ian-news@hotmail.com> - 2013-08-20 20:54 +1200
Re: size of Kelsey Bjarnason <kbjarnason@gmail.com> - 2013-08-20 02:39 -0700
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-20 08:15 -0500
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-20 08:17 -0700
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-20 13:58 -0700
Re: size of Ike Naar <ike@iceland.freeshell.org> - 2013-08-20 21:11 +0000
Re: size of gazelle@shell.xmission.com (Kenny McCormack) - 2013-08-20 21:21 +0000
Re: size of Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-20 16:21 -0600
Re: size of gazelle@shell.xmission.com (Kenny McCormack) - 2013-08-21 12:01 +0000
Re: size of Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-21 12:11 -0600
Re: size of gazelle@shell.xmission.com (Kenny McCormack) - 2013-08-22 09:19 +0000
Re: size of Ian Collins <ian-news@hotmail.com> - 2013-08-21 10:07 +1200
Re: size of glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-20 23:58 +0000
Re: size of Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-23 11:24 +0300
Re: size of glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-23 10:52 +0000
Re: size of "James Harris" <james.harris.1@gmail.com> - 2013-08-23 12:09 +0100
Re: size of Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-08-23 17:52 +0300
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-20 16:21 -0700
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-21 02:23 -0700
Re: size of glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-21 10:05 +0000
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-21 03:23 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-21 08:22 -0700
Re: size of Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-08-21 18:54 +0100
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-21 13:51 -0700
Re: size of Robert Wessel <robertwessel2@yahoo.com> - 2013-08-21 13:41 -0500
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-21 08:42 -0700
Re: size of Kelsey Bjarnason <kbjarnason@gmail.com> - 2013-08-20 20:44 -0700
Re: size of Malcolm McLean <malcolm.mclean5@btinternet.com> - 2013-08-21 02:30 -0700
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-21 08:30 -0700
Re: size of Kelsey Bjarnason <kbjarnason@gmail.com> - 2013-08-18 22:15 -0700
Re: size of Kelsey Bjarnason <kbjarnason@gmail.com> - 2013-08-18 22:08 -0700
Re: size of Tim Rentsch <txr@alumni.caltech.edu> - 2013-08-18 20:49 -0700
Re: size of Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2013-08-14 01:09 +0200
Re: size of Keith Thompson <kst-u@mib.org> - 2013-08-13 17:31 -0700
Re: size of Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-13 22:09 -0600
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-14 07:03 -0400
Re: size of Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-14 10:02 -0600
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-14 12:29 -0400
Re: size of Stephen Sprunk <stephen@sprunk.org> - 2013-08-14 14:44 -0500
Re: size of James Kuyper <jameskuyper@verizon.net> - 2013-08-14 16:03 -0400
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
| From | Kelsey Bjarnason <kbjarnason@gmail.com> |
|---|---|
| Date | 2013-08-17 04:50 +0000 |
| Message-ID | <kumve5$odv$2@dont-email.me> |
| In reply to | #35390 |
On Fri, 16 Aug 2013 14:36:33 -0700, Malcolm McLean wrote:
> On Friday, August 16, 2013 5:03:28 PM UTC+1, Kelsey Bjarnason wrote:
>> On Thu, 15 Aug 2013 08:54:53 -0700, Malcolm McLean wrote:
>>
>> > So size_t imagesize;
>> > size_t rasterbytes;
>> > size_t i;
>>
>>
>> > loadimage( ..., &imagesize);
>> > rasterbytes = imagesize - sizeof(ImageHeader);
>>
>> > for(i=0;i<rasterbytes;i++)
>> > printf("rasterbyte %z is %02x\n", i, image[sizeof(ImageHeader) +
>> > i]);
>>
>> > All reasonable?
>>
>>
>> Well, let's see. No idea what "loadimage" does, say, in cases of
>> failure or where the image is in fact larger than the capacity of a
>> size_t to represent (16-bit implementations, multi-gig images?).
>>
> Well if imagesize is a positive integer, and the function is correctly
> written, then you can assume that an object of that size has been
> successfully loaded into memory.
In which case, if you're using an int or an unsigned int, rather than a
size_t to handle sizes, you're creating failure conditions when the size
exceeds the bounds of your integer type, which should have been size_t.
> I agree that use of a size_t makes it difficult to distinguish the error
> case from the empty case. Some OSs do allow files of length zero.
Improper code design is not an argument against size_t, it's an argument
against writing code that way.
>> Okay, so, it looks to me like poor error handling plus poor evaluation
>> of loop indexes. What has that got to do with some bizarre argument
>> about not using size_t for sizes?
>>
> What happens if we use an int instead?
>
> If this was real code, what environment would you expect to see it in?
None whatsoever, ideally. Not unless it is backed by a largish set of
fundamental requirements, none of which are thus far documented here,
which would render the issues raised moot or largely so.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-17 03:21 -0700 |
| Message-ID | <cf16255e-047c-4940-9ff6-3d42d4377f32@googlegroups.com> |
| In reply to | #35400 |
On Saturday, August 17, 2013 5:50:14 AM UTC+1, Kelsey Bjarnason wrote: > On Fri, 16 Aug 2013 14:36:33 -0700, Malcolm McLean wrote: > > > Well if imagesize is a positive integer, and the function is correctly > > written, then you can assume that an object of that size has been > > successfully loaded into memory. > > In which case, if you're using an int or an unsigned int, rather than a > size_t to handle sizes, you're creating failure conditions when the size > exceeds the bounds of your integer type, which should have been size_t. > int should be the natural integer size for the machine. Usually we can live with the fact that it can only index 2GB of memory. Since it's signed, a decent platform can give an overflow error if we attempt to assign a result with is too large to one. Because of a quirk in the C standard, this isn't allowed for a size_t. So if loadimage() contains a loop like while( (ch = fgetc(fp)) ! EOF) N++; N must wrap on overflow. It's not allowed to behave any differently. > > > I agree that use of a size_t makes it difficult to distinguish the error > > case from the empty case. Some OSs do allow files of length zero. > > Improper code design is not an argument against size_t, it's an argument > against writing code that way. > If a language is Turing equivalent than, by definition, it's possible to write correct programs in that language. That doesn't shut down all discussions about possible errors that a human programmer is likely to introduce, because of badly designed features. > > > If this was real code, what environment would you expect to see it in? > > None whatsoever, ideally. Not unless it is backed by a largish set of > fundamental requirements, none of which are thus far documented here, > which would render the issues raised moot or largely so. > It would be running in a casual debug/ testing environment. You can't document and acceptance test all your testing code, or you create an infinite regression. So it's very likely that loadimage() has an error, and is being debugged. That's why someone wants to print out the raster bytes. So it's not a stretch to suppose that the size it returns is actually less than the size of the header.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2013-08-17 09:33 -0500 |
| Message-ID | <kuo1kf$5sk$1@dont-email.me> |
| In reply to | #35409 |
On 17-Aug-13 05:21, Malcolm McLean wrote: > On Saturday, August 17, 2013 5:50:14 AM UTC+1, Kelsey Bjarnason > wrote: >> In which case, if you're using an int or an unsigned int, rather >> than a size_t to handle sizes, you're creating failure conditions >> when the size exceeds the bounds of your integer type, which should >> have been size_t. > > int should be the natural integer size for the machine. Usually we > can live with the fact that it can only index 2GB of memory. int is not guaranteed to be able to index more than 64kB of memory, which is hardly sufficient for modern purposes. Even a 2GB limit frequently causes problems these days. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2013-08-17 07:58 -0700 |
| Message-ID | <d87d7290-75b8-49b9-9c2e-2a5ece72bc4f@googlegroups.com> |
| In reply to | #35417 |
On Saturday, August 17, 2013 3:33:53 PM UTC+1, Stephen Sprunk wrote: > On 17-Aug-13 05:21, Malcolm McLean wrote: > > int is not guaranteed to be able to index more than 64kB of memory, > which is hardly sufficient for modern purposes. Even a 2GB limit > frequently causes problems these days. > int should be the natural integer size for the machine. This policy was followed as machines moved from 16 bit to 32 bit, and int became 32 bits. 16 bit machines still exist, but they demand convolutions to support objects bigger than 64K, if they support them at all, so it's reasonable to say that a special index type must be used if you're doing this. Unfortunately int often isn't 64 bits on a 64 bit machine. So it's a bit of a problem, because number of times you have more than 2 billion entities is quite small, but not small enough to be negligible. So usually we can use int i as a general-purpose index, but not always. Which causes problems when trying to write clean code.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-08-17 20:17 +0100 |
| Message-ID | <0.3bc4e5b59d8aba8baf76.20130817201738BST.878v00yvn1.fsf@bsb.me.uk> |
| In reply to | #35418 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, August 17, 2013 3:33:53 PM UTC+1, Stephen Sprunk wrote: >> On 17-Aug-13 05:21, Malcolm McLean wrote: >> >> int is not guaranteed to be able to index more than 64kB of memory, >> which is hardly sufficient for modern purposes. Even a 2GB limit >> frequently causes problems these days. >> > int should be the natural integer size for the machine. This policy was > followed as machines moved from 16 bit to 32 bit, and int became 32 bits. > 16 bit machines still exist, but they demand convolutions to support objects > bigger than 64K, if they support them at all, so it's reasonable to say > that a special index type must be used if you're doing this. > > Unfortunately int often isn't 64 bits on a 64 bit machine. So it's a bit > of a problem, because number of times you have more than 2 billion entities > is quite small, but not small enough to be negligible. > So usually we can use int i as a general-purpose index, but not always. Which > causes problems when trying to write clean code. However, one /can/ use size_t as a general-purpose index. I understand you don't like the semantics of unsigned types in C, but you have not made a good case that the code you get when you use them is "unclean". -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Rosario1903 <Rosario@invalid.invalid> |
|---|---|
| Date | 2013-08-18 09:22 +0200 |
| Message-ID | <48t019dko1ojs30p06g5kmcu86gs2392ue@4ax.com> |
| In reply to | #35418 |
On Sat, 17 Aug 2013 07:58:15 -0700 (PDT), Malcolm McLean
<malcolm.mclean5@btinternet.com> wrote:
>On Saturday, August 17, 2013 3:33:53 PM UTC+1, Stephen Sprunk wrote:
>> On 17-Aug-13 05:21, Malcolm McLean wrote:
>>
>> int is not guaranteed to be able to index more than 64kB of memory,
>> which is hardly sufficient for modern purposes. Even a 2GB limit
>> frequently causes problems these days.
>>
>int should be the natural integer size for the machine. This policy was
>followed as machines moved from 16 bit to 32 bit, and int became 32 bits.
>16 bit machines still exist, but they demand convolutions to support objects
>bigger than 64K, if they support them at all, so it's reasonable to say
>that a special index type must be used if you're doing this.
>
>Unfortunately int often isn't 64 bits on a 64 bit machine. So it's a bit
>of a problem, because number of times you have more than 2 billion entities
>is quite small, but not small enough to be negligible.
>So usually we can use int i as a general-purpose index, but not always. Which
>causes problems when trying to write clean code.
i would do something as:
uint64_t i, len;
uint8_t *p;
/*
if big array
if sys is not able to address array of len of a number
of 64 bit stop
*/
if(sizeof(size_t)*CHAR_BIT< 64)
error();
len=f();
/* suppose malloc(u64 ) */
p=malloc(len * sizeof *p);
for(i=0; i<len; ++i)
p[i]=0;
for me size_t cold be useful only to see if machine can
address 64 bit array
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2013-08-19 20:42 -0500 |
| Message-ID | <kuuhhs$3p8$1@dont-email.me> |
| In reply to | #35435 |
On 18-Aug-13 02:22, Rosario1903 wrote: > i would do something as: > ... > /* > if big array > if sys is not able to address array of len of a number > of 64 bit stop > */ > > if(sizeof(size_t)*CHAR_BIT< 64) > error(); > ... > for me size_t cold be useful only to see if machine can > address 64 bit array Why not just always use size_t and let the compiler take care of ensuring it's large enough to index the largest arrays that the implementation can create--be that 16, 32, 64 or some other number of bits? Why insist on a 64-bit size_t, for instance, if the implementation you're compiling on doesn't support arrays larger than 2GB anyway? S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Rosario1903 <Rosario@invalid.invalid> |
|---|---|
| Date | 2013-08-20 09:03 +0200 |
| Message-ID | <7k4619p1h7o1j3sbcokgeaa7f9mt8g1s7c@4ax.com> |
| In reply to | #35480 |
On Mon, 19 Aug 2013 20:42:19 -0500, Stephen Sprunk
<stephen@sprunk.org> wrote:
>On 18-Aug-13 02:22, Rosario1903 wrote:
>> i would do something as:
>> ...
>> /*
>> if big array
>> if sys is not able to address array of len of a number
>> of 64 bit stop
>> */
>>
>> if(sizeof(size_t)*CHAR_BIT< 64)
>> error();
>> ...
>> for me size_t cold be useful only to see if machine can
>> address 64 bit array
>
>Why not just always use size_t and let the compiler take care of
>ensuring it's large enough to index the largest arrays that the
>implementation can create--be that 16, 32, 64 or some other number of bits?
in my vew, i not would use size_t because i don't know the value
sizeof(size_t)*CHAR_BIT
because each machine can be one different value and so UBs
>Why insist on a 64-bit size_t, for instance, if the implementation
>you're compiling on doesn't support arrays larger than 2GB anyway?
because Malcolm said:
"Unfortunately int often isn't 64 bits on a 64 bit machine. So it's a
bit
of a problem, because number of times you have more than 2 billion
entities
is quite small, but *not small enough to be negligible*."
where i wrote the 2 *
yes 64 could be oo much possible sizeof(size_t)== 40 bit etc
but it seem odd..
the code i post is a little sloppy the code i mean is this:
uint64_t i, len;
uint8_t *p;
len=f();
if(len > SIZE_TMAX) goto error()
p=malloc( len );
for(i=0; i<len; ++i)
p[i]=0;
>S
[toc] | [prev] | [next] | [standalone]
| From | Rosario1903 <Rosario@invalid.invalid> |
|---|---|
| Date | 2013-08-20 09:06 +0200 |
| Message-ID | <l75619t8vjsvfd09pkb3utflurfn6p2f1c@4ax.com> |
| In reply to | #35483 |
On Tue, 20 Aug 2013 09:03:05 +0200, Rosario1903 <Rosario@invalid.invalid> wrote: >yes 64 could be oo much possible sizeof(size_t)== 40 bit etc >but it seem odd.. yes 64 bit could be too much; possible size_t is 40 bit but that number seems to me odd or ridiculus
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2013-08-20 20:49 +1200 |
| Message-ID | <b7got6Fg6sqU7@mid.individual.net> |
| In reply to | #35483 |
Rosario1903 wrote: > On Mon, 19 Aug 2013 20:42:19 -0500, Stephen Sprunk > <stephen@sprunk.org> wrote: > >> On 18-Aug-13 02:22, Rosario1903 wrote: >>> i would do something as: >>> ... >>> /* >>> if big array >>> if sys is not able to address array of len of a number >>> of 64 bit stop >>> */ >>> >>> if(sizeof(size_t)*CHAR_BIT< 64) >>> error(); >>> ... >>> for me size_t cold be useful only to see if machine can >>> address 64 bit array >> >> Why not just always use size_t and let the compiler take care of >> ensuring it's large enough to index the largest arrays that the >> implementation can create--be that 16, 32, 64 or some other number of bits? > > in my vew, i not would use size_t because i don't know the value > sizeof(size_t)*CHAR_BIT > because each machine can be one different value That's the point. What's the use of a 64 bit size_t on a 16 bit machine? > and so UBs Where? >> Why insist on a 64-bit size_t, for instance, if the implementation >> you're compiling on doesn't support arrays larger than 2GB anyway? > > because Malcolm said: > "Unfortunately int often isn't 64 bits on a 64 bit machine. So it's a > bit > of a problem, because number of times you have more than 2 billion > entities > is quite small, but *not small enough to be negligible*." > > where i wrote the 2 * He's talking about int, not size_t. > yes 64 could be oo much possible sizeof(size_t)== 40 bit etc > but it seem odd.. > the code i post is a little sloppy the code i mean is this: > > uint64_t i, len; > uint8_t *p; > > len=f(); > > if(len > SIZE_TMAX) goto error() How can a value be bigger than its maximum value? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Rosario1903 <Rosario@invalid.invalid> |
|---|---|
| Date | 2013-08-20 10:57 +0200 |
| Message-ID | <opb619tjk23qus35292uo9kii1d5b23t3p@4ax.com> |
| In reply to | #35487 |
On Tue, 20 Aug 2013 20:49:42 +1200, Ian Collins <ian-news@hotmail.com> wrote: >Rosario1903 wrote: >> On Mon, 19 Aug 2013 20:42:19 -0500, Stephen Sprunk >> <stephen@sprunk.org> wrote: >> >>> On 18-Aug-13 02:22, Rosario1903 wrote: >>>> i would do something as: >> yes 64 could be oo much possible sizeof(size_t)== 40 bit etc >> but it seem odd.. >> the code i post is a little sloppy the code i mean is this: >> >> uint64_t i, len; >> uint8_t *p; >> >> len=f(); >> >> if(len > SIZE_TMAX) goto error() > >How can a value be bigger than its maximum value? if size_t is 32 bit, than len can be > size_t_max...
[toc] | [prev] | [next] | [standalone]
| From | Rosario1903 <Rosario@invalid.invalid> |
|---|---|
| Date | 2013-08-20 12:40 +0200 |
| Message-ID | <hrh619l28gk8f1m9evpplki1ravfvg4nar@4ax.com> |
| In reply to | #35483 |
On Tue, 20 Aug 2013 09:03:05 +0200, Rosario1903 <Rosario@invalid.invalid> wrote: >uint64_t i, len; >uint8_t *p; > >len=f(); > >if(len > SIZE_TMAX) goto error() > >p=malloc( len ); i forget if(p==0) error() >for(i=0; i<len; ++i) > p[i]=0; > > >>S
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2013-08-20 07:58 -0500 |
| Message-ID | <kuvp69$fjh$1@dont-email.me> |
| In reply to | #35483 |
On 20-Aug-13 02:03, Rosario1903 wrote: > On Mon, 19 Aug 2013 20:42:19 -0500, Stephen Sprunk > <stephen@sprunk.org> wrote: >> On 18-Aug-13 02:22, Rosario1903 wrote: >>> i would do something as: >>> ... >>> /* >>> if big array >>> if sys is not able to address array of len of a number >>> of 64 bit stop >>> */ >>> >>> if(sizeof(size_t)*CHAR_BIT< 64) >>> error(); >>> ... >>> for me size_t cold be useful only to see if machine can >>> address 64 bit array >> >> Why not just always use size_t and let the compiler take care of >> ensuring it's large enough to index the largest arrays that the >> implementation can create--be that 16, 32, 64 or some other number >> of bits? > > in my vew, i not would use size_t because i don't know the value > sizeof(size_t)*CHAR_BIT because each machine can be one different > value and so UBs It's not undefined, it's implementation-defined. You don't actually _need_ to know how many bits are in a size_t; all that you need to know is that it's guaranteed to be large enough to index any array that the implementation is capable of creating. For instance, if size_t is only 32 bits on a given implementation, then that means that implementation is not capable of creating an array larger than 4G elements. >> Why insist on a 64-bit size_t, for instance, if the implementation >> you're compiling on doesn't support arrays larger than 2GB anyway? > > because Malcolm said: > "Unfortunately int often isn't 64 bits on a 64 bit machine. So it's > a bit of a problem, because number of times you have more than 2 > billion entities is quite small, but *not small enough to be > negligible*." That's an argument against using int to index arrays, not against using size_t. In fact, that exact problem is why size_t was created! > where i wrote the 2 * > > yes 64 could be oo much possible sizeof(size_t)== 40 bit etc > but it seem odd.. > the code i post is a little sloppy the code i mean is this: > > uint64_t i, len; > uint8_t *p; > > len=f(); > > if(len > SIZE_TMAX) goto error() > > p=malloc( len ); > > for(i=0; i<len; ++i) > p[i]=0; That code does not do what you think it does. The argument to malloc() is itself a size_t, which means you cannot pass it a larger value than SIZE_MAX in the first place. If you try to cram a larger value into len, because it's a unit64_t, it may appear to work but a much smaller object will actually be created, which will cause your indexing to fail at some point. Consider what this code will do when you try to allocate (and then index) an 8GB array on a system that is incapable of creating an object larger than 32767 bytes, which likely means it has a 16-bit size_t. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Rosario1903 <Rosario@invalid.invalid> |
|---|---|
| Date | 2013-08-20 18:27 +0200 |
| Message-ID | <7r57195e8narse0k253g7p0f6mul4knqeb@4ax.com> |
| In reply to | #35500 |
On Tue, 20 Aug 2013 07:58:48 -0500, Stephen Sprunk
<stephen@sprunk.org> wrote:
>On 20-Aug-13 02:03, Rosario1903 wrote:
>> On Mon, 19 Aug 2013 20:42:19 -0500, Stephen Sprunk
>> <stephen@sprunk.org> wrote:
>>> On 18-Aug-13 02:22, Rosario1903 wrote:
>>>> i would do something as:
>>>> ...
>>>> /*
>>>> if big array
>>>> if sys is not able to address array of len of a number
>>>> of 64 bit stop
>>>> */
>>>>
>>>> if(sizeof(size_t)*CHAR_BIT< 64)
>>>> error();
>>>> ...
>>>> for me size_t cold be useful only to see if machine can
>>>> address 64 bit array
>>>
>>> Why not just always use size_t and let the compiler take care of
>>> ensuring it's large enough to index the largest arrays that the
>>> implementation can create--be that 16, 32, 64 or some other number
>>> of bits?
>>
>> in my vew, i not would use size_t because i don't know the value
>> sizeof(size_t)*CHAR_BIT because each machine can be one different
>> value and so UBs
>
>It's not undefined, it's implementation-defined.
>
>You don't actually _need_ to know how many bits are in a size_t; all
>that you need to know is that it's guaranteed to be large enough to
>index any array that the implementation is capable of creating.
>
>For instance, if size_t is only 32 bits on a given implementation, then
>that means that implementation is not capable of creating an array
>larger than 4G elements.
>
>>> Why insist on a 64-bit size_t, for instance, if the implementation
>>> you're compiling on doesn't support arrays larger than 2GB anyway?
>>
>> because Malcolm said:
>> "Unfortunately int often isn't 64 bits on a 64 bit machine. So it's
>> a bit of a problem, because number of times you have more than 2
>> billion entities is quite small, but *not small enough to be
>> negligible*."
>
>That's an argument against using int to index arrays, not against using
>size_t. In fact, that exact problem is why size_t was created!
>
>> where i wrote the 2 *
>>
>> yes 64 could be oo much possible sizeof(size_t)== 40 bit etc
>> but it seem odd..
>> the code i post is a little sloppy the code i mean is this:
>>
>> uint64_t i, len;
>> uint8_t *p;
>>
>> len=f();
>>
>> if(len > SIZE_TMAX) goto error()
>>
>> p=malloc( len );
>>
>> for(i=0; i<len; ++i)
>> p[i]=0;
>
>That code does not do what you think it does. The argument to malloc()
>is itself a size_t, which means you cannot pass it a larger value than
>SIZE_MAX in the first place. If you try to cram a larger value into
>len, because it's a unit64_t, it may appear to work but a much smaller
>object will actually be created, which will cause your indexing to fail
>at some point.
if "void* malloc(size_t r)"
if len > SIZE_MAX the program goes in error,
if len <= SIZE_MAX
than "len" goes to conversion to size_t,
if size_t is unsigned can not be a problem
>Consider what this code will do when you try to allocate (and then
>index) an 8GB array on a system that is incapable of creating an object
>larger than 32767 bytes,
in that sys
len=0xFFFFFFFFFFFF;
if(len>SIZE_MAX) goto error;
there is goto error... becaues SIZE_MAX==32767
>which likely means it has a 16-bit size_t.
>
>S
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2013-08-20 12:27 -0500 |
| Message-ID | <kv08uu$b8m$1@dont-email.me> |
| In reply to | #35505 |
On 20-Aug-13 11:27, Rosario1903 wrote: > On Tue, 20 Aug 2013 07:58:48 -0500, Stephen Sprunk > <stephen@sprunk.org> wrote: >> On 20-Aug-13 02:03, Rosario1903 wrote: >>> uint64_t i, len; >>> uint8_t *p; >>> >>> len=f(); >>> >>> if(len > SIZE_TMAX) goto error() >>> >>> p=malloc( len ); >>> >>> for(i=0; i<len; ++i) >>> p[i]=0; >> >> That code does not do what you think it does. The argument to >> malloc() is itself a size_t, which means you cannot pass it a >> larger value than SIZE_MAX in the first place. If you try to cram >> a larger value into len, because it's a unit64_t, it may appear to >> work but a much smaller object will actually be created, which will >> cause your indexing to fail at some point. > > if "void* malloc(size_t r)" That's not an "if"; that's defined by the Standard. > if len > SIZE_MAX the program goes in error, Sorry, I didn't catch the goto; my brain rejects that construct. Without that, the call to malloc() will likely appear to succeed, but the result will be a much smaller object than the caller expected. > if len <= SIZE_MAX > than "len" goes to conversion to size_t, > if size_t is unsigned can not be a problem Correct. But a different part of your code unnecessarily aborts if size_t isn't 64-bit, even though this case will work just fine. >> Consider what this code will do when you try to allocate (and then >> index) an 8GB array on a system that is incapable of creating an >> object larger than 32767 bytes, > > in that sys > len=0xFFFFFFFFFFFF; > if(len>SIZE_MAX) goto error; > > there is goto error... becaues SIZE_MAX==32767 Right. This is the correct solution, rather than insisting on size_t being a particular size (which may be larger than necessary) or blindly passing out-of-range values to malloc(). Also, there is no reason to require len to be exactly 64 bits; if you want an integer that is at least 64 bits wide, use unsigned long long. Ditto for p being uint8_t vs unsigned char. That way your code will be portable to systems that don't use power-of-two sizes. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-20 12:20 -0700 |
| Message-ID | <lnioz0i2zb.fsf@nuthaus.mib.org> |
| In reply to | #35506 |
Stephen Sprunk <stephen@sprunk.org> writes:
[...]
> Also, there is no reason to require len to be exactly 64 bits; if you
> want an integer that is at least 64 bits wide, use unsigned long long.
Or uint_least64_t (though that's probably going to be unsigned long long).
> Ditto for p being uint8_t vs unsigned char. That way your code will be
> portable to systems that don't use power-of-two sizes.
Or uint_least_t (which will probably be unsigned char).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2013-08-20 21:02 +0000 |
| Message-ID | <slrn3vfsl17mb5.9dm.ike@iceland.freeshell.org> |
| In reply to | #35508 |
On 2013-08-20, Keith Thompson <kst-u@mib.org> wrote: > Stephen Sprunk <stephen@sprunk.org> writes: > [...] >> Also, there is no reason to require len to be exactly 64 bits; if you >> want an integer that is at least 64 bits wide, use unsigned long long. > > Or uint_least64_t (though that's probably going to be unsigned long long). > >> Ditto for p being uint8_t vs unsigned char. That way your code will be >> portable to systems that don't use power-of-two sizes. > > Or uint_least_t (which will probably be unsigned char). Did you mean uint_least8_t ?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-08-20 16:10 -0700 |
| Message-ID | <ln61v0hsbe.fsf@nuthaus.mib.org> |
| In reply to | #35513 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2013-08-20, Keith Thompson <kst-u@mib.org> wrote:
>> Stephen Sprunk <stephen@sprunk.org> writes:
>> [...]
>>> Also, there is no reason to require len to be exactly 64 bits; if you
>>> want an integer that is at least 64 bits wide, use unsigned long long.
>>
>> Or uint_least64_t (though that's probably going to be unsigned long long).
>>
>>> Ditto for p being uint8_t vs unsigned char. That way your code will be
>>> portable to systems that don't use power-of-two sizes.
>>
>> Or uint_least_t (which will probably be unsigned char).
>
> Did you mean uint_least8_t ?
Yes, I did.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2013-08-23 10:50 +0300 |
| Message-ID | <87zjs826cn.fsf@bazspaz.fatphil.org> |
| In reply to | #35508 |
Keith Thompson <kst-u@mib.org> writes: (modulo minor typo) > Stephen Sprunk <stephen@sprunk.org> writes: > [...] > > Also, there is no reason to require len to be exactly 64 bits; if you > > want an integer that is at least 64 bits wide, use unsigned long long. > > Or uint_least64_t (though that's probably going to be unsigned long long). > > > Ditto for p being uint8_t vs unsigned char. That way your code will be > > portable to systems that don't use power-of-two sizes. > > Or uint_least8_t (which will probably be unsigned char). Whilst everything you both say is correct, sometimes I know that I prefer "provably works, as I know the size of everything" to "I've not actually checked to see what happens if we're in 36-bit lalaland, but it probably works" faux portability. I would rather build failures than unknown outcomes. (And a lot of my work is numeric, I do methematically (typo kept in for humour value) prove that the arithmetic modulo 2^32 or 2^64 does the right thing. If someone wants to port my code to 36-bit lalaland, then they will have to do the maths.) Phil -- If "law-abiding citizens have nothing to fear" from privacy-invading technologies and policies, then law-abiding governments should have nothing to fear from whistleblowers.
[toc] | [prev] | [next] | [standalone]
| From | Rosario1903 <Rosario@invalid.invalid> |
|---|---|
| Date | 2013-08-21 07:39 +0200 |
| Message-ID | <kgk819hj67kvn4k6vktfk9bse32tgnric8@4ax.com> |
| In reply to | #35506 |
On Tue, 20 Aug 2013 12:27:57 -0500, Stephen Sprunk <stephen@sprunk.org> wrote: >On 20-Aug-13 11:27, Rosario1903 wrote: >> On Tue, 20 Aug 2013 07:58:48 -0500, Stephen Sprunk >> <stephen@sprunk.org> wrote: >>> On 20-Aug-13 02:03, Rosario1903 wrote: >>>> uint64_t i, len; >>>> uint8_t *p; >>>> >Also, there is no reason to require len to be exactly 64 bits; in my vew registers len would be of 2^n: 2,4,8,16,32,64,128 etc >if you >want an integer that is at least 64 bits wide, use unsigned long long. >Ditto for p being uint8_t vs unsigned char. That way your code will be >portable to systems that don't use power-of-two sizes. i like uint64_t because i know the range is from 0 to 0xFFFFFFFF_FFFFFFFF >S
[toc] | [prev] | [next] | [standalone]
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web