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 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-11-22 02:33 -0800 |
| Message-ID | <15f0bc61-2bd4-42ec-8b62-b50b582231ccn@googlegroups.com> |
| In reply to | #168330 |
On Tuesday, 22 November 2022 at 05:57:33 UTC, Chris M. Thomasson wrote: > On 11/19/2022 7:58 PM, Chris M. Thomasson wrote: > > On 11/19/2022 6:06 PM, Bonita Montero wrote: > >> I always use int, it's the best choice for indexing on all machines. > > > > Until the index gets larger than INT_MAX? > Have you ever had to iterate larger than INT_MAX times before? > Mostly limits like that are not known at compile time, but are passed in by the user. I'm currently working on a general purpose 2D graphics library, and most of the data are Bezier paths. It's possible for the caller to construct a path of any size up to the maximum a size_t will hold. Some of the algorithms then construct an N-squared matrix of points. So of course it's possible to exceed their capabilities. But you'd have other problems with such big paths. The display side of the software might struggle to rasterise them. And they would be impossible for the user to edit. Virtually all paths are under a thousand points and most well under a hundred, and the algorithms aren't required to return in reasonable time for paths over about a thousand points.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-11-25 12:01 -0800 |
| Message-ID | <tlr6un$12r0g$2@dont-email.me> |
| In reply to | #168336 |
On 11/22/2022 2:33 AM, Malcolm McLean wrote: > On Tuesday, 22 November 2022 at 05:57:33 UTC, Chris M. Thomasson wrote: >> On 11/19/2022 7:58 PM, Chris M. Thomasson wrote: >>> On 11/19/2022 6:06 PM, Bonita Montero wrote: >>>> I always use int, it's the best choice for indexing on all machines. >>> >>> Until the index gets larger than INT_MAX? >> Have you ever had to iterate larger than INT_MAX times before? >> > Mostly limits like that are not known at compile time, but are passed in by the user. Mostly... Fwiw, I have computed IFS's with very large iterations. Larger than 2,147,483,647. INT_MAX is not even guaranteed to be 32-bit... > I'm currently working on a general purpose 2D graphics library, and most of the data > are Bezier paths. It's possible for the caller to construct a path of any size up to the > maximum a size_t will hold. Some of the algorithms then construct an N-squared matrix > of points. So of course it's possible to exceed their capabilities. > But you'd have other problems with such big paths. The display side of the software > might struggle to rasterise them. And they would be impossible for the user to edit. > Virtually all paths are under a thousand points and most well under a hundred, and > the algorithms aren't required to return in reasonable time for paths over about a thousand > points. Nice! Fwiw, one of my vector field makes it possible to construct a path, plotted on a segment-by-segment basis that requires billions of iterations. It would not work well in one of my experimental webgl programs: http://fractallife247.com/test/webgl Btw, does it work on your end?
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2022-11-23 09:28 +0100 |
| Message-ID | <tlklj8$7e46$3@solani.org> |
| In reply to | #168299 |
Am 20.11.22 um 03:06 schrieb Bonita Montero: > I always use int, it's the best choice for indexing on all machines. I often use uint_fast8_t, since it tends to be the "best" choice for my indexing for the machines I target.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-11-23 13:29 +0100 |
| Message-ID | <tll3nl$cap4$2@dont-email.me> |
| In reply to | #168338 |
Am 23.11.2022 um 09:28 schrieb Philipp Klaus Krause: > I often use uint_fast8_t, since it tends to be the "best" choice for my > indexing for the machines I target. I was joking ...
[toc] | [prev] | [next] | [standalone]
| From | Dolores Filandro <dolfiland8@gmail.com> |
|---|---|
| Date | 2022-11-25 17:26 -0800 |
| Message-ID | <3cd9fa14-f717-40b6-a430-5b6f609fcdc7n@googlegroups.com> |
| In reply to | #168196 |
On Thursday, November 17, 2022 at 1:20:45 AM UTC-5, Amit wrote: > 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 malloc returns NULL if the amount requested exceeds what malloc can allocate. There is no wrong behavior or crash from malloc(-1)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-11-26 09:15 +0100 |
| Message-ID | <tlshup$1ai85$1@dont-email.me> |
| In reply to | #168353 |
Am 26.11.2022 um 02:26 schrieb Dolores Filandro: > malloc returns NULL if the amount requested exceeds what malloc > can allocate. There is no wrong behavior or crash from malloc(-1) 30 yrs ago there were machines where malloc( -1 ) succeeded.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-11-26 14:50 -0800 |
| Message-ID | <tlu587$1fha9$5@dont-email.me> |
| In reply to | #168353 |
On 11/25/2022 5:26 PM, Dolores Filandro wrote: > On Thursday, November 17, 2022 at 1:20:45 AM UTC-5, Amit wrote: >> 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 > > malloc returns NULL if the amount requested exceeds what malloc can allocate. > There is no wrong behavior or crash from malloc(-1) I remember way back, in 2001'ish where if a malloc failed the server program would go into "panic mode" and start dumping resources.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-26 18:02 -0500 |
| Message-ID | <oWwgL.258409$kmVf.247337@fx15.iad> |
| In reply to | #168356 |
On 11/26/22 5:50 PM, Chris M. Thomasson wrote: > On 11/25/2022 5:26 PM, Dolores Filandro wrote: >> On Thursday, November 17, 2022 at 1:20:45 AM UTC-5, Amit wrote: >>> 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 >> >> malloc returns NULL if the amount requested exceeds what malloc can >> allocate. >> There is no wrong behavior or crash from malloc(-1) > > I remember way back, in 2001'ish where if a malloc failed the server > program would go into "panic mode" and start dumping resources. That would be from a bug in the server program. Or a "bug"/mis-feature in the OS that resulted from over-committing. Requesting an EXTREAMELY to large block probably shouldn't create the over-commit situation, as that would have that one process having too much allocatd.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2022-11-27 10:36 -0700 |
| Message-ID | <1b4juk47wa.fsf@pfeifferfamily.net> |
| In reply to | #168356 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > On 11/25/2022 5:26 PM, Dolores Filandro wrote: >> malloc returns NULL if the amount requested exceeds what malloc can >> allocate. >> There is no wrong behavior or crash from malloc(-1) > > I remember way back, in 2001'ish where if a malloc failed the server > program would go into "panic mode" and start dumping resources. That's a program that didn't properly handle a null return from malloc(), not a problem with malloc(). Something I do regard as a problem with either malloc(), Linux, or their interaction is that malloc() will happily allocate space that doesn't exist, and the user won't find out until an attempt is made to access the space and a protection violation happens.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-11-27 18:23 +0000 |
| Message-ID | <HWNgL.314526$Mlk.235583@fx17.iad> |
| In reply to | #168364 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > >> On 11/25/2022 5:26 PM, Dolores Filandro wrote: >>> malloc returns NULL if the amount requested exceeds what malloc can >>> allocate. >>> There is no wrong behavior or crash from malloc(-1) >> >> I remember way back, in 2001'ish where if a malloc failed the server >> program would go into "panic mode" and start dumping resources. > >That's a program that didn't properly handle a null return from >malloc(), not a problem with malloc(). > >Something I do regard as a problem with either malloc(), Linux, or their >interaction is that malloc() will happily allocate space that doesn't >exist, and the user won't find out until an attempt is made to access >the space and a protection violation happens. That "overcommit" was a feature introduced originally in AIX. Linux can be configured to overcommit or not by the system administrator.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-11-27 15:35 -0800 |
| Message-ID | <tm0s7v$1p7e1$1@dont-email.me> |
| In reply to | #168364 |
On 11/27/2022 9:36 AM, Joe Pfeiffer wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > >> On 11/25/2022 5:26 PM, Dolores Filandro wrote: >>> malloc returns NULL if the amount requested exceeds what malloc can >>> allocate. >>> There is no wrong behavior or crash from malloc(-1) >> >> I remember way back, in 2001'ish where if a malloc failed the server >> program would go into "panic mode" and start dumping resources. > > That's a program that didn't properly handle a null return from > malloc(), not a problem with malloc(). > > Something I do regard as a problem with either malloc(), Linux, or their > interaction is that malloc() will happily allocate space that doesn't > exist, and the user won't find out until an attempt is made to access > the space and a protection violation happens. I was testing different methods to handle resources in a server back then. One of the tests would malloc per-connection state on every new connection. Sure enough, a stress test would make a malloc return NULL. So, I would start dumping user state, and try malloc again in an experiment. Fun times. NT 4.0. Actually, forget about malloc failing for a moment, I remember some tests where the non-paged memory pool would get exhausted do to too many pending IOCP actions, and blast the whole system.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-11-27 15:39 -0800 |
| Message-ID | <tm0sf3$1p7e1$2@dont-email.me> |
| In reply to | #168368 |
On 11/27/2022 3:35 PM, Chris M. Thomasson wrote: > On 11/27/2022 9:36 AM, Joe Pfeiffer wrote: >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> >>> On 11/25/2022 5:26 PM, Dolores Filandro wrote: >>>> malloc returns NULL if the amount requested exceeds what malloc can >>>> allocate. >>>> There is no wrong behavior or crash from malloc(-1) >>> >>> I remember way back, in 2001'ish where if a malloc failed the server >>> program would go into "panic mode" and start dumping resources. >> >> That's a program that didn't properly handle a null return from >> malloc(), not a problem with malloc(). >> >> Something I do regard as a problem with either malloc(), Linux, or their >> interaction is that malloc() will happily allocate space that doesn't >> exist, and the user won't find out until an attempt is made to access >> the space and a protection violation happens. > > I was testing different methods to handle resources in a server back > then. One of the tests would malloc per-connection state on every new > connection. Sure enough, a stress test would make a malloc return NULL. > So, I would start dumping user state, and try malloc again in an > experiment. Fun times. NT 4.0. Actually, forget about malloc failing for > a moment, I remember some tests where the non-paged memory pool would > get exhausted do to too many pending IOCP actions, and blast the whole > system. For some reason my brain is thinking about an old paper that dealt with so-called cohort scheduling. A method to bunch up like operations in IOCP or the POSIX aio api. Let me try to find the paper... Hey now! I think I found it... Cool! https://www.usenix.org/legacy/publications/library/proceedings/usenix02/full_papers/larus/larus.pdf :^D
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-11-27 23:56 +0000 |
| Message-ID | <xOSgL.117610$8875.113341@fx13.iad> |
| In reply to | #168369 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 11/27/2022 3:35 PM, Chris M. Thomasson wrote: >> On 11/27/2022 9:36 AM, Joe Pfeiffer wrote: >>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>> >>>> On 11/25/2022 5:26 PM, Dolores Filandro wrote: >>>>> malloc returns NULL if the amount requested exceeds what malloc can >>>>> allocate. >>>>> There is no wrong behavior or crash from malloc(-1) >>>> >>>> I remember way back, in 2001'ish where if a malloc failed the server >>>> program would go into "panic mode" and start dumping resources. >>> >>> That's a program that didn't properly handle a null return from >>> malloc(), not a problem with malloc(). >>> >>> Something I do regard as a problem with either malloc(), Linux, or their >>> interaction is that malloc() will happily allocate space that doesn't >>> exist, and the user won't find out until an attempt is made to access >>> the space and a protection violation happens. >> >> I was testing different methods to handle resources in a server back >> then. One of the tests would malloc per-connection state on every new >> connection. Sure enough, a stress test would make a malloc return NULL. >> So, I would start dumping user state, and try malloc again in an >> experiment. Fun times. NT 4.0. Actually, forget about malloc failing for >> a moment, I remember some tests where the non-paged memory pool would >> get exhausted do to too many pending IOCP actions, and blast the whole >> system. > >For some reason my brain is thinking about an old paper that dealt with >so-called cohort scheduling. A method to bunch up like operations in >IOCP or the POSIX aio api. Let me try to find the paper... > Back in the mid 90's, I was working on the Oracle OSD for the Unisys OPUS platform (a massively parallel system). The OSD (OS-dependent layer) abstracts the hardware from the RDBMS itself. The OPUS systems had up to 64 nodes, each with a scsi controller and each with an ethernet port (100baseT at that point). We were running OPS (Oracle Parallel Server - later called RAC) to exploit the parallelism. The database was striped across multiple disks on all nodes and OPS workloads are dominated by I/O. The core RDBMS passed a list of required blocks to the OSD layer and we use the POSIX lio_listio(2) function to queue several thousand block requests to the kernel with a single system call. The kernel queued all the I/O's to the corresponding node automatically and we could poll for completion when prompted by the RDBMS.
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-29 00:51 -0800 |
| Message-ID | <0a801acb-1c1d-4216-894a-aa11ad307934n@googlegroups.com> |
| In reply to | #168370 |
On Monday, 28 November 2022 at 05:26:26 UTC+5:30, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
> >On 11/27/2022 3:35 PM, Chris M. Thomasson wrote:
> >> On 11/27/2022 9:36 AM, Joe Pfeiffer wrote:
> >>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
> >>>
> >>>> On 11/25/2022 5:26 PM, Dolores Filandro wrote:
> >>>>> malloc returns NULL if the amount requested exceeds what malloc can
> >>>>> allocate.
> >>>>> There is no wrong behavior or crash from malloc(-1)
> >>>>
> >>>> I remember way back, in 2001'ish where if a malloc failed the server
> >>>> program would go into "panic mode" and start dumping resources.
> >>>
> >>> That's a program that didn't properly handle a null return from
> >>> malloc(), not a problem with malloc().
> >>>
> >>> Something I do regard as a problem with either malloc(), Linux, or their
> >>> interaction is that malloc() will happily allocate space that doesn't
> >>> exist, and the user won't find out until an attempt is made to access
> >>> the space and a protection violation happens.
> >>
> >> I was testing different methods to handle resources in a server back
> >> then. One of the tests would malloc per-connection state on every new
> >> connection. Sure enough, a stress test would make a malloc return NULL.
> >> So, I would start dumping user state, and try malloc again in an
> >> experiment. Fun times. NT 4.0. Actually, forget about malloc failing for
> >> a moment, I remember some tests where the non-paged memory pool would
> >> get exhausted do to too many pending IOCP actions, and blast the whole
> >> system.
> >
> >For some reason my brain is thinking about an old paper that dealt with
> >so-called cohort scheduling. A method to bunch up like operations in
> >IOCP or the POSIX aio api. Let me try to find the paper...
> >
> Back in the mid 90's, I was working on the Oracle OSD for the Unisys OPUS
> platform (a massively parallel system). The OSD (OS-dependent layer)
> abstracts the hardware from the RDBMS itself. The OPUS systems had
> up to 64 nodes, each with a scsi controller and each with an ethernet
> port (100baseT at that point). We were running OPS (Oracle Parallel
> Server - later called RAC) to exploit the parallelism.
>
> The database was striped across multiple disks on all nodes and OPS
> workloads are dominated by I/O. The core RDBMS passed a list of
> required blocks to the OSD layer and we use the POSIX lio_listio(2)
> function to queue several thousand block requests to the kernel with
> a single system call. The kernel queued all the I/O's to the corresponding
> node automatically and we could poll for completion when prompted by the
> RDBMS.
Is size_t usage justified in memcpy()? If a user passes a negative number by mistake then memcpy() will crash.
void *memcpy(void *dest, const void *src, size_t n);
Shouldn't memcpy() function be like this:
void *memcpy(void *dest, const void *src, long n)
{
if (n < 0)
return NULL;
__Rest_of_Code__
}
It can be argued that a large number for 'n' can also crash the system but we should try to crash as less as possible.
Crashing is good but only during internal testing. Once the system goes live and people start using it, then if the system crashes then it is a big problem. And it is quite possible that the system may not crash in internal testing but may crash when it is live.
Suppose, a user by mistake enters '-1' for some value asked by the system and then this value is passed to memcpy(), then memcpy() will crash. It can be argued that the system can check for negative values, but it is equivalent to saying that memcpy() can also check for negative values.
And, in internal testing, it is quite possible than manual testers / automated tests don't pass a value of '-1' when asked for a value by the system.
I know glibc won't be changed but in my opinion, where ever size_t is used in glibc and a '-1' value for it can crash the system, then size_t is a wrong choice. In my opinion, these functions should declare size variables as long and check for negative values and return an error if the value is negative.
Amit
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-29 06:29 -0500 |
| Message-ID | <E2mhL.32010$zBQ2.21797@fx40.iad> |
| In reply to | #168376 |
On 11/29/22 3:51 AM, A wrote:
> On Monday, 28 November 2022 at 05:26:26 UTC+5:30, Scott Lurndal wrote:
>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>> On 11/27/2022 3:35 PM, Chris M. Thomasson wrote:
>>>> On 11/27/2022 9:36 AM, Joe Pfeiffer wrote:
>>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>>>
>>>>>> On 11/25/2022 5:26 PM, Dolores Filandro wrote:
>>>>>>> malloc returns NULL if the amount requested exceeds what malloc can
>>>>>>> allocate.
>>>>>>> There is no wrong behavior or crash from malloc(-1)
>>>>>>
>>>>>> I remember way back, in 2001'ish where if a malloc failed the server
>>>>>> program would go into "panic mode" and start dumping resources.
>>>>>
>>>>> That's a program that didn't properly handle a null return from
>>>>> malloc(), not a problem with malloc().
>>>>>
>>>>> Something I do regard as a problem with either malloc(), Linux, or their
>>>>> interaction is that malloc() will happily allocate space that doesn't
>>>>> exist, and the user won't find out until an attempt is made to access
>>>>> the space and a protection violation happens.
>>>>
>>>> I was testing different methods to handle resources in a server back
>>>> then. One of the tests would malloc per-connection state on every new
>>>> connection. Sure enough, a stress test would make a malloc return NULL.
>>>> So, I would start dumping user state, and try malloc again in an
>>>> experiment. Fun times. NT 4.0. Actually, forget about malloc failing for
>>>> a moment, I remember some tests where the non-paged memory pool would
>>>> get exhausted do to too many pending IOCP actions, and blast the whole
>>>> system.
>>>
>>> For some reason my brain is thinking about an old paper that dealt with
>>> so-called cohort scheduling. A method to bunch up like operations in
>>> IOCP or the POSIX aio api. Let me try to find the paper...
>>>
>> Back in the mid 90's, I was working on the Oracle OSD for the Unisys OPUS
>> platform (a massively parallel system). The OSD (OS-dependent layer)
>> abstracts the hardware from the RDBMS itself. The OPUS systems had
>> up to 64 nodes, each with a scsi controller and each with an ethernet
>> port (100baseT at that point). We were running OPS (Oracle Parallel
>> Server - later called RAC) to exploit the parallelism.
>>
>> The database was striped across multiple disks on all nodes and OPS
>> workloads are dominated by I/O. The core RDBMS passed a list of
>> required blocks to the OSD layer and we use the POSIX lio_listio(2)
>> function to queue several thousand block requests to the kernel with
>> a single system call. The kernel queued all the I/O's to the corresponding
>> node automatically and we could poll for completion when prompted by the
>> RDBMS.
>
>
> Is size_t usage justified in memcpy()? If a user passes a negative number by mistake then memcpy() will crash.
>
> void *memcpy(void *dest, const void *src, size_t n);
>
> Shouldn't memcpy() function be like this:
>
> void *memcpy(void *dest, const void *src, long n)
> {
> if (n < 0)
> return NULL;
>
> __Rest_of_Code__
>
> }
>
> It can be argued that a large number for 'n' can also crash the system but we should try to crash as less as possible.
And exactly the same number of values are "bad" for a given call whether
signed or unsigned.
>
> Crashing is good but only during internal testing. Once the system goes live and people start using it, then if the system crashes then it is a big problem. And it is quite possible that the system may not crash in internal testing but may crash when it is live.
>
> Suppose, a user by mistake enters '-1' for some value asked by the system and then this value is passed to memcpy(), then memcpy() will crash. It can be argued that the system can check for negative values, but it is equivalent to saying that memcpy() can also check for negative values.
So that is the fault of the PROGRAM not validating its input. Note, the
program has the ability to also check for a too big value, memcpy
doesn't, so it is the program that needs to do that test.
>
> And, in internal testing, it is quite possible than manual testers / automated tests don't pass a value of '-1' when asked for a value by the system.
>
> I know glibc won't be changed but in my opinion, where ever size_t is used in glibc and a '-1' value for it can crash the system, then size_t is a wrong choice. In my opinion, these functions should declare size variables as long and check for negative values and return an error if the value is negative.
>
> Amit
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-29 03:43 -0800 |
| Message-ID | <a9999649-3a56-4159-829d-8b08a021236dn@googlegroups.com> |
| In reply to | #168377 |
On Tuesday, 29 November 2022 at 16:59:55 UTC+5:30, Richard Damon wrote: > On 11/29/22 3:51 AM, A wrote: > > Suppose, a user by mistake enters '-1' for some value asked by the system and then this value is passed to memcpy(), then memcpy() will crash. It can be argued that the system can check for negative values, but it is equivalent to saying that memcpy() can also check for negative values. > So that is the fault of the PROGRAM not validating its input. Note, the > program has the ability to also check for a too big value, memcpy > doesn't, so it is the program that needs to do that test. > > That's the point. Why doesn't memcpy() check for valid/invalid values. Why is it leaving input validation for the user? I also have written few libraries and I do as much input validation as I can in my functions to make the user do less work. Amit
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-11-29 12:43 +0000 |
| Message-ID | <87v8mydj8j.fsf@bsb.me.uk> |
| In reply to | #168378 |
A <amit234234234234@gmail.com> writes: > On Tuesday, 29 November 2022 at 16:59:55 UTC+5:30, Richard Damon wrote: >> So that is the fault of the PROGRAM not validating its input. Note, the >> program has the ability to also check for a too big value, memcpy >> doesn't, so it is the program that needs to do that test. > > That's the point. Why doesn't memcpy() check for valid/invalid > values. What checks exactly -- that both pointers are non null and that the size is somehow fine? What sizes would you permit and which would you declare to be out of bounds? What would you do to tell the caller that the arguments are invalid? These are not rhetorical questions. I really want to know your view on how memcpy should have been specified so I can see if it's a function I would like to use. > Why is it leaving input validation for the user? Because that's the only general solution. If you want error_type my_memcpy(void *dst, const void *src, long size); you can write it in a few lines. But if memcpy did this, I can't avoid paying the price of checks on arguments I know to be valid. > I also have > written few libraries and I do as much input validation as I can in my > functions to make the user do less work. Do you know about memcpy_s? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-29 04:56 -0800 |
| Message-ID | <f8ea0400-2902-4117-b7a1-aacd998ebcb0n@googlegroups.com> |
| In reply to | #168380 |
On Tuesday, 29 November 2022 at 18:13:24 UTC+5:30, Ben Bacarisse wrote: > A <amit2342...@gmail.com> writes: > > > On Tuesday, 29 November 2022 at 16:59:55 UTC+5:30, Richard Damon wrote: > > >> So that is the fault of the PROGRAM not validating its input. Note, the > >> program has the ability to also check for a too big value, memcpy > >> doesn't, so it is the program that needs to do that test. > > > > That's the point. Why doesn't memcpy() check for valid/invalid > > values. > What checks exactly -- that both pointers are non null and that the size > is somehow fine? What sizes would you permit and which would you > declare to be out of bounds? What would you do to tell the caller that > the arguments are invalid? > My only argument is that the variable type should be 'long' instead of 'size_t' when a negative value can crash the system which has the variable type as 'size_t'. > > error_type my_memcpy(void *dst, const void *src, long size); > > you can write it in a few lines. But if memcpy did this, I can't avoid > paying the price of checks on arguments I know to be valid. Arguments have to be checked by someone - either by the user or by memcpy(). So, the cost is the same. Amit
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-29 08:11 -0500 |
| Message-ID | <DxnhL.32729$KDc3.26819@fx35.iad> |
| In reply to | #168381 |
On 11/29/22 7:56 AM, A wrote: > On Tuesday, 29 November 2022 at 18:13:24 UTC+5:30, Ben Bacarisse wrote: >> A <amit2342...@gmail.com> writes: >> >>> On Tuesday, 29 November 2022 at 16:59:55 UTC+5:30, Richard Damon wrote: >> >>>> So that is the fault of the PROGRAM not validating its input. Note, the >>>> program has the ability to also check for a too big value, memcpy >>>> doesn't, so it is the program that needs to do that test. >>> >>> That's the point. Why doesn't memcpy() check for valid/invalid >>> values. >> What checks exactly -- that both pointers are non null and that the size >> is somehow fine? What sizes would you permit and which would you >> declare to be out of bounds? What would you do to tell the caller that >> the arguments are invalid? >> > > My only argument is that the variable type should be 'long' instead of 'size_t' when a negative value can crash the system which has the variable type as 'size_t'. But still most of the positive values that it can't check for will break the program or crash the system. Any value bigger than the size of the output buffer will cause problems. memcpy don't know that size, you should (or you need to trust YOUR callers to verify correct usage). > >> >> error_type my_memcpy(void *dst, const void *src, long size); >> >> you can write it in a few lines. But if memcpy did this, I can't avoid >> paying the price of checks on arguments I know to be valid. > > Arguments have to be checked by someone - either by the user or by memcpy(). So, the cost is the same. Nope, they can be know to be correct because you did ONE check on them earlier, rather than needed to recheck on each use. > > Amit
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-29 05:18 -0800 |
| Message-ID | <068d7ac4-13e2-48ee-aaae-d1622e50bcaen@googlegroups.com> |
| In reply to | #168382 |
On Tuesday, 29 November 2022 at 18:41:14 UTC+5:30, Richard Damon wrote: > On 11/29/22 7:56 AM, A wrote: > > On Tuesday, 29 November 2022 at 18:13:24 UTC+5:30, Ben Bacarisse wrote: > >> A <amit2342...@gmail.com> writes: > >> > >>> On Tuesday, 29 November 2022 at 16:59:55 UTC+5:30, Richard Damon wrote: > > > > My only argument is that the variable type should be 'long' instead of 'size_t' when a negative value can crash the system which has the variable type as 'size_t'. > But still most of the positive values that it can't check for will break > the program or crash the system. > Then according to this argument, why to check pointers for NULL value? Pointers can have non-null values which may point to invalid memory location for that program and so when these pointers are used, the system will crash. So, checking for NULL is not saving a crash. And then, according to this argument, no function should check for validity of any argument - let the user do all the validation. Amit
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web