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 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-12-01 10:04 -0800 |
| Message-ID | <87h6yfj90p.fsf@nosuchdomain.example.com> |
| In reply to | #168407 |
A <amit234234234234@gmail.com> writes:
> 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'.
Presumably the syntax error would have been corrected (as you did in a
followup) before it came to me for review.
I'd tell the developer to use size_t, for reasons that have already been
repeatedly discussed in this thread.
--
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-12-01 19:14 +0000 |
| Message-ID | <u27iL.6668$jXi9.2399@fx34.iad> |
| In reply to | #168416 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>A <amit234234234234@gmail.com> writes:
>> 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'.
>
>Presumably the syntax error would have been corrected (as you did in a
>followup) before it came to me for review.
>
>I'd tell the developer to use size_t, for reasons that have already been
>repeatedly discussed in this thread.
>
I'd also suggest he use existing errno values to avoid potential conflicts
in the future.
ENULL -> EFAULT
ENEGATIVESIZE -> EINVAL
ESUCCESS -> 0
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-12-02 04:49 -0800 |
| Message-ID | <d2243be8-ca0b-4c4a-8c1f-6a228b554109n@googlegroups.com> |
| In reply to | #168416 |
On Thursday, 1 December 2022 at 23:34:21 UTC+5:30, Keith Thompson wrote:
> A <amit2342...@gmail.com> writes:
> > 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'.
> Presumably the syntax error would have been corrected (as you did in a
> followup) before it came to me for review.
>
> I'd tell the developer to use size_t, for reasons that have already been
> repeatedly discussed in this thread.
So, basically, if the developer wants to check for negative values, you don't want the developer to do that.
Amit
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-12-02 05:13 -0800 |
| Message-ID | <d8f328a5-12c1-4223-b3c8-299df58120d5n@googlegroups.com> |
| In reply to | #168439 |
On Friday, 2 December 2022 at 18:19:29 UTC+5:30, A wrote:
> On Thursday, 1 December 2022 at 23:34:21 UTC+5:30, Keith Thompson wrote:
> > A <amit2342...@gmail.com> writes:
> > > 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'.
> > Presumably the syntax error would have been corrected (as you did in a
> > followup) before it came to me for review.
> >
> > I'd tell the developer to use size_t, for reasons that have already been
> > repeatedly discussed in this thread.
> So, basically, if the developer wants to check for negative values, you don't want the developer to do that.
>
> Amit
Basically, my point is that if something is specified in the standard, then it doesn't mean that it should be used by everyone. After all, the standard was defined by humans only.
Multiple inheritance is a feature of C++. But google recommends its developers to not use multiple inheritance when writing C++ code. So, google is not following C++ standards completely. So, do you think that google is wrong?
What I am saying is that size_t may be preferred by many people. But many people may not like it size_t. They may want to use long. So, why force them to use size_t when using long is not introducing any bug?
I thought a lot about why would they specify size_t in the C standard in memcpy(), etc. - the only reason that comes to my mind is that they thought that they don't know what kind of systems will come in the future. So, why to restrict the developer by using a signed type. Instead, give the user the whole range.
But some people said that the size of type size_t differs according in various systems/implementations. Again, defining this kind of size_t is wrong.
If you really want to address the whole memory range (so that the user is not restricted because no one knows what kind of systems may come in future), the size of type size_t should be set equal to the width of the address bus of the system to address the whole memory range (whether available or not) (and probably get this value dynamically).
Amit
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-12-02 07:17 -0800 |
| Message-ID | <b085202a-b604-4a6c-99ca-ea4fc1ff2dd0n@googlegroups.com> |
| In reply to | #168440 |
On Friday, 2 December 2022 at 15:13:34 UTC+2, A wrote:
> On Friday, 2 December 2022 at 18:19:29 UTC+5:30, A wrote:
> > On Thursday, 1 December 2022 at 23:34:21 UTC+5:30, Keith Thompson wrote:
> > > A <amit2342...@gmail.com> writes:
> > > > 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'.
> > > Presumably the syntax error would have been corrected (as you did in a
> > > followup) before it came to me for review.
> > >
> > > I'd tell the developer to use size_t, for reasons that have already been
> > > repeatedly discussed in this thread.
> > So, basically, if the developer wants to check for negative values, you don't want the developer to do that.
> >
> > Amit
> Basically, my point is that if something is specified in the standard, then it doesn't mean that it should be used by everyone. After all, the standard was defined by humans only.
Yes, everybody may do whatever they want to in their own code. Just
that when they want to cooperate with others and achieve efficient
products then it is worth to try to synchronise style and to use
techniques that are easy for compiler too.
>
> Multiple inheritance is a feature of C++. But google recommends its developers to not use multiple inheritance when writing C++ code. So, google is not following C++ standards completely. So, do you think that google is wrong?
C++ is large language. Everybody use only some subset of it.
Google style guide actually says that:
"Multiple inheritance is permitted, but multiple implementation
inheritance is strongly discouraged."
Actually virtual functions of multiple implementation inheritance
are complex to follow logically and quite a trick to pull for compiler so
those cause way more noticeable performance losses than virtual
functions of single implementation inheritance. So the rule makes
sense.
>
> What I am saying is that size_t may be preferred by many people. But many people may not like it size_t. They may want to use long. So, why force them to use size_t when using long is not introducing any bug?
Lot of people are used to use size_t as count of something, especially
bytes. It is easier to cooperate with them. The sizeof operator of
language returns size_t. The memcpy needs size_t argument. It is easier to
cooperate with language using size_t. So from where that long somehow
got there? Just that "I want to want differently than language and
other programmers"? It is irrational want, unlike that Google rule.
>
> I thought a lot about why would they specify size_t in the C standard in memcpy(), etc. - the only reason that comes to my mind is that they thought that they don't know what kind of systems will come in the future. So, why to restrict the developer by using a signed type. Instead, give the user the whole range.
Most likely it was so because all throughout history the natural numbers
are used for counting and ordering and natural numbers can't be negative.
So unsigned number of C makes better sense to be used as count, a
natural number.
>
> But some people said that the size of type size_t differs according in various systems/implementations. Again, defining this kind of size_t is wrong.
That is same with long whose size in bits differs in various systems
so it does not make any difference in that sense.
>
> If you really want to address the whole memory range (so that the user is not restricted because no one knows what kind of systems may come in future), the size of type size_t should be set equal to the width of the address bus of the system to address the whole memory range (whether available or not) (and probably get this value dynamically).
That does not make sense. Run-time dynamic bit width of types?
That likely hits performance rather badly. Why such nonsense is
needed? Especially on the 8 or 16 bit controllers where we indeed
might want to address whole available memory range.
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-12-02 08:07 -0800 |
| Message-ID | <b8cdc381-67ea-4037-aa0b-2f9ea99a23e7n@googlegroups.com> |
| In reply to | #168441 |
On Friday, 2 December 2022 at 20:48:00 UTC+5:30, Öö Tiib wrote:
> On Friday, 2 December 2022 at 15:13:34 UTC+2, A wrote:
> > On Friday, 2 December 2022 at 18:19:29 UTC+5:30, A wrote:
> > > On Thursday, 1 December 2022 at 23:34:21 UTC+5:30, Keith Thompson wrote:
> > > > A <amit2342...@gmail.com> writes:
> > > > > 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'.
> > > > Presumably the syntax error would have been corrected (as you did in a
> > > > followup) before it came to me for review.
> > > >
> > > > I'd tell the developer to use size_t, for reasons that have already been
> > > > repeatedly discussed in this thread.
> > > So, basically, if the developer wants to check for negative values, you don't want the developer to do that.
> > >
> > > Amit
> > Basically, my point is that if something is specified in the standard, then it doesn't mean that it should be used by everyone. After all, the standard was defined by humans only.
> Yes, everybody may do whatever they want to in their own code. Just
> that when they want to cooperate with others and achieve efficient
> products then it is worth to try to synchronise style and to use
> techniques that are easy for compiler too.
Your comment is non-sensical.
> >
> > Multiple inheritance is a feature of C++. But google recommends its developers to not use multiple inheritance when writing C++ code. So, google is not following C++ standards completely. So, do you think that google is wrong?
> C++ is large language. Everybody use only some subset of it.
> Google style guide actually says that:
> "Multiple inheritance is permitted, but multiple implementation
> inheritance is strongly discouraged."
> Actually virtual functions of multiple implementation inheritance
> are complex to follow logically and quite a trick to pull for compiler so
> those cause way more noticeable performance losses than virtual
> functions of single implementation inheritance. So the rule makes
> sense.
Your claims are wrong. Read this: https://google.github.io/styleguide/cppguide.html
> >
> > What I am saying is that size_t may be preferred by many people. But many people may not like it size_t. They may want to use long. So, why force them to use size_t when using long is not introducing any bug?
> Lot of people are used to use size_t as count of something, especially
> bytes. It is easier to cooperate with them. The sizeof operator of
> language returns size_t. The memcpy needs size_t argument. It is easier to
> cooperate with language using size_t. So from where that long somehow
> got there? Just that "I want to want differently than language and
> other programmers"? It is irrational want, unlike that Google rule.
> >
It looks like you haven't read the whole thread. I have clearly mentioned why I want to use long over size_t in memcpy().
> > I thought a lot about why would they specify size_t in the C standard in memcpy(), etc. - the only reason that comes to my mind is that they thought that they don't know what kind of systems will come in the future. So, why to restrict the developer by using a signed type. Instead, give the user the whole range.
> Most likely it was so because all throughout history the natural numbers
> are used for counting and ordering and natural numbers can't be negative.
> So unsigned number of C makes better sense to be used as count, a
> natural number.
> >
> > But some people said that the size of type size_t differs according in various systems/implementations. Again, defining this kind of size_t is wrong.
> That is same with long whose size in bits differs in various systems
> so it does not make any difference in that sense.
> >
> > If you really want to address the whole memory range (so that the user is not restricted because no one knows what kind of systems may come in future), the size of type size_t should be set equal to the width of the address bus of the system to address the whole memory range (whether available or not) (and probably get this value dynamically).
> That does not make sense. Run-time dynamic bit width of types?
> That likely hits performance rather badly. Why such nonsense is
> needed? Especially on the 8 or 16 bit controllers where we indeed
> might want to address whole available memory range.
This is not nonsense. Before writing anything please deliberate as to what you are writing. The compiler has to get the width when it is invoked, there is no run time penalty on executables.
Most of your comments are nonsense. It looks like you really don't know what is being talked about here.
I will explain again. I want to use long because I want to check if the user has passed me negative value. The user can input anything, so the user input has to be checked somewhere. The check is in the function or outside, it doesn't matter.
But after interacting with so many people here, it looks like to me that they will pass user input directly to memcpy(). But if they will check input "somewhere", then if i want to check the input in the function then what's wrong with it.
So, I don't know what the people are arguing against when they will check input somewhere.
Amit
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-02 16:32 +0000 |
| Message-ID | <OMpiL.20041$3SM3.5872@fx45.iad> |
| In reply to | #168442 |
A <amit234234234234@gmail.com> writes: >On Friday, 2 December 2022 at 20:48:00 UTC+5:30, =C3=96=C3=B6 Tiib wrote: >I will explain again. I want to use long because I want to check if the use= >r has passed me negative value. The user can input anything, so the user i= >nput has to be checked somewhere. The check is in the function or outside, = >it doesn't matter. Use long as the type of the variable to which the result of strtol is assigned. Cast that to a size_t if the value is positive, and produce an error message if it is negative. And pass the size_t to any function whose signature requires a size_t. It's not that hard.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-12-02 16:58 +0000 |
| Message-ID | <tmdarg$15hl$1@gioia.aioe.org> |
| In reply to | #168442 |
On 02/12/2022 16:07, A wrote: > I will explain again. I want to use long because I want to check if the user has passed me negative value. Why just negative, rather than a value that is too small, or too big, or massively big (like 9000000000000000000 bytes if using a 64-bit long)? Out of 2**64 possible inputs, if you really only want to check for half of wrong inputs, then just use u64 and check the value is under 2**63, but see below. > The user can input anything, so the user input has to be checked somewhere. The check is in the function or outside, it doesn't matter. > But after interacting with so many people here, it looks like to me that they will pass user input directly to memcpy(). Under what circumstances would a user decide what goes into a memcpy call? Presumably the user's input would first have to be used to allocate dynamic memory to create a destination and/or source buffer, where it would get checked first. > But if they will check input "somewhere", then if i want to check the input in the function then what's wrong with it. Because the function will have no idea what the correct value is. Let's put it this way: if you passed a random u64 value as the count to memcpy(), you are partitioning all those values into two, and discarding one half. But what about the other 2**63-1 wrong values? It is pointless. If you only want a very broad check, use u64 and check the value is under 2**26 or 2**28, or whatever you consider is a plausible maximum value for the size of one memory block in one task. Checking for under 2**63 (your negative check) is a waste of time. More important is ensuring the count is exact; that has to be done inside the caller, using more information than just checking for values above 2**63 (what the check for negative is).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-12-02 12:46 -0800 |
| Message-ID | <874judjzyu.fsf@nosuchdomain.example.com> |
| In reply to | #168442 |
A <amit234234234234@gmail.com> writes:
[...]
> I will explain again. I want to use long because I want to check if
> the user has passed me negative value. The user can input anything,
> so the user input has to be checked somewhere. The check is in the
> function or outside, it doesn't matter.
>
> But after interacting with so many people here, it looks like to me
> that they will pass user input directly to memcpy(). But if they will
> check input "somewhere", then if i want to check the input in the
> function then what's wrong with it.
>
> So, I don't know what the people are arguing against when they will
> check input somewhere.
I'm curious where you got the idea that anyone is passing unchecked user
input to memcpy().
The size argument to memcpy() is typically computed. Sometimes
it might just be sizeof applied to some type or object, perhaps
muliplied by a count. Sometimes it might be some more complex
calculation, or a configurable buffer size. That calculation *might*
be based in part on user input, but usually it won't be.
An end user of a program very likely won't know how many bytes need to
be copied, or even that memcpy() is being called.
Sure, a program *could* do something like:
printf("How many bytes do you want to copy? ");
scanf("%ld\n", &count);
memcpy(target, source, count);
and blow up if the user enters "-1", but that would be, you know,
insane.
Take a look at the source code for any open source project and search
for calls to memcpy, and let us know if any of them are actually
vulnerable to the problems you're so worried about.
--
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 | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-12-02 21:32 -0800 |
| Message-ID | <b2167bb2-6695-481d-a984-f7fc0ab6d69dn@googlegroups.com> |
| In reply to | #168448 |
> > Take a look at the source code for any open source project and search > for calls to memcpy, and let us know if any of them are actually > vulnerable to the problems you're so worried about. What I am saying is that before calling memcpy(), the input from the user is being checked somewhere, at least, for negative values. So, we are not using the full range of size_t. So, then why do we need size_t, if we are not using its full range? And if before calling memcpy(), the input is being checked for negative values, then why not use long instead of size_t and also let memcpy() to make an extra check for negative values. Now, the issue will be of time lost in extra check but the way I code is that, for every function that I write, I don't trust the values passed to that function and so I check values passed for each argument and return INVALID_ARG if any of the values is not correct. Some extra time is taken, but from my point of view, this ensures more correctness and also less chances of system crashing / behaving wrongly when it goes live, out in the open for everyone to use it. Amit
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-02 21:41 -0800 |
| Message-ID | <tmenhh$39ung$4@dont-email.me> |
| In reply to | #168455 |
On 12/2/2022 9:32 PM, A wrote: > >> >> Take a look at the source code for any open source project and search >> for calls to memcpy, and let us know if any of them are actually >> vulnerable to the problems you're so worried about. > > What I am saying is that before calling memcpy(), the input from the user is being checked somewhere, at least, for negative values. So, we are not using the full range of size_t. So, then why do we need size_t, if we are not using its full range? And if before calling memcpy(), the input is being checked for negative values, then why not use long instead of size_t and also let memcpy() to make an extra check for negative values. > > Now, the issue will be of time lost in extra check but the way I code is that, for every function that I write, I don't trust the values passed to that function and so I check values passed for each argument and return INVALID_ARG if any of the values is not correct. > > Some extra time is taken, but from my point of view, this ensures more correctness and also less chances of system crashing / behaving wrongly when it goes live, out in the open for everyone to use it. If I create an API, and rules for using it... Then I expect programmers to follow the rules. Or, else! A nasal demon will manifest, and have hyper powerful breath, claw and tail whip attack weapons.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-02 21:42 -0800 |
| Message-ID | <tmenjv$39ung$5@dont-email.me> |
| In reply to | #168457 |
On 12/2/2022 9:41 PM, Chris M. Thomasson wrote: > On 12/2/2022 9:32 PM, A wrote: >> >>> >>> Take a look at the source code for any open source project and search >>> for calls to memcpy, and let us know if any of them are actually >>> vulnerable to the problems you're so worried about. >> >> What I am saying is that before calling memcpy(), the input from the >> user is being checked somewhere, at least, for negative values. So, we >> are not using the full range of size_t. So, then why do we need >> size_t, if we are not using its full range? And if before calling >> memcpy(), the input is being checked for negative values, then why not >> use long instead of size_t and also let memcpy() to make an extra >> check for negative values. >> >> Now, the issue will be of time lost in extra check but the way I code >> is that, for every function that I write, I don't trust the values >> passed to that function and so I check values passed for each argument >> and return INVALID_ARG if any of the values is not correct. >> >> Some extra time is taken, but from my point of view, this ensures more >> correctness and also less chances of system crashing / behaving >> wrongly when it goes live, out in the open for everyone to use it. > > If I create an API, and rules for using it... Then I expect programmers > to follow the rules. Or, else! A nasal demon will manifest, and have > hyper powerful breath, claw and tail whip attack weapons. > Actually, I remember some old drawings of mine of the so-called: Codan the Barbarian That would club attack programmers for shit like void main() in C/C++.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-02 21:49 -0800 |
| Message-ID | <tmeo1d$39ung$6@dont-email.me> |
| In reply to | #168458 |
On 12/2/2022 9:42 PM, Chris M. Thomasson wrote: > On 12/2/2022 9:41 PM, Chris M. Thomasson wrote: >> On 12/2/2022 9:32 PM, A wrote: >>> >>>> >>>> Take a look at the source code for any open source project and search >>>> for calls to memcpy, and let us know if any of them are actually >>>> vulnerable to the problems you're so worried about. >>> >>> What I am saying is that before calling memcpy(), the input from the >>> user is being checked somewhere, at least, for negative values. So, >>> we are not using the full range of size_t. So, then why do we need >>> size_t, if we are not using its full range? And if before calling >>> memcpy(), the input is being checked for negative values, then why >>> not use long instead of size_t and also let memcpy() to make an extra >>> check for negative values. >>> >>> Now, the issue will be of time lost in extra check but the way I code >>> is that, for every function that I write, I don't trust the values >>> passed to that function and so I check values passed for each >>> argument and return INVALID_ARG if any of the values is not correct. >>> >>> Some extra time is taken, but from my point of view, this ensures >>> more correctness and also less chances of system crashing / behaving >>> wrongly when it goes live, out in the open for everyone to use it. >> >> If I create an API, and rules for using it... Then I expect >> programmers to follow the rules. Or, else! A nasal demon will >> manifest, and have hyper powerful breath, claw and tail whip attack >> weapons. >> > > Actually, I remember some old drawings of mine of the so-called: > > Codan the Barbarian > > That would club attack programmers for shit like void main() in C/C++. Fwiw, here is a dragon sketch of mine that Codan had to fight: The battle was brutal. Codan got heavily burned, and the dragon sustained heavy damage to one of its wings, and tail. https://fractalforums.org/gallery/1612-031222054905.jpeg
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-04 12:49 -0800 |
| Message-ID | <tmj148$3od8t$3@dont-email.me> |
| In reply to | #168457 |
On 12/2/2022 9:41 PM, Chris M. Thomasson wrote: > On 12/2/2022 9:32 PM, A wrote: >> >>> >>> Take a look at the source code for any open source project and search >>> for calls to memcpy, and let us know if any of them are actually >>> vulnerable to the problems you're so worried about. >> >> What I am saying is that before calling memcpy(), the input from the >> user is being checked somewhere, at least, for negative values. So, we >> are not using the full range of size_t. So, then why do we need >> size_t, if we are not using its full range? And if before calling >> memcpy(), the input is being checked for negative values, then why not >> use long instead of size_t and also let memcpy() to make an extra >> check for negative values. >> >> Now, the issue will be of time lost in extra check but the way I code >> is that, for every function that I write, I don't trust the values >> passed to that function and so I check values passed for each argument >> and return INVALID_ARG if any of the values is not correct. >> >> Some extra time is taken, but from my point of view, this ensures more >> correctness and also less chances of system crashing / behaving >> wrongly when it goes live, out in the open for everyone to use it. > > If I create an API, and rules for using it... Then I expect programmers > to follow the rules. Or, else! A nasal demon will manifest, and have > hyper powerful breath, claw and tail whip attack weapons. > I forgot bite attack. The nasal demon destroys the programmers computer. Then, decides to bite the programmer in half instead of cooking it first. Programmer Tartare?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-12-03 12:59 -0800 |
| Message-ID | <87cz902ogo.fsf@nosuchdomain.example.com> |
| In reply to | #168455 |
A <amit234234234234@gmail.com> writes:
>> Take a look at the source code for any open source project and search
>> for calls to memcpy, and let us know if any of them are actually
>> vulnerable to the problems you're so worried about.
I wrote the above. You deleted the attribution line. Don't do that.
> What I am saying is that before calling memcpy(), the input from the
> user is being checked somewhere, at least, for negative values. So, we
> are not using the full range of size_t. So, then why do we need
> size_t, if we are not using its full range? And if before calling
> memcpy(), the input is being checked for negative values, then why not
> use long instead of size_t and also let memcpy() to make an extra
> check for negative values.
Can you show us just one example where the size passed to memcpy() is
based directly on user input?
Can you show us just one example of a problem in real code caused by
passing a negative value to memcpy?
And while you're at it, can you answer the question I asked you about
Windows, where long is 32 bits and size_t is 64 bits, or are you just
going to ignore them?
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-12-04 11:54 -0500 |
| Message-ID | <tmijcv$3n615$1@dont-email.me> |
| In reply to | #168455 |
On 12/3/22 00:32, A wrote: > >> >> Take a look at the source code for any open source project and search >> for calls to memcpy, and let us know if any of them are actually >> vulnerable to the problems you're so worried about. > > What I am saying is that before calling memcpy(), the input from the > user is being checked somewhere, at least, for negative values. So, we > are not using the full range of size_t. Why not? You seem to think that the only way memcpy() is to pass to it directly a number of bytes provided by a user. By far the most common use, in my experience, is to pass memcpy() the total size of a number of objects of some type. That number will only rarely be directly provided by the user. It might not depend in any way upon user input, but if it does, it will usually depend upon user input only indirectly. However, the most important point is that the type will often have sizeof(type) > 1, so the number passed to memcpy() will usually be the product of sizeof(type) and a count. Even if that count is stored in a long int, and validated to not be negative, the product could easily be larger than LONG_MAX, while still being smaller than SIZE_MAX.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-12-02 14:58 -0800 |
| Message-ID | <b277dbde-57c3-4bca-84c5-1c0843e0e616n@googlegroups.com> |
| In reply to | #168442 |
On Friday, 2 December 2022 at 18:07:33 UTC+2, A wrote:
> On Friday, 2 December 2022 at 20:48:00 UTC+5:30, Öö Tiib wrote:
> > On Friday, 2 December 2022 at 15:13:34 UTC+2, A wrote:
> > > On Friday, 2 December 2022 at 18:19:29 UTC+5:30, A wrote:
> > > > On Thursday, 1 December 2022 at 23:34:21 UTC+5:30, Keith Thompson wrote:
> > > > > A <amit2342...@gmail.com> writes:
> > > > > > 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'.
> > > > > Presumably the syntax error would have been corrected (as you did in a
> > > > > followup) before it came to me for review.
> > > > >
> > > > > I'd tell the developer to use size_t, for reasons that have already been
> > > > > repeatedly discussed in this thread.
> > > > So, basically, if the developer wants to check for negative values, you don't want the developer to do that.
> > > >
> > > > Amit
> > > Basically, my point is that if something is specified in the standard, then it doesn't mean that it should be used by everyone. After all, the standard was defined by humans only.
> > Yes, everybody may do whatever they want to in their own code. Just
> > that when they want to cooperate with others and achieve efficient
> > products then it is worth to try to synchronise style and to use
> > techniques that are easy for compiler too.
> Your comment is non-sensical.
So out of arguments?
> > >
> > > Multiple inheritance is a feature of C++. But google recommends its developers to not use multiple inheritance when writing C++ code. So, google is not following C++ standards completely. So, do you think that google is wrong?
> > C++ is large language. Everybody use only some subset of it.
> > Google style guide actually says that:
> > "Multiple inheritance is permitted, but multiple implementation
> > inheritance is strongly discouraged."
> > Actually virtual functions of multiple implementation inheritance
> > are complex to follow logically and quite a trick to pull for compiler so
> > those cause way more noticeable performance losses than virtual
> > functions of single implementation inheritance. So the rule makes
> > sense.
> Your claims are wrong. Read this: https://google.github.io/styleguide/cppguide.html
Literal copy-paste from it:
<https://google.github.io/styleguide/cppguide.html#Inheritance>
"Multiple inheritance is permitted, but multiple implementation
inheritance is strongly discouraged."
You haven't read it??
> > >
> > > What I am saying is that size_t may be preferred by many people. But many people may not like it size_t. They may want to use long. So, why force them to use size_t when using long is not introducing any bug?
> > Lot of people are used to use size_t as count of something, especially
> > bytes. It is easier to cooperate with them. The sizeof operator of
> > language returns size_t. The memcpy needs size_t argument. It is easier to
> > cooperate with language using size_t. So from where that long somehow
> > got there? Just that "I want to want differently than language and
> > other programmers"? It is irrational want, unlike that Google rule.
> > >
> It looks like you haven't read the whole thread. I have clearly mentioned why I want to use long over size_t in memcpy().
You say you have negative sizes passed to memcpy. I have not met such
defect during all the decades. May be someone has made it somewhere
but then they have fixed it themselves before committing to code base.
> > > I thought a lot about why would they specify size_t in the C standard in memcpy(), etc. - the only reason that comes to my mind is that they thought that they don't know what kind of systems will come in the future. So, why to restrict the developer by using a signed type. Instead, give the user the whole range.
> > Most likely it was so because all throughout history the natural numbers
> > are used for counting and ordering and natural numbers can't be negative.
> > So unsigned number of C makes better sense to be used as count, a
> > natural number.
> > >
> > > But some people said that the size of type size_t differs according in various systems/implementations. Again, defining this kind of size_t is wrong.
> > That is same with long whose size in bits differs in various systems
> > so it does not make any difference in that sense.
> > >
> > > If you really want to address the whole memory range (so that the user is not restricted because no one knows what kind of systems may come in future), the size of type size_t should be set equal to the width of the address bus of the system to address the whole memory range (whether available or not) (and probably get this value dynamically).
> > That does not make sense. Run-time dynamic bit width of types?
> > That likely hits performance rather badly. Why such nonsense is
> > needed? Especially on the 8 or 16 bit controllers where we indeed
> > might want to address whole available memory range.
> This is not nonsense. Before writing anything please deliberate as to what you are writing. The compiler has to get the width when it is invoked, there is no run time penalty on executables.
What you mean by "getting value dynamically" if that does not happen
run-time?
> Most of your comments are nonsense. It looks like you really don't know what is being talked about here.
It looks like you really do not know anything and are unfamiliar
with software development. You can not read text link to what you
paste yourself.
>
> I will explain again. I want to use long because I want to check if the user has passed me negative value. The user can input anything, so the user input has to be checked somewhere. The check is in the function or outside, it doesn't matter.
So some end user of software is entering negative value -42 from
keyboard and somehow the software does not check user input
to fit with some sane sizes (lets say from 1 to 10000) and so passes
it as raw overflown from -42 size_t value
(lets say like 18446744073709551574) to memcpy after what
program crashes? But if we replace it with long (that lets say has
limit 2147483647) then user enters that and program crashes anyway.
>
> But after interacting with so many people here, it looks like to me that they will pass user input directly to memcpy(). But if they will check input "somewhere", then if i want to check the input in the function then what's wrong with it.
>
> So, I don't know what the people are arguing against when they will check input somewhere.
No, it is you who seem to claim that replacing size_t with long
somehow frees us from user input checking need.
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-12-02 21:17 -0800 |
| Message-ID | <a89f0881-45a7-4ee0-9978-af580123ec6cn@googlegroups.com> |
| In reply to | #168450 |
> > > > Multiple inheritance is a feature of C++. But google recommends its developers to not use multiple inheritance when writing C++ code. So, google is not following C++ standards completely. So, do you think that google is wrong? > > > C++ is large language. Everybody use only some subset of it. > > > Google style guide actually says that: > > > "Multiple inheritance is permitted, but multiple implementation > > > inheritance is strongly discouraged." > > > Actually virtual functions of multiple implementation inheritance > > > are complex to follow logically and quite a trick to pull for compiler so > > > those cause way more noticeable performance losses than virtual > > > functions of single implementation inheritance. So the rule makes > > > sense. > > Your claims are wrong. Read this: https://google.github.io/styleguide/cppguide.html > Literal copy-paste from it: > <https://google.github.io/styleguide/cppguide.html#Inheritance> > "Multiple inheritance is permitted, but multiple implementation > inheritance is strongly discouraged." > You haven't read it?? What I meant to say was that multiple implementation inheritance is not the only issue with multiple inheritance because of which google discourages multiple inheritance. The other problem is "diamond" inheritance issue. The text from the web page is below: ------------------------------------------ For implementation inheritance, because the code implementing a sub-class is spread between the base and the sub-class, it can be more difficult to understand an implementation. The sub-class cannot override functions that are not virtual, so the sub-class cannot change implementation. Multiple inheritance is especially problematic, because it often imposes a higher performance overhead (in fact, the performance drop from single inheritance to multiple inheritance can often be greater than the performance drop from ordinary to virtual dispatch), and because it risks leading to "diamond" inheritance patterns, which are prone to ambiguity, confusion, and outright bugs. ------------------------------------------ > > > > I will explain again. I want to use long because I want to check if the user has passed me negative value. The user can input anything, so the user input has to be checked somewhere. The check is in the function or outside, it doesn't matter. > So some end user of software is entering negative value -42 from > keyboard and somehow the software does not check user input > to fit with some sane sizes (lets say from 1 to 10000) and so passes > it as raw overflown from -42 size_t value > (lets say like 18446744073709551574) to memcpy after what > program crashes? But if we replace it with long (that lets say has > limit 2147483647) then user enters that and program crashes anyway. It is not just about replacing size_t with long. It is also about checking for negative values when using long. So, there won't be any crash if long is used and negative values are checked for. > > > > But after interacting with so many people here, it looks like to me that they will pass user input directly to memcpy(). But if they will check input "somewhere", then if i want to check the input in the function then what's wrong with it. > > > > So, I don't know what the people are arguing against when they will check input somewhere. > No, it is you who seem to claim that replacing size_t with long > somehow frees us from user input checking need. Again, It is not just about replacing size_t with long. It is also about checking for negative values when using long. So, there won't be any crash if long is used and negative values are checked for. The point is that no one is passing negative values to memcpy() as the input values get checked somewhere. As such why is size_t needed when the full range of size_t is not used by anyone? Amit
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-12-02 21:38 -0800 |
| Message-ID | <4b6a6c8c-575c-42f3-abb9-15d77d80ae29n@googlegroups.com> |
| In reply to | #168450 |
> It looks like you really do not know anything and are unfamiliar > with software development. You can not read text link to what you > paste yourself. That's why I said that most of your comments are non-sensical because you are saying that I am unfamiliar with software development because I can't read the whole text link that I pasted. Your inference is really non-sensical. Amit
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-12-03 03:39 -0800 |
| Message-ID | <4c37a643-5227-4a65-97f6-dc0658e19aecn@googlegroups.com> |
| In reply to | #168456 |
On Saturday, 3 December 2022 at 07:38:57 UTC+2, A wrote: > > It looks like you really do not know anything and are unfamiliar > > with software development. You can not read text link to what you > > paste yourself. > That's why I said that most of your comments are non-sensical because you are saying that I am unfamiliar with software development because I can't read the whole text link that I pasted. > > Your inference is really non-sensical. There was not in use any inference. I meant that there are three different (orthogonal or mildly related) problems with you in action. 1) low knowledge and bad ideas 2) unfamiliarity software development 3) inability to read documents Each of three was demonstrated in parts of post you snipped.
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web