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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-11-20 01:51 -0500 |
| Message-ID | <tlciq4$3f4tk$4@dont-email.me> |
| In reply to | #168304 |
On 11/20/22 01:38, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On 11/19/22 15:47, Keith Thompson wrote: >>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> ... >>>> Standard library routines are required to set errno to positive values, >>>> specifically to allow users to use negative values for their own >>>> purposes. allocate_memory() is not supposed to be a standard library >>>> function, and therefore can use a negative value. >>> >>> I don't think that's correct. The standard requires the values of EDOM, >>> EILSEQ, and ERANGE to be positive, but makes no such guarantee about any >>> implementation-defined E* macros, or about values that errno might be >>> set to by library function calls. >> >> The description of errno in 7.5p2 says "... the value of which is set to >> a positive error number by several library functions." > > You're right, I missed that -- but p3 says "The value of errno may be > set to nonzero by a library function call whether or not there is an > error, provided the use of errno is not documented in the description of > the function in this International Standard." > > And I'm sure the intent is that the "additional macro definitions" > beginning with E are supposed to expand to positive constant expressions > of type int, but the standard doesn't say so. (It would IMHO be nice if > it did.) That this requirement was imposed with the intent of allowing user code to assign negative values to errno is something I've only heard third-hand, I've no official source for it.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-11-20 15:43 +0000 |
| Message-ID | <20221120073416.515@kylheku.com> |
| In reply to | #168304 |
On 2022-11-20, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On 11/19/22 15:47, Keith Thompson wrote: >>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> ... >>>> Standard library routines are required to set errno to positive values, >>>> specifically to allow users to use negative values for their own >>>> purposes. allocate_memory() is not supposed to be a standard library >>>> function, and therefore can use a negative value. >>> >>> I don't think that's correct. The standard requires the values of EDOM, >>> EILSEQ, and ERANGE to be positive, but makes no such guarantee about any >>> implementation-defined E* macros, or about values that errno might be >>> set to by library function calls. >> >> The description of errno in 7.5p2 says "... the value of which is set to >> a positive error number by several library functions." > > You're right, I missed that -- but p3 says "The value of errno may be > set to nonzero by a library function call whether or not there is an > error, provided the use of errno is not documented in the description of > the function in this International Standard." There is also "strerror shall map any value of type int to a message". So we know that if we stick a negative value into errno, and something tries to interpret it, that is required to be robust. That is important, because if it said something like that the behavior is undefined if strerror is invoked on anything than the values of the standard-defined constants, plus any implementation-defined ones, that would put a damper on the use of application-defined errno values. A program sticking nonstandard values into errno would have to ensure that no function is invoked that might try to extract a message from errno. Though that is required to be robust, I don't think it's a great idea to stick custom values into errno because strerror will not come up with a useful message. There is a risk the value stored in errno will be accessed beyond its intended perimeter of use, and result in some users having to deal with some cryptic "errno -123" diagnostic that will send them on some wild goose chase. Only as a hack between internal routines: say a lower-level routine setting a custom value in errno, knowing that the intermediate level intercepts it, handles it, and overwrites the value with zero or a standard value before returning to the higher level. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-11-20 15:29 +0000 |
| Message-ID | <20221120071843.649@kylheku.com> |
| In reply to | #168272 |
On 2022-11-19, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 11/17/22 10:55, Kaz Kylheku wrote:
>> On 2022-11-17, A <amit234234234234@gmail.com> wrote:
>>> Let me ask a similar question.
>>>
>>> Please see the function below:
>>>
>>> void *allocate_memory(long size)
>>> {
>>> if (size < 0) {
>>> errno = -ENEGATIVESIZE;
>>
>> errno values aren't negated; might you have been studying Linux kernel
>> code recently?
>
> Standard library routines are required to set errno to positive values,
> specifically to allow users to use negative values for their own
> purposes. allocate_memory() is not supposed to be a standard library
> function, and therefore can use a negative value.
Even if every standard as well as implementation-added constant is
positive, it would be a bad idea to define your own negative-valued
constant via its additive inverse:
#define ENEGATIVESIZE 42
and then have to remember to negate it everywhere it is used.
The constants might /be/ negative, but code should not be /negating/
them to make them negative at the points of use.
That's just about as silly as
#define ENEGATIVESIZE (3 * 42)
And then remember to:
errno = ENEGATIVESIZE / 3;
You generally define any given symbolic constant to produce the intended
literal constant.
It really looks to me like the statement might be a coding mistake by
someone who formed a habit due to mainly coding in the Linux kernel.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-11-17 16:59 +0000 |
| Message-ID | <877czttt3d.fsf@bsb.me.uk> |
| In reply to | #168213 |
A <amit234234234234@gmail.com> writes:
> Let me ask a similar question.
>
> Please see the function below:
>
> void *allocate_memory(long size)
> {
> if (size < 0) {
> errno = -ENEGATIVESIZE;
It's better to avoid using names starting with E since implementations
may add their own to errno.h.
My main objection is that this should not be reported as an allocation
failure. This *should* "crash" the program. I'd have an assert in
there to force termination during testing.
> return NULL;
> }
> return (malloc((size_t)(size)));
Why all the brackets? return malloc((size_t)size); is clearer isn't it?
> }
>
> Would you ask the developer to use size_t instead of long and WHY?
If the sort of bug you are hoping to catch is at all likely, I'd try to
improve testing. I'd have a testing malloc function that has
assert(size < 0x10000);
(or whatever is a reasonable maximum for this program) at the top so as
to catch all these bug as early as possible. I most certainly don't
want code that detect a NULL return and then does something if errno is
-ENEGATIVESIZE. It's not a condition I want the code to handle like an
allocation failure!
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-18 10:30 +0100 |
| Message-ID | <tl7jb8$2tkgm$1@dont-email.me> |
| In reply to | #168208 |
On 17/11/2022 11:48, A wrote: > >> This all seems a pretty drastic decision based solely on spotting a very >> specific type of error that is unlikely to happen in practice, and which >> will immediately be found in testing. > >> Why just check for negative values? What happens if the caller passes >> 0x0bad0bad0bad0bad as the size? It is perfectly good value in a 64-bit >> "long", yet just as unrealistic for a memory size as -1. You are >> drawing arbitrary lines that I don't think help anyone. > > Let's say that you have to design an allocate_memory() function. Would you choose a size_t argument over long and WHY? > > Amit Reason number one for choosing "size_t" is that it is what programmers expect, fits with all existing memory allocation functions (such as those in the standard library), fits the common usage of C programmers when dealing with something that is the "size of something", and is the type returned by the "sizeof" operator. Reason number two would be that it is the right range for the purpose on a wide variety of systems - including those where "size_t" is smaller than "long", and those where it is bigger than "long", as these are all in mainstream usage. Reason number three is that sometimes (admittedly not often) the range of "long" is not enough. I still have a 32-bit computer with 8 GB ram under my desk at home, though it's a number of years since I last had it switched on. So, lots of benefits of "size_t". And what is the benefit of "long", assuming you happen to be on a target where "long" is the same size as "size_t" ? No one is going to pass a negative value to the function - it's not going to happen intentionally because it makes no sense, and it is extremely unlikely to happen by accident. (Testing for 0 might be appropriate.) So in reality, it gives no advantage whatsoever.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-11-17 12:47 +0000 |
| Message-ID | <871qq1vjbc.fsf@bsb.me.uk> |
| In reply to | #168196 |
Amit <amitchoudhary0523@gmail.com> writes: > I prefer long over size_t. Hmm... ok, but you probably can't avoid using it. The argument to malloc is a size_t, for example, as is the result of strlen. > 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. You can do the same check with size_t. Any value > SIZE_MAX/2 is probably the result of converting a negative value to size_t. You are cutting out half of the possible sizes, but you are doing that (for the common widths of these types) already by excluding negative values of type long. The only case where you would not want to lose half the range like this is when size_t is shorter than long. But on those implementations, there is probably some non-trivial cost to doing long arithmetic so on these systems you might prefer to use size_t as it was intended to be used. I'm prepared to bet your code would not run on such a system anyway given that you assume -1 to be 0xFFFFFFFF! <cut> > 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. size_t is not a glibc invention. It's from the very first C standard (1989) when machines were much smaller. On a 16-bit implementation, size_t might be only 16 bits wide so making it unsigned was worth while. At the same time, insisting on using long would have incurred unnecessary runt-time costs since long might not be supported by the hardware. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.org> |
|---|---|
| Date | 2022-11-17 13:15 +0000 |
| Message-ID | <slrntnccv1.96a.ike@sverige.sdf.org> |
| In reply to | #168196 |
On 2022-11-17, Amit <amitchoudhary0523@gmail.com> wrote: > 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). If malloc cannot allocate the requested size, it does not crash, it returns a null pointer. > 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. The array index should be in the range [0 .. N-1] where N is the number of elements in the array. Passing an index < 0 or an index >= N is an error, so don't do that. If the index is an unsigned type, it cannot be < 0, but you should still be sure it's < N.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-11-17 15:01 +0000 |
| Message-ID | <U0sdL.5884$rB56.1897@fx08.iad> |
| In reply to | #168196 |
Amit <amitchoudhary0523@gmail.com> writes: >Hi, > >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. size_t predates glibc by several years. size_t was specified by the SVID and adopted into POSIX and XPG. It defines the size of an object/region, and it is defined such that it can describe the largest object/region that can be created or allocated by the implementation. A negative size is not sensible.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2022-11-17 15:24 +0000 |
| Message-ID | <tl5jn5$2ln2t$1@dont-email.me> |
| In reply to | #168227 |
On Thu, 17 Nov 2022 15:01:08 +0000, Scott Lurndal wrote: > Amit <amitchoudhary0523@gmail.com> writes: >>Hi, > > >>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. > > size_t predates glibc by several years. size_t was specified by the > SVID and adopted into POSIX and XPG. > > It defines the size of an object/region, and it is defined such that it > can describe the largest object/region that can be created or allocated > by the implementation. > > A negative size is not sensible. POSIX now defines a ssize_t, a signed integer type which is "used for a count of bytes or an error indication", with negative values indicating error conditions, and positive (or zero) values indicating a "count of bytes". -- Lew Pitcher "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-11-17 21:48 -0800 |
| Message-ID | <tl76b4$2sims$2@dont-email.me> |
| In reply to | #168196 |
On 11/16/2022 10:20 PM, Amit wrote: > Hi, > > I prefer long over size_t. > > This is because, in case the user passes a negative number by mistake then I will be able to check it if the type is long and return immediately. > > But if size_t is used, then most probably, it will result in a crash - like malloc(-1) will crash the program because unsigned -1 is 0xFFFFFFFF and this much memory is not available on today's computers and probably may not be available at all in future also (RAM size of 2^64 bits is really really huge). [...] Patient: Doctor, it hurts when I malloc(-1)... Doctor: Well, then don't do that... ;^)
[toc] | [prev] | [next] | [standalone]
| From | Opus <ifonly@youknew.org> |
|---|---|
| Date | 2022-11-18 20:12 +0100 |
| Message-ID | <tl8lf0$db4$1@gioia.aioe.org> |
| In reply to | #168239 |
Le 18/11/2022 à 06:48, Chris M. Thomasson a écrit : > On 11/16/2022 10:20 PM, Amit wrote: >> Hi, >> >> I prefer long over size_t. >> >> This is because, in case the user passes a negative number by mistake >> then I will be able to check it if the type is long and return >> immediately. >> >> But if size_t is used, then most probably, it will result in a crash - >> like malloc(-1) will crash the program because unsigned -1 is >> 0xFFFFFFFF and this much memory is not available on today's computers >> and probably may not be available at all in future also (RAM size of >> 2^64 bits is really really huge). > [...] > > Patient: Doctor, it hurts when I malloc(-1)... > > Doctor: Well, then don't do that... Just a note regarding this, on top of all that has been already said: the above would be easily caught by a decent compiler. Unfortunately, for historical reasons, GCC (and LLVM, which strives to behave the same as GCC) will not emit a warning for this (yes even with '-Wall') unless you explicitely pass the additional '-Wconversion' warning flag. And I highly recommend it. Of course, with this flag enabled, a crapton of existing code is bound to throw warnings all over the place. Usually because said code is very flaky. You can also use third-party static analyzers, which would easily catch this and a LOT of other potentially problematic stuff in your code. Do not hesitate to use them. Heck, some are even free.
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2022-11-18 00:26 -0600 |
| Message-ID | <tl78j8$pk1$1@gioia.aioe.org> |
| In reply to | #168196 |
On 11/17/2022 12:20 AM, Amit wrote: > Hi, > > I prefer long over size_t. > > This is because, in case the user passes a negative number by mistake then I will be able to check it if the type is long and return immediately. > > But if size_t is used, then most probably, it will result in a crash - like malloc(-1) will crash the program because unsigned -1 is 0xFFFFFFFF and this much memory is not available on today's computers and probably may not be available at all in future also (RAM size of 2^64 bits is really really huge). > > Another thing is that if size_t is used an array index then array[-1] will result in wrong behavior or program crash. But with long, the developer can check whether the index is negative, thus avoiding program crash. > > So, in my opinion, long should be used instead of size_t. > > I know that original glibc authors had chosen size_t, so there must be some reason for that, however that reason is not clear to me. > > Amit Are longs and long longs the same in Unix ? Thanks, Lynn
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-18 10:37 +0100 |
| Message-ID | <tl7jpi$2tlfb$1@dont-email.me> |
| In reply to | #168240 |
On 18/11/2022 07:26, Lynn McGuire wrote: > On 11/17/2022 12:20 AM, Amit wrote: >> Hi, >> >> I prefer long over size_t. >> >> This is because, in case the user passes a negative number by mistake >> then I will be able to check it if the type is long and return >> immediately. >> >> But if size_t is used, then most probably, it will result in a crash - >> like malloc(-1) will crash the program because unsigned -1 is >> 0xFFFFFFFF and this much memory is not available on today's computers >> and probably may not be available at all in future also (RAM size of >> 2^64 bits is really really huge). >> >> Another thing is that if size_t is used an array index then array[-1] >> will result in wrong behavior or program crash. But with long, the >> developer can check whether the index is negative, thus avoiding >> program crash. >> >> So, in my opinion, long should be used instead of size_t. >> >> I know that original glibc authors had chosen size_t, so there must be >> some reason for that, however that reason is not clear to me. >> >> Amit > > Are longs and long longs the same in Unix ? > No. They are the same size and range in all 64-bit *nix systems (AFAIK), but on 32-bit *nix systems they are different (long is 32-bit, long long is 64-bit). That also applies to the x32 ABI for Linux on amd64 processor, where you have 64-bit registers but 32-bit pointers. Even if the size and range are the same, they are still different types - a "long *" and a "long long *" pointer are incompatible.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-11-19 01:43 -0500 |
| Message-ID | <tl9tv3$367b8$5@dont-email.me> |
| In reply to | #168240 |
On 11/18/22 01:26, Lynn McGuire wrote:
...
> Are longs and long longs the same in Unix ?
Unix imposes only the same constraints on long and long long as the C
standard itself:
{LLONG_MAX}
Maximum value for an object of type long long.
Minimum Acceptable Value: +9223372036854775807
{LLONG_MIN}
Minimum value for an object of type long long.
Maximum Acceptable Value: -9223372036854775807
{LONG_MAX}
Maximum value for an object of type long.
Minimum Acceptable Value: +2 147 483 647
{LONG_MIN}
Minimum value for an object of type long.
Maximum Acceptable Value: -2 147 483 647
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-11-20 03:06 +0100 |
| Message-ID | <tlc23m$3bd4v$1@dont-email.me> |
| In reply to | #168196 |
I always use int, it's the best choice for indexing on all machines.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-11-19 19:58 -0800 |
| Message-ID | <tlc8lj$3elcf$3@dont-email.me> |
| In reply to | #168299 |
On 11/19/2022 6:06 PM, Bonita Montero wrote: > I always use int, it's the best choice for indexing on all machines. Until the index gets larger than INT_MAX?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-11-20 08:34 +0100 |
| Message-ID | <tlcl9h$3fils$1@dont-email.me> |
| In reply to | #168300 |
Am 20.11.2022 um 04:58 schrieb Chris M. Thomasson: >> I always use int, it's the best choice for indexing on all machines. > Until the index gets larger than INT_MAX? Then I use "int x : 128" !!!
[toc] | [prev] | [next] | [standalone]
| From | Opus <ifonly@youknew.org> |
|---|---|
| Date | 2022-11-20 20:11 +0100 |
| Message-ID | <tldu5p$cab$1@gioia.aioe.org> |
| In reply to | #168309 |
Le 20/11/2022 à 08:34, Bonita Montero a écrit : > Am 20.11.2022 um 04:58 schrieb Chris M. Thomasson: > >>> I always use int, it's the best choice for indexing on all machines. > >> Until the index gets larger than INT_MAX? > > Then I use "int x : 128" !!! Hilarious!
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-11-20 20:48 +0100 |
| Message-ID | <tle0b2$3j3tt$1@dont-email.me> |
| In reply to | #168315 |
Am 20.11.2022 um 20:11 schrieb Opus: > Le 20/11/2022 à 08:34, Bonita Montero a écrit : >> Am 20.11.2022 um 04:58 schrieb Chris M. Thomasson: >> >>>> I always use int, it's the best choice for indexing on all machines. >> >>> Until the index gets larger than INT_MAX? >> >> Then I use "int x : 128" !!! > > Hilarious! Sometimes I even use "int x : 1024" ! And not an unsigned to address the negative portion of the address space.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-11-21 21:57 -0800 |
| Message-ID | <tlhobs$1js7$3@dont-email.me> |
| In reply to | #168300 |
On 11/19/2022 7:58 PM, Chris M. Thomasson wrote: > On 11/19/2022 6:06 PM, Bonita Montero wrote: >> I always use int, it's the best choice for indexing on all machines. > > Until the index gets larger than INT_MAX? Have you ever had to iterate larger than INT_MAX times before?
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web