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 | 13 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 11 of 11 — ← Prev page 1 … 9 10 [11]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-12-13 01:46 -0800 |
| Message-ID | <b4c64fa7-7f75-41f4-988c-28ea2834114cn@googlegroups.com> |
| In reply to | #168471 |
On Saturday, 3 December 2022 at 23:41:57 UTC+5:30, Scott Lurndal wrote: > A <amit2342...@gmail.com> writes: > > > >> 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 > From my perspective, nothing you've posted to date as shown > that you've had anything to do with professional software > development; just pointless arguments about things that have > been settled for close to half a century. I actually don't care what you think about me. Amit
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2022-12-10 17:24 +0000 |
| Message-ID | <tn2fbg$1mkh9$1@dont-email.me> |
| In reply to | #168450 |
On 02/12/2022 22:58, Öö Tiib wrote: > 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. Isn't this what some buffer overflow attacks use? Pass a specially constructed object - a file, or a comms packet - which has a size field in it, and set the size value to an invalid value which isn't checked? Andy
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-12-10 11:51 -0800 |
| Message-ID | <73db9194-8334-4228-b0ae-d1ce7fa8c37cn@googlegroups.com> |
| In reply to | #168501 |
On Saturday, 10 December 2022 at 19:24:15 UTC+2, Vir Campestris wrote: > On 02/12/2022 22:58, Öö Tiib wrote: > > 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. > > Isn't this what some buffer overflow attacks use? Pass a specially > constructed object - a file, or a comms packet - which has a size field > in it, and set the size value to an invalid value which isn't checked? Yes. It is typically about unreasonably big index, count or size of something. So if the size is unsigned and is checked for not being too big then also wrapped around negative values are tested to be invalid. But If the size is signed then two checks are needed if it is not too big and if it is not negative. So the type being signed gives no benefits.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-10 21:09 +0000 |
| Message-ID | <uA6lL.4569$5jd8.1516@fx05.iad> |
| In reply to | #168501 |
Vir Campestris <vir.campestris@invalid.invalid> writes: >On 02/12/2022 22:58, Öö Tiib wrote: >> 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. > >Isn't this what some buffer overflow attacks use? Pass a specially >constructed object - a file, or a comms packet - which has a size field >in it, and set the size value to an invalid value which isn't checked? > Input data should have been vetted and passed long before being used as an argument to mempcy.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-11 20:49 +0100 |
| Message-ID | <tn5c89$20gfp$3@dont-email.me> |
| In reply to | #168504 |
On 10/12/2022 22:09, Scott Lurndal wrote: > Vir Campestris <vir.campestris@invalid.invalid> writes: >> On 02/12/2022 22:58, Öö Tiib wrote: >>> 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. >> >> Isn't this what some buffer overflow attacks use? Pass a specially >> constructed object - a file, or a comms packet - which has a size field >> in it, and set the size value to an invalid value which isn't checked? >> > > Input data should have been vetted and passed long before being > used as an argument to mempcy. > Sure. And that is why checks in low-level functions like allocators (or memcpy) are worse than useless. They won't help against real problems, and they will be a waste of time for code that has already ensured the arguments are correct.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-12-02 10:18 -0800 |
| Message-ID | <878rjpk6tk.fsf@nosuchdomain.example.com> |
| In reply to | #168440 |
A <amit234234234234@gmail.com> writes:
[...]
> 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?
size_t is used extensively in the C standard library. You can't avoid
it if you're programming in C. (You can at least mostly avoid multiple
inheritance when programming in C++. I offer no opinion on whether
that's a good idea or not.)
> 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.
They didn't know what kinds of systems will appear in the future, and
they *did* know what kinds of systems already existed. Existing systems
have different characteristics. It makes sense for size_t to be 16 bits
on some systems, 32 on some, and 64 on some. And each implementation
defines it with an appropriate width for the target system.
> 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.
I don't understand whatever point you're making here. size_t is already
defined appropriately for each implementation, based on the
characteristics of the target system. Were you not aware of that?
> 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).
It typically *is* the width of the address bus (or it might be different
for some valid reason). The developers of the implementation have that
information, and use it when writing the <stddef.h> header and the
various functions that take size_t arguments. There's no need to
compute it dynamically.
--
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:24 -0800 |
| Message-ID | <733e7ce4-12ce-4c77-a092-9194ddc1ee79n@googlegroups.com> |
| In reply to | #168447 |
> > 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? > size_t is used extensively in the C standard library. You can't avoid > it if you're programming in C. (You can at least mostly avoid multiple > inheritance when programming in C++. I offer no opinion on whether > that's a good idea or not.) > > 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. > They didn't know what kinds of systems will appear in the future, and > they *did* know what kinds of systems already existed. Existing systems > have different characteristics. It makes sense for size_t to be 16 bits > on some systems, 32 on some, and 64 on some. And each implementation > defines it with an appropriate width for the target system. > > 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. > I don't understand whatever point you're making here. size_t is already > defined appropriately for each implementation, based on the > characteristics of the target system. Were you not aware of that? size_t is defined to be at least 16 bits wide. So, on 8 bit systems also, it will be 16 bits. So, according to me, this doesn't make sense. Also, if a new system comes, then probably stddef.h has to be modified. But if the compiler gets the size of type size_t dynamically, then there is no need to modify anything for this. And also, many developers will end up modifying many different C compilers, so dynamically obtaining value of width of address bus will save all this work. Amit
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-03 16:54 +0100 |
| Message-ID | <tmfrga$3cclu$3@dont-email.me> |
| In reply to | #168453 |
On 03/12/2022 06:24, A wrote: > >> They didn't know what kinds of systems will appear in the future, >> and they *did* know what kinds of systems already existed. Existing >> systems have different characteristics. It makes sense for size_t >> to be 16 bits on some systems, 32 on some, and 64 on some. And each >> implementation defines it with an appropriate width for the target >> system. >>> 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. >> I don't understand whatever point you're making here. size_t is >> already defined appropriately for each implementation, based on >> the characteristics of the target system. Were you not aware of >> that? > > size_t is defined to be at least 16 bits wide. So, on 8 bit systems > also, it will be 16 bits. So, according to me, this doesn't make > sense. > Have you ever used an 8-bit system? Can you name a real 8-bit system where 16-bit size_t would not be the appropriate choice, or which has an 8-bit address bus? > Also, if a new system comes, then probably stddef.h has to be > modified. But if the compiler gets the size of type size_t > dynamically, then there is no need to modify anything for this. And > also, many developers will end up modifying many different C > compilers, so dynamically obtaining value of width of address bus > will save all this work. > <stddef.h> is part of the C implementation. "size_t" is defined as the type returned by the C "sizeof" operator. While some parts of the standard C library can be written independently from the compiler, other parts are more tightly tied - including the definition of "size_t".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-12-03 12:48 -0800 |
| Message-ID | <87h6yc2oy9.fsf@nosuchdomain.example.com> |
| In reply to | #168453 |
Amit, when you post a followup, attribution lines are automatically
added, indicating who wrote what. Please leave those lines in
place. It makes it easier to follow the discussion.
A <amit234234234234@gmail.com> writes:
> size_t is defined to be at least 16 bits wide. So, on 8 bit systems
> also, it will be 16 bits. So, according to me, this doesn't make
> sense.
An "8 bit system" is one with 8-bit registers and/or an 8-bit data bus
(the definition is not rigorous). Such systems typically have 16-bit
registers and 16-bit addresses. A true 8-bit system of the kind you're
thinking of could only address 256 bytes of memory. Such systems are
exceedingly rare (I recently read about such a system), and could not
reasonably support a C implementation.
The requirement that size_t is at least 16 bits doesn't cause any
problems in practice.
> Also, if a new system comes, then probably stddef.h has to be
> modified. But if the compiler gets the size of type size_t
> dynamically, then there is no need to modify anything for this. And
> also, many developers will end up modifying many different C
> compilers, so dynamically obtaining value of width of address bus will
> save all this work.
Developers already know how to handle this. There's no need to
dynamically obtain the width of the address bus. If you're creating a
new implementation, you know the characteristics of the target system.
Determining how size_t should be defined is one very small and nearly
trivial part of the work of creating a C implementation. Changing the
language to make that step easier would not be useful.
--
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:55 -0500 |
| Message-ID | <tmijdq$3n615$2@dont-email.me> |
| In reply to | #168453 |
On 12/3/22 00:24, A wrote: ... >> I don't understand whatever point you're making here. size_t is >> already defined appropriately for each implementation, based on the >> characteristics of the target system. Were you not aware of that? > > size_t is defined to be at least 16 bits wide. So, on 8 bit systems > also, it will be 16 bits. So, according to me, this doesn't make sense. On some systems, size_t will be 16 bits, on others 32 bits, and on others 64 bits. On some rare systems it might be 36 bits. All of those satisfy the requirement that it be at least 16 bits wide, but implementors for each type of system choose a size for size_t that is based upon the characteristics of that system. What doesn't make sense to you about that?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-12-02 09:58 -0800 |
| Message-ID | <87cz91k7rh.fsf@nosuchdomain.example.com> |
| In reply to | #168439 |
A <amit234234234234@gmail.com> writes:
> 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.
If the developer wants to write code that arbitrarily makes it
impossible to use sizes greater than LONG_MAX (which are perfectly valid
on some real-world systems), I don't want the developer to do that.
If the developer wants to invent a new interface for the sake of
detecting an extremely rare error, writing extra code to interface to
the standard library, code that needs to be maintained and will be a
possible source of bugs, I don't want the developer to do that.
If the developer wants to either (a) define a new interface to memcpy
and leave everything else alone or (b) define new interfaces to
everything in the standard library that uses size_t, I don't want the
developer to do that.
Some questions for you:
Do you have a reason other than checking for incorrect negative values
for wanting to make this change?
Do you have an estimate of how often the error of using a negative size
actually occurs? In fact, have you ever seen that error in real code?
Have you addressed the fact that size_t is bigger than long on Windows?
How would you allocate a 3GB object on Windows? (As far as I can tell,
you simply ignore this every time it's brought up.)
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-12-01 20:02 +0000 |
| Message-ID | <877czaao5j.fsf@bsb.me.uk> |
| 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));
Shades of C++. (size_t)n in the C version.
> 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'.
I would have much more serious concerns than the type of n. The very
existence of the function raises all sorts of red flags for me. What
does the rest of code look like if catching a bad size or a null pointer
is best done by checking the a return value from a copy operation.
I'd want to see every call site and, depending on what I found, I would
try to correct the design. Can you describe how this function is used
in some actual program?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-12-04 07:35 -0800 |
| Message-ID | <867cz75gib.fsf@linuxsc.com> |
| In reply to | #168196 |
Amit <amitchoudhary0523@gmail.com> writes: > I prefer long over size_t. > > This is because, in case the user passes a negative number by mistake > then I will be able to check it if the type is long and return > immediately. > > But if size_t is used, then most probably, it will result in a crash > - like malloc(-1) will crash the program because unsigned -1 is > 0xFFFFFFFF and this much memory is not available on today's computers > and probably may not be available at all in future also (RAM size of > 2^64 bits is really really huge). > > Another thing is that if size_t is used an array index then array[-1] > will result in wrong behavior or program crash. But with long, the > developer can check whether the index is negative, thus avoiding > program crash. > > So, in my opinion, long should be used instead of size_t. > > I know that original glibc authors had chosen size_t, so there must > be some reason for that, however that reason is not clear to me. I have been reading through your postings in this thread. Here are my main impressions. First, your conclusions are bad. This result occurs because, one, some of your assumptions are wrong, and two, your logic is faulty. Second, it appears you are fundamentally confused about the nature of types defined in the ISO C standard. Most types defined in the ISO C standard allow some amount of variation in choices for their precision, representation, etc. These choices are left up to the various implementations, and it is expected that each implementation will make its own choices in a way most suitable to the implementation's execution environment. This variability has been in place for more than 30 years (closer to 40 years if you count the time after the C standardization effort was started); it works pretty well, and has not presented any serious difficulties in carrying it out. Third, there is nothing wrong with wanting to check for negative arguments to functionalities such as memory allocation, etc, but you are conflating that high-level desire with one particular approach to addressing it, and that approach (using a 'long' parameter) is inherently flawed. It appears you simply do not understand why that is. If you want to make any progress, you must learn how to separate these different aspects and deal with them individually. Otherwise what you are advocating is just a muddled mess, and no competent software developer is going to take you seriously.
[toc] | [prev] | [standalone]
Page 11 of 11 — ← Prev page 1 … 9 10 [11]
Back to top | Article view | comp.lang.c
csiph-web