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 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-29 18:53 -0500 |
| Message-ID | <YXwhL.9954$pem1.3943@fx10.iad> |
| In reply to | #168383 |
On 11/29/22 8:18 AM, A wrote: > 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 Depends on the definition of the function. Sometimes, functions are have defined behavior for what might be considered "invalid" arguements for a number of reasons. But yes, for maximum efficiency, pushing requirements to callers is often faster. But, if checking is normally needed, it may be faster to always check in the function to make the program smaller and thus use less cache, Note, if the pointer might ligitametly be NULL, then you do need to check the value. If you require your caller to never give you a NULL pointer, then you don't need to (but might want to have a ASSERT to verify in debug, or if efficiency isn't critical, as defensive programming.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2022-12-10 16:04 +0000 |
| Message-ID | <tn2alp$1m7am$2@dont-email.me> |
| In reply to | #168383 |
On 29/11/2022 13:18, A wrote: > 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. > On a few very rare cases I've wanted to read from or write to the zero address (embedded systems and boot roms). A NULL check would prevent me using memcpy. And as to why it's long? I think the answer is the memcpy was around a long time before size_t. Andy
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-11-29 17:19 +0000 |
| Message-ID | <878rjtekzm.fsf@bsb.me.uk> |
| In reply to | #168381 |
A <amit234234234234@gmail.com> writes: > 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'. What about cases where long is wider than size_t? What about cases where long is narrower than 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. Not so. No checks are needed for code like memcpy(&pkt_header, received_data, sizeof pkt_header); -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-29 18:55 -0500 |
| Message-ID | <GZwhL.7789$jHT4.7205@fx06.iad> |
| In reply to | #168384 |
On 11/29/22 12:19 PM, Ben Bacarisse wrote: > A <amit234234234234@gmail.com> writes: > >> 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'. > > What about cases where long is wider than size_t? What about cases > where long is narrower than 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. > > Not so. No checks are needed for code like > > memcpy(&pkt_header, received_data, sizeof pkt_header); > Actually, if received_data is smaller than pkt_header, then there is a small chance that reading past the end of the data could trigger an problem.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2022-11-30 00:02 +0000 |
| Message-ID | <74xhL.9875$f9D6.3099@fx09.iad> |
| In reply to | #168394 |
On 2022-11-29, Richard Damon <Richard@Damon-Family.org> wrote: > On 11/29/22 12:19 PM, Ben Bacarisse wrote: >> A <amit234234234234@gmail.com> writes: >> >>> 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'. >> >> What about cases where long is wider than size_t? What about cases >> where long is narrower than 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. >> >> Not so. No checks are needed for code like >> >> memcpy(&pkt_header, received_data, sizeof pkt_header); >> > > Actually, if received_data is smaller than pkt_header, then there is a > small chance that reading past the end of the data could trigger an problem. We don't know size of received_data, supposition is that it is larger then header. I guess that necessary checks are done before that line... -- 7-77-777 Evil Sinner! with software, you repeat same experiment, expecting different results...
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-11-30 01:58 +0000 |
| Message-ID | <87pmd5cifh.fsf@bsb.me.uk> |
| In reply to | #168394 |
Richard Damon <Richard@Damon-Family.org> writes: > On 11/29/22 12:19 PM, Ben Bacarisse wrote: >> A <amit234234234234@gmail.com> writes: >>> Arguments have to be checked by someone - either by the user or by >>> memcpy(). So, the cost is the same. >> >> Not so. No checks are needed for code like >> >> memcpy(&pkt_header, received_data, sizeof pkt_header); > > Actually, if received_data is smaller than pkt_header, then there is a > small chance that reading past the end of the data could trigger an > problem. Of course, but I chose the names to suggest a situation that is safe without having to give all the declarations and so on. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-29 10:21 -0800 |
| Message-ID | <87tu2hk4fa.fsf@nosuchdomain.example.com> |
| In reply to | #168376 |
A <amit234234234234@gmail.com> writes:
> 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.
How do you know it will crash?
It's not possible to pass a negative value to memcpy(). It is possible
to use a negative value as an argument, but it will be implicitly
converted to size_t before being passed.
Yes, if you pass -1 as the size argument, it will result in memcpy()
receiving SIZE_MAX. This will *probably* result in undefined behavior,
because it *probably* exceeds the size of the source and/or target
object, and likely the maximum object size the implementation supports.
There is no guarantee that it will crash. In the worst case, it will
quietly copy more memory than you intended, corrupt memory past the end
of the target object, and result in arbitrary misbehavior later on.
So don't do that.
Seriously, passing a negative value to memcpy() would be a bug, but it's
not one that I've ever encountered as far as I know. Programs don't
call memcpy() with a size argument obtained from unchecked user input.
Have you ever encountered such a bug?
You propose changing the way the language defines memcpy() (and a
plethora of other functions) to avoid an error that hardly ever occurs.
And it's just one of a number of possible errors, such as passing a
pointer to an object that no longer exists, computing the size
incorrectly in a way that still yields a positive value, trying to copy
overlapping objects, passing a pointer to the wrong object, reversing
the source and destination pointers, etc.
It's not possible to guard against all these errors. It might be
possible to build an interface *on top of* memcpy() that guards against
many of them.
> 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__
>
> }
No, it shouldn't.
The use of size_t by memcpy() is mandated by the ISO C standard.
I believe that's been mentioned here a number of times.
The standard (nearly) guarantees that the size of any object can be
represented by a value of type size_t. It makes no such guarantee for
type long. And in fact modern Windows has 32-bit long and 64-bit
size_t, and you could have an object whose size requires 33 or more bits
to represent it. I believe that's also been mentioned here a number of
times. You haven't suggested how that should be addressed.
> 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.
At what cost? (And again, a crash is not guaranteed.)
> 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.
Yes, bugs happen. I do not suggest radically changing an aspect of the
language (abandoning size_t) to prevent one very rare class of bug.
> 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.
That would be the fault of the programmer who passed an unchecked value
to memcpy().
> 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.
They shouldn't be able to. A user typing the string "-1" on standard
input should never result in a value of -1 being passed to memcpy().
There needs to be a lot more checking between user input and low-level
function calls.
> 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.
Why are you still talking about glibc? glibc implements these functions
as specifed by the C standard. It cannot change them. Your disgreement
is with the way they're defined by the C standard.
If I agreed with your underlying point, I would not suggest using long.
I would suggest that the type used to represent sizes should be a a
signed type rather than an unsigned type. I would suggest standardizing
the POSIX signed integer type ssize_t (which can be defined
appropriately for each implementation) and using that as the parameter
for memcpy(), and deprecating the unsigned type size_t.
Again, I do not agree with your underlying point. Accidentally passing
a negative value to memcpy() is a rare error, one that I don't think
I've ever seen, and that's the entire rationale for your suggestion.
But even I agreed, changing memcpy()'s parameter type from size_t to
long would be the wrong answer.
If you want the kind of memory safety you're looking for, there are
other languages that (attempt to) provide it. (Many of them are
implemented in C.)
--
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 | Opus <ifonly@youknew.org> |
|---|---|
| Date | 2022-11-29 19:42 +0100 |
| Message-ID | <tm5jr3$1u8f$1@gioia.aioe.org> |
| In reply to | #168385 |
Le 29/11/2022 à 19:21, Keith Thompson a écrit : > It's not possible to pass a negative value to memcpy(). It is possible > to use a negative value as an argument, but it will be implicitly > converted to size_t before being passed. Yep. As I think I mentioned, enabling the right compiler warning, the compiler will catch that anyway (both passing a negative value for an unsigned argument, and passing a signed variable. Use proper tools, use static analysis. Use the fricking -Wconversion option for GCC (or CLang.) Other compilers probably have something similar. Why twist standard lib functions when compilers can catch this error with no overhead? I'm all for parameter validation - I'm a big proponent of that - but in this case, it doesn't make any sense. Passing a negative value/signed variable to an unsigned parameter is a 'semantic' error and can be caught easily with static analysis. The question would not even be raised for a strongly-typed language; C is not strongly-typed, but using the proper compiler options and/or third-party static analysis tools, this kind of issues disappears almost entirely. Fricking use them. Seriously. And use parameters with the right semantic. malloc() expects an unsigned parameter. It definitely SHOULD be declared as unsigned. Otherwise the signature of the function would suggest that negative values would be part of its domain, when it's not. I'm again all for run-time parameter validation, but when it can be validated statically, it serves no purpose. As to not being strongly-typed... If I had anything to complain about C, it would be its implicit conversions. That again can be mitigated with some compiler options or separate static analysis tools, but I don't think those implicit conversions were ever a good idea.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-11-29 19:00 +0000 |
| Message-ID | <aFshL.6$MGw.2@fx16.iad> |
| In reply to | #168385 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >A <amit234234234234@gmail.com> writes: >> On Monday, 28 November 2022 at 05:26:26 UTC+5:30, Scott Lurndal wrote: <snip> >> >> Is size_t usage justified in memcpy()? If a user passes a negative >> number by mistake then memcpy() will crash. > <snip> >Seriously, passing a negative value to memcpy() would be a bug, but it's >not one that I've ever encountered as far as I know. Programs don't >call memcpy() with a size argument obtained from unchecked user input. >Have you ever encountered such a bug? > >You propose changing the way the language defines memcpy() (and a >plethora of other functions) to avoid an error that hardly ever occurs. >And it's just one of a number of possible errors, such as passing a >pointer to an object that no longer exists, computing the size >incorrectly in a way that still yields a positive value, trying to copy >overlapping objects, passing a pointer to the wrong object, reversing >the source and destination pointers, etc. > >It's not possible to guard against all these errors. It might be >possible to build an interface *on top of* memcpy() that guards against >many of them. At one of the X/Open meetings mid 90s, we considered adding EFAULT as a return code from memcpy/memset/memmove and the str* functions, but decided the overhead required to support it was excessive at the time (e.g. each call to mem* or str* functions would establish a signal handler for SIGSEGV and SIGBUS, and restore the original handler(s) before returning). That said, SuS/Posix does allow an implementation to return error codes that are not explicitly defined by the specification, so an implementation can add that capability if needed.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-29 13:47 -0800 |
| Message-ID | <87pmd5juvt.fsf@nosuchdomain.example.com> |
| In reply to | #168387 |
scott@slp53.sl.home (Scott Lurndal) writes:
[...]
> At one of the X/Open meetings mid 90s, we considered adding EFAULT
> as a return code from memcpy/memset/memmove and the str*
> functions, but decided the overhead required to support it
> was excessive at the time (e.g. each call to mem* or str*
> functions would establish a signal handler for SIGSEGV
> and SIGBUS, and restore the original handler(s) before
> returning).
>
> That said, SuS/Posix does allow an implementation to return
> error codes that are not explicitly defined by the specification,
> so an implementation can add that capability if needed.
memcpy() returns a void*. C specifies that it returns a pointer to the
destination object. POSIX says pretty much the same thing:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/memcpy.html
The memcpy() function shall return s1; no return value is reserved
to indicate an error.
...
No errors are defined.
...
The memcpy() function does not check for the overflow of the
receiving memory area.
Of course it could return anything it likes in cases of undefined
behavior, but neither C nor POSIX says so explicitly.
Was the proposal was to set errno? Setting errno and returning a null
pointer could make sense. (Returning EFAULT from a void* function would
be awkward.)
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-11-29 22:45 +0000 |
| Message-ID | <dYvhL.5425$KVI.4413@fx14.iad> |
| In reply to | #168391 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >scott@slp53.sl.home (Scott Lurndal) writes: >[...] >> At one of the X/Open meetings mid 90s, we considered adding EFAULT >> as a return code from memcpy/memset/memmove and the str* >> functions, but decided the overhead required to support it >> was excessive at the time (e.g. each call to mem* or str* >> functions would establish a signal handler for SIGSEGV >> and SIGBUS, and restore the original handler(s) before >> returning). >> >> That said, SuS/Posix does allow an implementation to return >> error codes that are not explicitly defined by the specification, >> so an implementation can add that capability if needed. > >memcpy() returns a void*. C specifies that it returns a pointer to the >destination object. POSIX says pretty much the same thing: As usual with such functions, the intent was to set errno to zero before calling malloc, and checking it afterwords. > >Was the proposal was to set errno? Setting errno and returning a null >pointer could make sense. (Returning EFAULT from a void* function would >be awkward.) Yes, that was the proposal - I wasn't clear above.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-11-30 00:42 -0800 |
| Message-ID | <tm750v$2g9me$1@dont-email.me> |
| In reply to | #168370 |
On 11/27/2022 3:56 PM, Scott Lurndal wrote: > "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. Nice. Fwiw, Microsoft has the handy function that makes constructing cohorts rather "easy, ish" in IOCP: https://learn.microsoft.com/en-us/windows/win32/fileio/getqueuedcompletionstatusex-func Iirc, this was not available in nt 4.0
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-11-30 00:44 -0800 |
| Message-ID | <tm755h$2g9me$2@dont-email.me> |
| In reply to | #168398 |
On 11/30/2022 12:42 AM, Chris M. Thomasson wrote: > On 11/27/2022 3:56 PM, Scott Lurndal wrote: >> "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. > > Nice. Fwiw, Microsoft has the handy function that makes constructing > cohorts rather "easy, ish" in IOCP: > > https://learn.microsoft.com/en-us/windows/win32/fileio/getqueuedcompletionstatusex-func > > Iirc, this was not available in nt 4.0 > One of the infamous ex postfixed ms functions... ;^D
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-30 23:31 -0800 |
| Message-ID | <e3434e66-f73d-4afb-b382-03182427f1adn@googlegroups.com> |
| In reply to | #168399 |
So, let's say a developer wrote some code like this:
error_t copy_bytes(void *dest, const void *src, long n)
{
if ((!dest) || (!src))
return ENULL;
if (n < 0)
return ENEGATIVESIZE;
memcpy(dest, src, size_t(n));
return ESUCCESS;
}
Now, the above code comes to you for review.
So, will you tell the developer to use size_t for 'n' or let the developer keep using long for 'n'.
Amit
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-30 23:35 -0800 |
| Message-ID | <25a406de-f919-48a0-858a-f40ba3fa9d1en@googlegroups.com> |
| In reply to | #168407 |
On Thursday, 1 December 2022 at 13:01:21 UTC+5:30, A wrote:
> So, let's say a developer wrote some code like this:
>
> error_t copy_bytes(void *dest, const void *src, long n)
> {
>
> if ((!dest) || (!src))
> return ENULL;
>
> if (n < 0)
> return ENEGATIVESIZE;
>
> memcpy(dest, src, size_t(n));
>
> return ESUCCESS;
>
> }
>
> Now, the above code comes to you for review.
>
> So, will you tell the developer to use size_t for 'n' or let the developer keep using long for 'n'.
>
> Amit
I forgot the brackets around size_t in memcpy(dest, src, size_t(n)). It should be memcpy(dest, src, (size_t)(n)).
Amit
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-01 09:08 +0100 |
| Message-ID | <tm9nee$2oso4$1@dont-email.me> |
| In reply to | #168408 |
On 01/12/2022 08:35, A wrote:
> On Thursday, 1 December 2022 at 13:01:21 UTC+5:30, A wrote:
>> So, let's say a developer wrote some code like this:
>>
>> error_t copy_bytes(void *dest, const void *src, long n)
>> {
>>
>> if ((!dest) || (!src))
>> return ENULL;
>>
>> if (n < 0)
>> return ENEGATIVESIZE;
>>
>> memcpy(dest, src, size_t(n));
>>
>> return ESUCCESS;
>>
>> }
>>
>> Now, the above code comes to you for review.
>>
>> So, will you tell the developer to use size_t for 'n' or let the developer keep using long for 'n'.
>>
>> Amit
>
> I forgot the brackets around size_t in memcpy(dest, src, size_t(n)). It should be memcpy(dest, src, (size_t)(n)).
>
> Amit
>
Or just "memcpy(dest, src, n);". There is no need to cast to "size_t",
as any needed conversions are done automatically when calling the
function (assuming you have #include <strings.h>). And there is no need
for parentheses around "n" either.
(You really should get a proper newsclient and proper newsserver -
Thunderbird and news.eternal-september.org are a free and popular
combination, though there are many other options. Google groups can't
handle code snippets properly and messes up indentation - this is a
really bad thing for a language newsgroup.)
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-12-02 04:23 -0800 |
| Message-ID | <801289ca-529b-41e2-a88e-e1c3f24620e3n@googlegroups.com> |
| In reply to | #168410 |
On Thursday, 1 December 2022 at 13:39:01 UTC+5:30, David Brown wrote:
> On 01/12/2022 08:35, A wrote:
> > On Thursday, 1 December 2022 at 13:01:21 UTC+5:30, A wrote:
> >> So, let's say a developer wrote some code like this:
> >>
> >> error_t copy_bytes(void *dest, const void *src, long n)
> >> {
> >>
> >> if ((!dest) || (!src))
> >> return ENULL;
> >>
> >> if (n < 0)
> >> return ENEGATIVESIZE;
> >>
> >> memcpy(dest, src, size_t(n));
> >>
> >> return ESUCCESS;
> >>
> >> }
> >>
> >> Now, the above code comes to you for review.
> >>
> >> So, will you tell the developer to use size_t for 'n' or let the developer keep using long for 'n'.
> >>
> >> Amit
> >
> > I forgot the brackets around size_t in memcpy(dest, src, size_t(n)). It should be memcpy(dest, src, (size_t)(n)).
> >
> > Amit
> >
> Or just "memcpy(dest, src, n);". There is no need to cast to "size_t",
> as any needed conversions are done automatically when calling the
> function (assuming you have #include <strings.h>). And there is no need
> for parentheses around "n" either.
I use gcc with many flags. One of them is -Wconversion. When this flag is specified, gcc gives a warning when converting long to size_t without cast.
warning: conversion to ‘size_t’ {aka ‘long unsigned int’} from ‘long int’ may change the sign of the result [-Wsign-conversion]
Amit
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-03 16:42 +0100 |
| Message-ID | <tmfqpu$3cclu$2@dont-email.me> |
| In reply to | #168438 |
On 02/12/2022 13:23, A wrote:
> On Thursday, 1 December 2022 at 13:39:01 UTC+5:30, David Brown wrote:
>> On 01/12/2022 08:35, A wrote:
>>> On Thursday, 1 December 2022 at 13:01:21 UTC+5:30, A wrote:
>>>> So, let's say a developer wrote some code like this:
>>>>
>>>> error_t copy_bytes(void *dest, const void *src, long n)
>>>> {
>>>>
>>>> if ((!dest) || (!src))
>>>> return ENULL;
>>>>
>>>> if (n < 0)
>>>> return ENEGATIVESIZE;
>>>>
>>>> memcpy(dest, src, size_t(n));
>>>>
>>>> return ESUCCESS;
>>>>
>>>> }
>>>>
>>>> Now, the above code comes to you for review.
>>>>
>>>> So, will you tell the developer to use size_t for 'n' or let the developer keep using long for 'n'.
>>>>
>>>> Amit
>>>
>>> I forgot the brackets around size_t in memcpy(dest, src, size_t(n)). It should be memcpy(dest, src, (size_t)(n)).
>>>
>>> Amit
>>>
>> Or just "memcpy(dest, src, n);". There is no need to cast to "size_t",
>> as any needed conversions are done automatically when calling the
>> function (assuming you have #include <strings.h>). And there is no need
>> for parentheses around "n" either.
>
> I use gcc with many flags. One of them is -Wconversion. When this flag is specified, gcc gives a warning when converting long to size_t without cast.
>
> warning: conversion to ‘size_t’ {aka ‘long unsigned int’} from ‘long int’ may change the sign of the result [-Wsign-conversion]
>
Warnings are a sign that you might be doing something risky,
non-portable, or which might have effects or results that are not
immediately apparent from the source code. And casts are a way of
saying "I know what I am doing even though it is a bid odd". While
casts are, therefore, more commonly useful in code that is compiled with
high warning levels, both disappear in situations like this when you use
the appropriate types in the first place.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-12-01 02:47 -0500 |
| Message-ID | <tm9m68$2oesk$2@dont-email.me> |
| In reply to | #168407 |
On 12/1/22 02:31, A wrote:
>
> So, let's say a developer wrote some code like this:
>
> error_t copy_bytes(void *dest, const void *src, long n)
> {
>
> if ((!dest) || (!src))
> return ENULL;
>
> if (n < 0)
> return ENEGATIVESIZE;
>
> memcpy(dest, src, size_t(n));
>
> return ESUCCESS;
>
> }
>
> Now, the above code comes to you for review.
>
> So, will you tell the developer to use size_t for 'n' or let the developer keep using long for 'n'.
If LONG_MAX > SIZE_MAX, this code fails to catch all of the possible
erroneous values for n. It should be if(n < 0 || n > SIZE_MAX).
If LONG_MAX < SIZE_MAX, this code prevents copying of blocks of memory
that memcpy() could be used for.
Keep in mind that LONG_MAX can be (and on some real-world systems, has
been) either much larger than SIZE_MAX, or much smaller than it, so
these are not minor quibbles. For instance, long might be a 64 bit type,
while size_t could be a 32 bit type, or vice-versa.
The third argument of memcpy() will be implicitly converted to size_t,
there's no need to do so explicitly. Also, this is comp.lang.c, not
comp.lang.c++. the correct syntax is (size_t)n, not size_t(n).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-01 09:14 +0100 |
| Message-ID | <tm9nou$2othu$1@dont-email.me> |
| In reply to | #168409 |
On 01/12/2022 08:47, James Kuyper wrote:
> On 12/1/22 02:31, A wrote:
>>
>> So, let's say a developer wrote some code like this:
>>
>> error_t copy_bytes(void *dest, const void *src, long n)
>> {
>>
>> if ((!dest) || (!src))
>> return ENULL;
>>
>> if (n < 0)
>> return ENEGATIVESIZE;
>>
>> memcpy(dest, src, size_t(n));
>>
>> return ESUCCESS;
>>
>> }
>>
>> Now, the above code comes to you for review.
>>
>> So, will you tell the developer to use size_t for 'n' or let the developer keep using long for 'n'.
>
> If LONG_MAX > SIZE_MAX, this code fails to catch all of the possible
> erroneous values for n. It should be if(n < 0 || n > SIZE_MAX).
>
> If LONG_MAX < SIZE_MAX, this code prevents copying of blocks of memory
> that memcpy() could be used for.
>
> Keep in mind that LONG_MAX can be (and on some real-world systems, has
> been) either much larger than SIZE_MAX, or much smaller than it, so
> these are not minor quibbles. For instance, long might be a 64 bit type,
> while size_t could be a 32 bit type, or vice-versa.
>
It is not just "has been", but "is". On 64-bit Windows (which, I hear,
is quite popular in some circles) you have 64-bit "size_t" and 32-bit
"long".
On 8-bit and 16-bit microcontrollers - which outsell 64-bit processors
by a long way - you have 16-bit "size_t" and 32-bit "long".
> The third argument of memcpy() will be implicitly converted to size_t,
> there's no need to do so explicitly. Also, this is comp.lang.c, not
> comp.lang.c++. the correct syntax is (size_t)n, not size_t(n).
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web