Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #168196 > unrolled thread
| Started by | Amit <amitchoudhary0523@gmail.com> |
|---|---|
| First post | 2022-11-16 22:20 -0800 |
| Last post | 2022-12-04 07:35 -0800 |
| Articles | 20 on this page of 213 — 30 participants |
Back to article view | Back to comp.lang.c
size_t vs long. Amit <amitchoudhary0523@gmail.com> - 2022-11-16 22:20 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-17 02:44 -0500
Re: size_t vs long. Amit <amitchoudhary0523@gmail.com> - 2022-11-17 00:16 -0800
Re: size_t vs long. Amit <amitchoudhary0523@gmail.com> - 2022-11-17 00:28 -0800
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-17 07:59 -0500
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-17 05:09 -0800
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-11-17 13:45 +0000
Re: size_t vs long. Amit <amitchoudhary0523@gmail.com> - 2022-11-17 22:39 -0800
Re: size_t vs long. Ike Naar <ike@sdf.org> - 2022-11-18 08:19 +0000
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-19 01:42 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 12:32 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-20 01:32 -0500
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-18 11:21 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-19 02:51 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-19 11:37 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-19 22:39 -0800
Re: size_t vs long. Paul <nospam@needed.invalid> - 2022-11-18 13:21 -0500
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-17 16:17 +0000
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-18 09:56 +0100
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-20 01:46 -0500
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-19 01:41 -0500
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-17 09:37 +0000
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-19 01:41 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 12:56 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-19 13:03 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-19 21:17 +0000
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 17:41 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-21 10:30 +0100
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-22 04:27 +0000
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-22 08:55 +0100
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-20 01:33 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 22:50 -0800
Re: size_t vs long. Philipp Klaus Krause <pkk@spth.de> - 2022-11-25 20:51 +0100
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-25 12:21 -0800
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-20 06:52 -0800
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-17 09:31 +0000
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-17 02:43 -0800
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-17 10:02 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-18 10:19 +0100
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-18 01:46 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-18 13:01 +0100
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-18 04:56 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-18 14:49 +0000
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-19 06:19 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-19 06:44 -0800
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-19 09:53 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-19 02:23 -0500
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-19 06:42 -0800
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-19 10:00 -0500
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-19 10:09 -0800
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 13:27 -0800
Re: size_t vs long. Philipp Klaus Krause <pkk@spth.de> - 2022-11-24 11:26 +0100
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-04 06:29 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-21 11:31 +0100
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-21 08:51 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-21 15:11 -0500
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-18 07:33 -0500
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-18 04:55 -0800
Re: size_t vs long. tTh <tth@none.invalid> - 2022-11-18 11:01 +0100
Re: size_t vs long. Philipp Klaus Krause <pkk@spth.de> - 2022-11-23 09:23 +0100
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-24 20:09 +0000
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-25 08:29 +0100
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-17 11:16 +0100
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-17 02:48 -0800
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-11-17 11:30 +0000
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-17 03:52 -0800
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-11-17 12:27 +0000
Re: size_t vs long. Mark Bluemel <mark.bluemel@gmail.com> - 2022-11-17 04:28 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-17 04:34 -0800
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-17 15:48 +0000
Re: size_t vs long. Amit <amitchoudhary0523@gmail.com> - 2022-11-17 22:36 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-17 04:28 -0800
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-11-17 12:46 +0000
Re: size_t vs long. Paul N <gw7rib@aol.com> - 2022-11-17 05:24 -0800
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-17 16:20 +0000
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-17 15:55 +0000
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-19 01:43 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 12:47 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-20 01:33 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-19 22:38 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-20 01:51 -0500
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-20 15:43 +0000
Re: size_t vs long. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-20 15:29 +0000
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-17 16:59 +0000
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-18 10:30 +0100
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-17 12:47 +0000
Re: size_t vs long. Ike Naar <ike@sdf.org> - 2022-11-17 13:15 +0000
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-17 15:01 +0000
Re: size_t vs long. Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-11-17 15:24 +0000
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-17 21:48 -0800
Re: size_t vs long. Opus <ifonly@youknew.org> - 2022-11-18 20:12 +0100
Re: size_t vs long. Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-18 00:26 -0600
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-11-18 10:37 +0100
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-19 01:43 -0500
Re: size_t vs long. Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-20 03:06 +0100
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-19 19:58 -0800
Re: size_t vs long. Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-20 08:34 +0100
Re: size_t vs long. Opus <ifonly@youknew.org> - 2022-11-20 20:11 +0100
Re: size_t vs long. Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-20 20:48 +0100
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-21 21:57 -0800
Re: size_t vs long. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-11-22 02:33 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-25 12:01 -0800
Re: size_t vs long. Philipp Klaus Krause <pkk@spth.de> - 2022-11-23 09:28 +0100
Re: size_t vs long. Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-23 13:29 +0100
Re: size_t vs long. Dolores Filandro <dolfiland8@gmail.com> - 2022-11-25 17:26 -0800
Re: size_t vs long. Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-26 09:15 +0100
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-26 14:50 -0800
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-26 18:02 -0500
Re: size_t vs long. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2022-11-27 10:36 -0700
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-27 18:23 +0000
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-27 15:35 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-27 15:39 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-27 23:56 +0000
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-29 00:51 -0800
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-29 06:29 -0500
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-29 03:43 -0800
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-29 12:43 +0000
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-29 04:56 -0800
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-29 08:11 -0500
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-29 05:18 -0800
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-29 18:53 -0500
Re: size_t vs long. Vir Campestris <vir.campestris@invalid.invalid> - 2022-12-10 16:04 +0000
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-29 17:19 +0000
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-11-29 18:55 -0500
Re: size_t vs long. Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2022-11-30 00:02 +0000
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-30 01:58 +0000
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-29 10:21 -0800
Re: size_t vs long. Opus <ifonly@youknew.org> - 2022-11-29 19:42 +0100
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-29 19:00 +0000
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-29 13:47 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-11-29 22:45 +0000
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-30 00:42 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-30 00:44 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-30 23:31 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-11-30 23:35 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-01 09:08 +0100
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 04:23 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-03 16:42 +0100
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-12-01 02:47 -0500
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-01 09:14 +0100
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-01 12:41 -0800
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-12-01 23:53 +0000
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-02 21:30 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-03 13:48 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-05 00:17 +0100
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-13 13:12 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-03 14:55 +0100
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-12-03 09:35 -0500
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-12-03 14:56 +0000
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-12-03 15:33 -0500
Re: size_t vs long. Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-12-03 20:51 +0000
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-12-03 15:58 -0500
Re: size_t vs long. Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-12-03 21:12 +0000
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-12-03 17:22 -0500
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-12-03 23:58 +0000
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-12-03 19:25 -0500
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-12-03 23:44 +0000
Re: size_t vs long. Richard Damon <Richard@Damon-Family.org> - 2022-12-03 19:22 -0500
Re: size_t vs long. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-12-03 16:41 +0000
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-12-03 17:24 +0000
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-01 10:04 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-12-01 19:14 +0000
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 04:49 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 05:13 -0800
Re: size_t vs long. Öö Tiib <ootiib@hot.ee> - 2022-12-02 07:17 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 08:07 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-12-02 16:32 +0000
Re: size_t vs long. Bart <bc@freeuk.com> - 2022-12-02 16:58 +0000
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-02 12:46 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 21:32 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-02 21:41 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-02 21:42 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-02 21:49 -0800
Re: size_t vs long. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-04 12:49 -0800
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-03 12:59 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-12-04 11:54 -0500
Re: size_t vs long. Öö Tiib <ootiib@hot.ee> - 2022-12-02 14:58 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 21:17 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 21:38 -0800
Re: size_t vs long. Öö Tiib <ootiib@hot.ee> - 2022-12-03 03:39 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-13 01:45 -0800
Re: size_t vs long. Öö Tiib <ootiib@hot.ee> - 2022-12-13 20:18 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-14 01:20 -0800
Re: size_t vs long. Öö Tiib <ootiib@hot.ee> - 2022-12-16 03:03 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2023-01-05 01:21 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2023-01-05 01:41 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2023-01-05 16:53 +0100
Re: size_t vs long. A <amit234234234234@gmail.com> - 2023-01-06 01:29 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2023-01-06 10:51 +0100
Re: size_t vs long. A <amit234234234234@gmail.com> - 2023-01-06 02:19 -0800
Re: size_t vs long. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-06 02:43 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2023-01-06 14:56 +0100
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2023-01-06 16:26 +0000
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2023-01-06 19:51 +0100
Re: size_t vs long. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-06 12:52 -0800
Re: size_t vs long. DFS <nospam@dfs.com> - 2023-01-05 15:38 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-05 14:05 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2023-01-06 01:30 -0800
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-06 10:06 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-12-03 18:11 +0000
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-13 01:46 -0800
Re: size_t vs long. Vir Campestris <vir.campestris@invalid.invalid> - 2022-12-10 17:24 +0000
Re: size_t vs long. Öö Tiib <ootiib@hot.ee> - 2022-12-10 11:51 -0800
Re: size_t vs long. scott@slp53.sl.home (Scott Lurndal) - 2022-12-10 21:09 +0000
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-11 20:49 +0100
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-02 10:18 -0800
Re: size_t vs long. A <amit234234234234@gmail.com> - 2022-12-02 21:24 -0800
Re: size_t vs long. David Brown <david.brown@hesbynett.no> - 2022-12-03 16:54 +0100
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-03 12:48 -0800
Re: size_t vs long. James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-12-04 11:55 -0500
Re: size_t vs long. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-02 09:58 -0800
Re: size_t vs long. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-01 20:02 +0000
Re: size_t vs long. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-04 07:35 -0800
Page 1 of 11 [1] 2 3 … 11 Next page →
| From | Amit <amitchoudhary0523@gmail.com> |
|---|---|
| Date | 2022-11-16 22:20 -0800 |
| Subject | size_t vs long. |
| Message-ID | <5a71fdad-b7d6-4b4a-a3ee-c5a9beb75d28n@googlegroups.com> |
Hi, I prefer long over size_t. This is because, in case the user passes a negative number by mistake then I will be able to check it if the type is long and return immediately. But if size_t is used, then most probably, it will result in a crash - like malloc(-1) will crash the program because unsigned -1 is 0xFFFFFFFF and this much memory is not available on today's computers and probably may not be available at all in future also (RAM size of 2^64 bits is really really huge). Another thing is that if size_t is used an array index then array[-1] will result in wrong behavior or program crash. But with long, the developer can check whether the index is negative, thus avoiding program crash. So, in my opinion, long should be used instead of size_t. I know that original glibc authors had chosen size_t, so there must be some reason for that, however that reason is not clear to me. Amit
[toc] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-11-17 02:44 -0500 |
| Message-ID | <tl4op2$2juop$1@dont-email.me> |
| In reply to | #168196 |
On 11/17/22 01:20, Amit wrote: > Hi, > > I prefer long over size_t. For which purpose? C supports a large number of different types, precisely because different types are preferred for different purposes. More often than not, the type I need to use is dictated by the interfaces to standard and third-part libraries that I'm using. When I do have a choice in the matter, I prefer unsigned types like size_t in any context where bitwise operations are involved, because many of those operations can have undefined behavior under certain circumstances when using a signed types, but not with unsigned types. Unsigned types are often preferred when the quantity in question is incapable of being negative, though care must be used when applying this criterion. Operations involving quantities that cannot be negative, may have results that can be negative. If such operations are relevant to a particular variable, that variable should have a signed type.
[toc] | [prev] | [next] | [standalone]
| From | Amit <amitchoudhary0523@gmail.com> |
|---|---|
| Date | 2022-11-17 00:16 -0800 |
| Message-ID | <ddb4aff7-fb2a-4c57-be32-736d6615dd0fn@googlegroups.com> |
| In reply to | #168198 |
On Thursday, November 17, 2022 at 1:14:49 PM UTC+5:30, james...@alumni.caltech.edu wrote:
> On 11/17/22 01:20, Amit wrote:
> > Hi,
> >
> > I prefer long over size_t.
> For which purpose? C supports a large number of different types,
> precisely because different types are preferred for different purposes.
> More often than not, the type I need to use is dictated by the
> interfaces to standard and third-part libraries that I'm using.
>
> When I do have a choice in the matter, I prefer unsigned types like
> size_t in any context where bitwise operations are involved, because
> many of those operations can have undefined behavior under certain
> circumstances when using a signed types, but not with unsigned types.
>
> Unsigned types are often preferred when the quantity in question is
> incapable of being negative, though care must be used when applying this
> criterion. Operations involving quantities that cannot be negative, may
> have results that can be negative. If such operations are relevant to a
> particular variable, that variable should have a signed type.
I am not talking about signed vs unsigned.
I am specifically talking about size_t. In general, size_t is used in gibc where size is concerned such as in malloc(), memcmp(), etc.
size_t is defined as unsigned long.
My question is why size_t is used in these functions when, if the user passes a negative value by mistake then these functions will crash the program.
What reasons glibc original authors had when they used size_t in these functions instead of long.
If we don't know those reasons then if a developer has to implement a function called allocate_memory() then which implementation should he use and WHY?
Implementation 1:
-----------------------------
void *allocate_memory(size_t len)
{
}
Implementation 2:
-----------------------------
void *allocate_memory(long len)
{
}
Of the above two implementations, which implementation should the developer use and WHY?
In my opinion, using size_t in malloc(), memcmp(), etc. is wrong. I could be wrong but if we don't know original glibc authors reasons then may be I am right.
Amit
[toc] | [prev] | [next] | [standalone]
| From | Amit <amitchoudhary0523@gmail.com> |
|---|---|
| Date | 2022-11-17 00:28 -0800 |
| Message-ID | <17dd4a56-1498-43d0-a82c-ea972c8c91bfn@googlegroups.com> |
| In reply to | #168199 |
On Thursday, November 17, 2022 at 1:46:14 PM UTC+5:30, Amit wrote:
> On Thursday, November 17, 2022 at 1:14:49 PM UTC+5:30, james...@alumni.caltech.edu wrote:
> > On 11/17/22 01:20, Amit wrote:
> > > Hi,
> > >
> > > I prefer long over size_t.
> > For which purpose? C supports a large number of different types,
> > precisely because different types are preferred for different purposes.
> > More often than not, the type I need to use is dictated by the
> > interfaces to standard and third-part libraries that I'm using.
> >
> > When I do have a choice in the matter, I prefer unsigned types like
> > size_t in any context where bitwise operations are involved, because
> > many of those operations can have undefined behavior under certain
> > circumstances when using a signed types, but not with unsigned types.
> >
> > Unsigned types are often preferred when the quantity in question is
> > incapable of being negative, though care must be used when applying this
> > criterion. Operations involving quantities that cannot be negative, may
> > have results that can be negative. If such operations are relevant to a
> > particular variable, that variable should have a signed type.
> I am not talking about signed vs unsigned.
>
> I am specifically talking about size_t. In general, size_t is used in gibc where size is concerned such as in malloc(), memcmp(), etc.
>
> size_t is defined as unsigned long.
>
> My question is why size_t is used in these functions when, if the user passes a negative value by mistake then these functions will crash the program.
>
> What reasons glibc original authors had when they used size_t in these functions instead of long.
>
> If we don't know those reasons then if a developer has to implement a function called allocate_memory() then which implementation should he use and WHY?
>
> Implementation 1:
> -----------------------------
>
> void *allocate_memory(size_t len)
> {
> }
>
> Implementation 2:
> -----------------------------
>
> void *allocate_memory(long len)
> {
> }
>
> Of the above two implementations, which implementation should the developer use and WHY?
>
> In my opinion, using size_t in malloc(), memcmp(), etc. is wrong. I could be wrong but if we don't know original glibc authors reasons then may be I am right.
>
> Amit
To shorten the discussion and making it to the point, I would like to know why is size_t used in malloc() when a negative value (passed by user by mistake) can crash the program. Using long and checking for negative values can prevent the program from crashing.
Some people might say that user should check for value being negative but for checking for negative values long is required, not size_t. So, then the user will end up using long instead of size_t. So, in effect using size_t in malloc is not correct (unless we get further insight that explains why size_t is correct in malloc()).
Amit
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-17 07:59 -0500 |
| Message-ID | <VeqdL.68901$Iwb3.66405@fx13.iad> |
| In reply to | #168200 |
On 11/17/22 3:28 AM, Amit wrote:
> On Thursday, November 17, 2022 at 1:46:14 PM UTC+5:30, Amit wrote:
>> On Thursday, November 17, 2022 at 1:14:49 PM UTC+5:30, james...@alumni.caltech.edu wrote:
>>> On 11/17/22 01:20, Amit wrote:
>>>> Hi,
>>>>
>>>> I prefer long over size_t.
>>> For which purpose? C supports a large number of different types,
>>> precisely because different types are preferred for different purposes.
>>> More often than not, the type I need to use is dictated by the
>>> interfaces to standard and third-part libraries that I'm using.
>>>
>>> When I do have a choice in the matter, I prefer unsigned types like
>>> size_t in any context where bitwise operations are involved, because
>>> many of those operations can have undefined behavior under certain
>>> circumstances when using a signed types, but not with unsigned types.
>>>
>>> Unsigned types are often preferred when the quantity in question is
>>> incapable of being negative, though care must be used when applying this
>>> criterion. Operations involving quantities that cannot be negative, may
>>> have results that can be negative. If such operations are relevant to a
>>> particular variable, that variable should have a signed type.
>> I am not talking about signed vs unsigned.
>>
>> I am specifically talking about size_t. In general, size_t is used in gibc where size is concerned such as in malloc(), memcmp(), etc.
>>
>> size_t is defined as unsigned long.
>>
>> My question is why size_t is used in these functions when, if the user passes a negative value by mistake then these functions will crash the program.
>>
>> What reasons glibc original authors had when they used size_t in these functions instead of long.
>>
>> If we don't know those reasons then if a developer has to implement a function called allocate_memory() then which implementation should he use and WHY?
>>
>> Implementation 1:
>> -----------------------------
>>
>> void *allocate_memory(size_t len)
>> {
>> }
>>
>> Implementation 2:
>> -----------------------------
>>
>> void *allocate_memory(long len)
>> {
>> }
>>
>> Of the above two implementations, which implementation should the developer use and WHY?
>>
>> In my opinion, using size_t in malloc(), memcmp(), etc. is wrong. I could be wrong but if we don't know original glibc authors reasons then may be I am right.
>>
>> Amit
>
> To shorten the discussion and making it to the point, I would like to know why is size_t used in malloc() when a negative value (passed by user by mistake) can crash the program. Using long and checking for negative values can prevent the program from crashing.
But with an unsigned, you CAN'T pass a negative number, because as you
have said, it becomes a very big number, which for something like
malloc, should return an error, that will
>
> Some people might say that user should check for value being negative but for checking for negative values long is required, not size_t. So, then the user will end up using long instead of size_t. So, in effect using size_t in malloc is not correct (unless we get further insight that explains why size_t is correct in malloc()).
>
> Amit
But unsigneds CAN'T be negative, just too big to be reasonable, which
would also need to be checked with a long.
Thus with unsigned sizes you can make LESS checks for bad values, you
only need to check that it isn't too big, not that it negative.
Note, before we got to 64 bit computers, it was sometimes reasonable to
ask for more than 1/2 of the max value of the max unsigned value, so
making size_t signed would have been an error.
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-17 05:09 -0800 |
| Message-ID | <e6a39ee5-6fd7-42c8-91a4-c3d42558742an@googlegroups.com> |
| In reply to | #168217 |
On Thursday, 17 November 2022 at 18:29:46 UTC+5:30, Richard Damon wrote: > On 11/17/22 3:28 AM, Amit wrote: > > > Note, before we got to 64 bit computers, it was sometimes reasonable to > ask for more than 1/2 of the max value of the max unsigned value, so > making size_t signed would have been an error. Is there an example of this? As far as I know, malloc(size_t) was introduced in 1989 with C89 standard. At that time, i486 was also released. In 1985, i386 was released. They both had size of "long" as 32 bits but RAM size was only about 4 MB (22 bits) or 8 MB (23 bits). So, I don't think that your comment is correct unless you can give an example. Regards, Amit
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-11-17 13:45 +0000 |
| Message-ID | <tl5dt4$1o4n$1@gioia.aioe.org> |
| In reply to | #168219 |
On 17/11/2022 13:09, A wrote: > On Thursday, 17 November 2022 at 18:29:46 UTC+5:30, Richard Damon wrote: >> On 11/17/22 3:28 AM, Amit wrote: >> >> >> Note, before we got to 64 bit computers, it was sometimes reasonable to >> ask for more than 1/2 of the max value of the max unsigned value, so >> making size_t signed would have been an error. > > Is there an example of this? > > As far as I know, malloc(size_t) was introduced in 1989 with C89 standard. At that time, i486 was also released. In 1985, i386 was released. They both had size of "long" as 32 bits but RAM size was only about 4 MB (22 bits) or 8 MB (23 bits). > > So, I don't think that your comment is correct unless you can give an example. The comment was about the 32-bit machines just before 64-bit ones. And those 32-bit machines could easily have more then 4GB memory in total, and up to 4GB per task. So asking for a 3GB allocation was reasonable, but this needs a 32-bit unsigned value to represent. (Windows 32 would limit the address space for user code to 2GB, but other systems can work differently. What you don't want to throw away half the possible available memory just because of choosing i32 over u32.)
[toc] | [prev] | [next] | [standalone]
| From | Amit <amitchoudhary0523@gmail.com> |
|---|---|
| Date | 2022-11-17 22:39 -0800 |
| Message-ID | <cff8a5ef-edc5-4c1f-a49f-755d6484495cn@googlegroups.com> |
| In reply to | #168224 |
On Thursday, November 17, 2022 at 7:15:22 PM UTC+5:30, Bart wrote: > On 17/11/2022 13:09, A wrote: > > On Thursday, 17 November 2022 at 18:29:46 UTC+5:30, Richard Damon wrote: > >> On 11/17/22 3:28 AM, Amit wrote: > >> > >> > >> Note, before we got to 64 bit computers, it was sometimes reasonable to > >> ask for more than 1/2 of the max value of the max unsigned value, so > >> making size_t signed would have been an error. > > > > Is there an example of this? > > > > As far as I know, malloc(size_t) was introduced in 1989 with C89 standard. At that time, i486 was also released. In 1985, i386 was released. They both had size of "long" as 32 bits but RAM size was only about 4 MB (22 bits) or 8 MB (23 bits). > > > > So, I don't think that your comment is correct unless you can give an example. > The comment was about the 32-bit machines just before 64-bit ones. And > those 32-bit machines could easily have more then 4GB memory in total, > and up to 4GB per task. > > So asking for a 3GB allocation was reasonable, but this needs a 32-bit > unsigned value to represent. > Did some application/software really ask for 3 GB allocation in one go? Do you know of any such application/software? Amit
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.org> |
|---|---|
| Date | 2022-11-18 08:19 +0000 |
| Message-ID | <slrntneg02.pui.ike@sverige.sdf.org> |
| In reply to | #168242 |
On 2022-11-18, Amit <amitchoudhary0523@gmail.com> wrote:
> Did some application/software really ask for 3 GB allocation in one go?
> Do you know of any such application/software?
Here's one:
------8<------ start application/software.c ------>8------
#include <stdio.h>
#include <stdlib.h>
void try(size_t size)
{
printf("try: size as size_t: %zu, size as long: %ld\n", size, (long) size);
char * const p = malloc(size);
printf("try: malloc(%zu) = %p\n", size, p);
free(p);
}
int main(void)
{
printf("sizeof (long) = %zu\n", sizeof (long));
printf("sizeof (size_t) = %zu\n", sizeof (size_t));
size_t const giga = 1024 * 1024 * 1024;
try(3 * giga);
return 0;
}
------8<------ end application/software.c ------>8------
$ gcc -m32 application/software.c
$ ./a.out
sizeof (long) = 4
sizeof (size_t) = 4
try: size as size_t: 3221225472, size as long: -1073741824
try: malloc(3221225472) = 0x30800000
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-11-19 01:42 -0500 |
| Message-ID | <tl9tsq$367b8$3@dont-email.me> |
| In reply to | #168244 |
On 11/18/22 03:19, Ike Naar wrote: ... > size_t const giga = 1024 * 1024 * 1024; The initializer for that expression is evaluated as an int. INT_MAX is permitted to be low enough for that expression to overflow, and that's because there have been (and I believe, still are) real-world machines where int had as few as 16 bits. Note that, on many such machines, size_t also has only 16 bits, which is also permitted by the standard. I'd recommend using a hexadecimal constant here instead.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-19 12:32 -0800 |
| Message-ID | <87iljan0qv.fsf@nosuchdomain.example.com> |
| In reply to | #168271 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 11/18/22 03:19, Ike Naar wrote:
> ...
>> size_t const giga = 1024 * 1024 * 1024;
>
> The initializer for that expression is evaluated as an int. INT_MAX is
> permitted to be low enough for that expression to overflow, and that's
> because there have been (and I believe, still are) real-world machines
> where int had as few as 16 bits. Note that, on many such machines,
> size_t also has only 16 bits, which is also permitted by the standard.
> I'd recommend using a hexadecimal constant here instead.
Just in case someone misunderstands, you're recommending 0x40000000, not
0x400 * 0x400 * 0x400.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-11-20 01:32 -0500 |
| Message-ID | <tlchm6$3f4tk$1@dont-email.me> |
| In reply to | #168290 |
On 11/19/22 15:32, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On 11/18/22 03:19, Ike Naar wrote: >> ... >>> size_t const giga = 1024 * 1024 * 1024; >> >> The initializer for that expression is evaluated as an int. INT_MAX is >> permitted to be low enough for that expression to overflow, and that's >> because there have been (and I believe, still are) real-world machines >> where int had as few as 16 bits. Note that, on many such machines, >> size_t also has only 16 bits, which is also permitted by the standard. >> I'd recommend using a hexadecimal constant here instead. > > Just in case someone misunderstands, you're recommending 0x40000000, not > 0x400 * 0x400 * 0x400. You're right - I left out one crucial word: "... a single hexadecimal constant ...".
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-11-18 11:21 -0800 |
| Message-ID | <tl8lv1$30fpq$2@dont-email.me> |
| In reply to | #168242 |
On 11/17/2022 10:39 PM, Amit wrote: > On Thursday, November 17, 2022 at 7:15:22 PM UTC+5:30, Bart wrote: >> On 17/11/2022 13:09, A wrote: >>> On Thursday, 17 November 2022 at 18:29:46 UTC+5:30, Richard Damon wrote: >>>> On 11/17/22 3:28 AM, Amit wrote: >>>> >>>> >>>> Note, before we got to 64 bit computers, it was sometimes reasonable to >>>> ask for more than 1/2 of the max value of the max unsigned value, so >>>> making size_t signed would have been an error. >>> >>> Is there an example of this? >>> >>> As far as I know, malloc(size_t) was introduced in 1989 with C89 standard. At that time, i486 was also released. In 1985, i386 was released. They both had size of "long" as 32 bits but RAM size was only about 4 MB (22 bits) or 8 MB (23 bits). >>> >>> So, I don't think that your comment is correct unless you can give an example. >> The comment was about the 32-bit machines just before 64-bit ones. And >> those 32-bit machines could easily have more then 4GB memory in total, >> and up to 4GB per task. >> >> So asking for a 3GB allocation was reasonable, but this needs a 32-bit >> unsigned value to represent. >> > > Did some application/software really ask for 3 GB allocation in one go? Do you know of any such application/software? A volumetric renderer.
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-19 02:51 -0800 |
| Message-ID | <dbe626c8-0c72-49f6-8d06-88e44057292an@googlegroups.com> |
| In reply to | #168266 |
On Saturday, 19 November 2022 at 00:51:18 UTC+5:30, Chris M. Thomasson wrote: > On 11/17/2022 10:39 PM, Amit wrote: > > On Thursday, November 17, 2022 at 7:15:22 PM UTC+5:30, Bart wrote: > >> On 17/11/2022 13:09, A wrote: > >>> On Thursday, 17 November 2022 at 18:29:46 UTC+5:30, Richard Damon wrote: > >>>> On 11/17/22 3:28 AM, Amit wrote: > >>>> > >>>> > >>>> Note, before we got to 64 bit computers, it was sometimes reasonable to > >>>> ask for more than 1/2 of the max value of the max unsigned value, so > >>>> making size_t signed would have been an error. > >>> > >>> Is there an example of this? > >>> > >>> As far as I know, malloc(size_t) was introduced in 1989 with C89 standard. At that time, i486 was also released. In 1985, i386 was released. They both had size of "long" as 32 bits but RAM size was only about 4 MB (22 bits) or 8 MB (23 bits). > >>> > >>> So, I don't think that your comment is correct unless you can give an example. > >> The comment was about the 32-bit machines just before 64-bit ones. And > >> those 32-bit machines could easily have more then 4GB memory in total, > >> and up to 4GB per task. > >> > >> So asking for a 3GB allocation was reasonable, but this needs a 32-bit > >> unsigned value to represent. > >> > > > > Did some application/software really ask for 3 GB allocation in one go? Do you know of any such application/software? > A volumetric renderer. They do take a lot of memory. However, I doubt that they will malloc 3 GB in one go - like malloc(3 GB). I think they will do malloc() as and when required. Amit
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-11-19 11:37 -0800 |
| Message-ID | <tlbbai$39j1t$3@dont-email.me> |
| In reply to | #168276 |
On 11/19/2022 2:51 AM, A wrote: > On Saturday, 19 November 2022 at 00:51:18 UTC+5:30, Chris M. Thomasson wrote: >> On 11/17/2022 10:39 PM, Amit wrote: >>> On Thursday, November 17, 2022 at 7:15:22 PM UTC+5:30, Bart wrote: >>>> On 17/11/2022 13:09, A wrote: >>>>> On Thursday, 17 November 2022 at 18:29:46 UTC+5:30, Richard Damon wrote: >>>>>> On 11/17/22 3:28 AM, Amit wrote: >>>>>> >>>>>> >>>>>> Note, before we got to 64 bit computers, it was sometimes reasonable to >>>>>> ask for more than 1/2 of the max value of the max unsigned value, so >>>>>> making size_t signed would have been an error. >>>>> >>>>> Is there an example of this? >>>>> >>>>> As far as I know, malloc(size_t) was introduced in 1989 with C89 standard. At that time, i486 was also released. In 1985, i386 was released. They both had size of "long" as 32 bits but RAM size was only about 4 MB (22 bits) or 8 MB (23 bits). >>>>> >>>>> So, I don't think that your comment is correct unless you can give an example. >>>> The comment was about the 32-bit machines just before 64-bit ones. And >>>> those 32-bit machines could easily have more then 4GB memory in total, >>>> and up to 4GB per task. >>>> >>>> So asking for a 3GB allocation was reasonable, but this needs a 32-bit >>>> unsigned value to represent. >>>> >>> >>> Did some application/software really ask for 3 GB allocation in one go? Do you know of any such application/software? >> A volumetric renderer. > > They do take a lot of memory. However, I doubt that they will malloc 3 GB in one go - like malloc(3 GB). I think they will do malloc() as and when required. Loading up a high res volume say, 2048^3, does take a toll on the system...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-11-19 22:39 -0800 |
| Message-ID | <tlci33$3faqf$1@dont-email.me> |
| In reply to | #168289 |
On 11/19/2022 11:37 AM, Chris M. Thomasson wrote: > On 11/19/2022 2:51 AM, A wrote: >> On Saturday, 19 November 2022 at 00:51:18 UTC+5:30, Chris M. Thomasson >> wrote: >>> On 11/17/2022 10:39 PM, Amit wrote: >>>> On Thursday, November 17, 2022 at 7:15:22 PM UTC+5:30, Bart wrote: >>>>> On 17/11/2022 13:09, A wrote: >>>>>> On Thursday, 17 November 2022 at 18:29:46 UTC+5:30, Richard Damon >>>>>> wrote: >>>>>>> On 11/17/22 3:28 AM, Amit wrote: >>>>>>> >>>>>>> >>>>>>> Note, before we got to 64 bit computers, it was sometimes >>>>>>> reasonable to >>>>>>> ask for more than 1/2 of the max value of the max unsigned value, so >>>>>>> making size_t signed would have been an error. >>>>>> >>>>>> Is there an example of this? >>>>>> >>>>>> As far as I know, malloc(size_t) was introduced in 1989 with C89 >>>>>> standard. At that time, i486 was also released. In 1985, i386 was >>>>>> released. They both had size of "long" as 32 bits but RAM size was >>>>>> only about 4 MB (22 bits) or 8 MB (23 bits). >>>>>> >>>>>> So, I don't think that your comment is correct unless you can give >>>>>> an example. >>>>> The comment was about the 32-bit machines just before 64-bit ones. And >>>>> those 32-bit machines could easily have more then 4GB memory in total, >>>>> and up to 4GB per task. >>>>> >>>>> So asking for a 3GB allocation was reasonable, but this needs a 32-bit >>>>> unsigned value to represent. >>>>> >>>> >>>> Did some application/software really ask for 3 GB allocation in one >>>> go? Do you know of any such application/software? >>> A volumetric renderer. >> >> They do take a lot of memory. However, I doubt that they will malloc 3 >> GB in one go - like malloc(3 GB). I think they will do malloc() as and >> when required. > > Loading up a high res volume say, 2048^3, does take a toll on the system... > Some low res experiments, some are from volumetrics. The rest are from raw triangles in an obj file (wavefront). https://sketchfab.com/ChrisThomasson Works in VR... ;^) C++ is fun. Can crank out a obj file, no problem. Love this one, a circle in 3d can either be a circle, an ellipse or a line wrt an observing agent in the volume. https://skfb.ly/6TYVW a simple 3d von Koch curve: https://skfb.ly/6TuEV Using raw volumetric's requires big computers, so to speak... Think of very high res DICOM.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2022-11-18 13:21 -0500 |
| Message-ID | <tl8ien$uci$1@gioia.aioe.org> |
| In reply to | #168224 |
On 11/17/2022 8:45 AM, Bart wrote:
> On 17/11/2022 13:09, A wrote:
>> On Thursday, 17 November 2022 at 18:29:46 UTC+5:30, Richard Damon wrote:
>>> On 11/17/22 3:28 AM, Amit wrote:
>>>
>>>
>>> Note, before we got to 64 bit computers, it was sometimes reasonable to
>>> ask for more than 1/2 of the max value of the max unsigned value, so
>>> making size_t signed would have been an error.
>>
>> Is there an example of this?
>>
>> As far as I know, malloc(size_t) was introduced in 1989 with C89 standard. At that time, i486 was also released. In 1985, i386 was released. They both had size of "long" as 32 bits but RAM size was only about 4 MB (22 bits) or 8 MB (23 bits).
>>
>> So, I don't think that your comment is correct unless you can give an example.
>
> The comment was about the 32-bit machines just before 64-bit ones. And those 32-bit machines could easily have more then 4GB memory in total, and up to 4GB per task.
>
> So asking for a 3GB allocation was reasonable, but this needs a 32-bit unsigned value to represent.
>
> (Windows 32 would limit the address space for user code to 2GB, but other systems can work differently. What you don't want to throw away half the possible available memory just because of choosing i32 over u32.)
>
Windows XP (x86), allows the address space split to be changed.
The default virtual addresses are split 2GB userspace, 2GB kernelspace.
You can change this to 3GB userspace, 1GB kernelspace, but
this may cause various issues with the operation of the OS
for day-to-day activity (at least on WinXP it does -- the design is a
bit better on Windows 7).
I made that modification once, to get 32-bit Firefox to build on my WinXP x86
machine. And the build completed, the linking stage for XUL.dll
took every ounce of RAM the machine had. So at least the machine
behaved well enough, to finish a Firefox build that way.
As for hobby programming projects, this might help...
/* gcc -o malloc.exe -Wl,--large-address-aware malloc.c */
So once you change the split on your Windows XP machine, that's
how a little hobby program could use all 3GB of addresses.
And you may notice something a little weird about this 2:2
or 3:1 thing, as you don't get "exactly 2" or "exactly 3".
But I can't figure out why virtual addressing would have
any "holes cut in it", so I can't explain any size
discrepancy you might find. My test program, on 2:2 case, notes...
01919 megabytes t=001.263926
2048 minus 1919 is about 128MB. The test program in that
case, was very small, so it does not need 128MB of
address space just for the read-only code segment.
The result was not as pure as I had hoped. I first noticed
this on Photoshop and I blamed it on "bloated" code, but
that does not seem to be the reason. Even a small test program,
doesn't get to use the amount of space you might expect.
Paul
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-11-17 16:17 +0000 |
| Message-ID | <20221117080534.170@kylheku.com> |
| In reply to | #168219 |
On 2022-11-17, A <amit234234234234@gmail.com> wrote: > On Thursday, 17 November 2022 at 18:29:46 UTC+5:30, Richard Damon wrote: >> On 11/17/22 3:28 AM, Amit wrote: >> >> >> Note, before we got to 64 bit computers, it was sometimes reasonable to >> ask for more than 1/2 of the max value of the max unsigned value, so >> making size_t signed would have been an error. > > Is there an example of this? > > As far as I know, malloc(size_t) was introduced in 1989 with C89 > standard. ANSI C wasn't suddenly produced in 1989; it was ratified that year after years of standardization. Lots of 16-bit systems existed in that era and were programmed in C. There are still 16 bit microcontrollers today with C toolchains today. The most recewnt C standard allows implementations to be conforming which have a 16 bit size_t, and the library continues to be organized accordingly. The 8088 itself was used in some embedded systems, long after it disappeared from new personal computers. IBM-PC compatibles continued to run 16 bit platforms: MS-DOS was still used in 1989. Windows 3.0 was released in May, 1990. In the 1990 I had a programming job, which was on 16 bit DOS. I was wrestling with near and far pointers and such. That crud was still everywhere, and development for it was going on; it took some years after that for 16 bit PC's to begin disappearing. I was doing contract work in 1995 in various companies, and distinctly remember installations of Windows for Workgroups. Windows NT and 95 weren't brought in everywhere overnight. > At that time, i486 was also released. In 1985, i386 was > released. They both had size of "long" as 32 bits but RAM size was > only about 4 MB (22 bits) or 8 MB (23 bits). Eventually, 32 bit x86 machines did have RAM sizes of 4Gb and beyond, where some kinds of of programs that malloced over 2Gb made sense. (Not to mention that it's possible to do with virtual memory before you actually have that much RAM.) -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-18 09:56 +0100 |
| Message-ID | <tl7hbt$2tero$1@dont-email.me> |
| In reply to | #168219 |
On 17/11/2022 14:09, A wrote: > On Thursday, 17 November 2022 at 18:29:46 UTC+5:30, Richard Damon wrote: >> On 11/17/22 3:28 AM, Amit wrote: >> >> >> Note, before we got to 64 bit computers, it was sometimes reasonable to >> ask for more than 1/2 of the max value of the max unsigned value, so >> making size_t signed would have been an error. > > Is there an example of this? > > As far as I know, malloc(size_t) was introduced in 1989 with C89 standard. At that time, i486 was also released. In 1985, i386 was released. They both had size of "long" as 32 bits but RAM size was only about 4 MB (22 bits) or 8 MB (23 bits). > > So, I don't think that your comment is correct unless you can give an example. > The history of both "malloc" and C goes back a lot longer than the first ANSI C standard. And in 1989 there were 64-bit computers with 32 GB of ram. Not many, to be fair - Cray was not a mass-market supplier - but they existed. Addresses had already been used for far bigger ranges than physical memory, however, as people used virtual memory for large tasks. For 16-bit systems, it is entirely reasonable to ask for more than half the address range. "size_t" is 16-bit unsigned, while "long" will be 32-bit (the minimum size allowed), and programs may deal with objects that are greater than 32 KB but less than the full 64K address range. We did have 64-bit systems before 4 GB ram became an economically and physically practical size of memory. But 32-bit processors were still common with a long overlap with 64-bit processors in the mass market, and the Windows world was especially limited. Normal 32-bit Windows limited user space to 2 GB, and thus a signed 32-bit size would be enough, but IIRC 32-bit server versions of Windows supported a 3/1 GB split between user and kernel space. That was common on 32-bit Linux too. This is all history, of course. The main reasons to use "size_t" instead of "long" for sizes in C are that it is the standard practice and you'd need a /very/ good reason for doing something else, and that on Windows systems, "long" is not big enough - you'd need "long long". And on 32-bit systems, "long long" would be too big. You need a type that is "just right" for all systems - "size_t".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-11-20 01:46 -0500 |
| Message-ID | <tlcif8$3f4tj$1@dont-email.me> |
| In reply to | #168219 |
On 11/17/22 08:09, A wrote: > On Thursday, 17 November 2022 at 18:29:46 UTC+5:30, Richard Damon wrote: >> On 11/17/22 3:28 AM, Amit wrote: >> >> >> Note, before we got to 64 bit computers, it was sometimes reasonable to >> ask for more than 1/2 of the max value of the max unsigned value, so >> making size_t signed would have been an error. > > Is there an example of this?> > As far as I know, malloc(size_t) was introduced in 1989 with C89 standard. At that time, i486 was also released. In 1985, i386 was released. They both had size of "long" as 32 bits but RAM size was only about 4 MB (22 bits) or 8 MB (23 bits). > > So, I don't think that your comment is correct unless you can give an example. The C programming language is targeted at a much wider range of systems than you seem to be willing to consider. The minimum permitted value for SIZE_MAX is 65535, and that minimum was set precisely because, at the time it was set, there were some systems for which a value that low was appropriate, and such systems still exist. On systems with such small amounts of memory, a need to allocate more than half of it at one time might be rare, but not very rare. Another issue to consider is that SIZE_MAX is simply the largest amount of memory that you can request be allocated. It need not be greater than the total amount of memory available on a system to be allocated. On systems where SIZE_MAX is much smaller than the total amount of memory, allocating more than SIZE_MAX/2 bytes would not be particularly uncommon.
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web