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 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-01 12:41 -0800 |
| Message-ID | <tmb3i1$2s3ov$4@dont-email.me> |
| In reply to | #168411 |
On 12/1/2022 12:14 AM, David Brown wrote:
> On 01/12/2022 08:47, James Kuyper wrote:
>> On 12/1/22 02:31, A wrote:
>>>
>>> So, let's say a developer wrote some code like this:
>>>
>>> error_t copy_bytes(void *dest, const void *src, long n)
>>> {
>>>
>>> if ((!dest) || (!src))
>>> return ENULL;
>>>
>>> if (n < 0)
>>> return ENEGATIVESIZE;
>>>
>>> memcpy(dest, src, size_t(n));
>>>
>>> return ESUCCESS;
>>>
>>> }
>>>
>>> Now, the above code comes to you for review.
>>>
>>> So, will you tell the developer to use size_t for 'n' or let the
>>> developer keep using long for 'n'.
>>
>> If LONG_MAX > SIZE_MAX, this code fails to catch all of the possible
>> erroneous values for n. It should be if(n < 0 || n > SIZE_MAX).
>>
>> If LONG_MAX < SIZE_MAX, this code prevents copying of blocks of memory
>> that memcpy() could be used for.
>>
>> Keep in mind that LONG_MAX can be (and on some real-world systems, has
>> been) either much larger than SIZE_MAX, or much smaller than it, so
>> these are not minor quibbles. For instance, long might be a 64 bit type,
>> while size_t could be a 32 bit type, or vice-versa.
>>
>
> It is not just "has been", but "is". On 64-bit Windows (which, I hear,
> is quite popular in some circles) you have 64-bit "size_t" and 32-bit
> "long".
>
> On 8-bit and 16-bit microcontrollers - which outsell 64-bit processors
> by a long way - you have 16-bit "size_t" and 32-bit "long".
Iirc, LONG on windows has to be 32-bits or the proverbial shi% will hit
the fan? Legacy from their internal impl?
DWORD
DWORDLONG
DWORD_PTR
Ahh, then the LONG:
LONG
A 32-bit signed integer. The range is -2147483648 through 2147483647
decimal.
This type is declared in WinNT.h as follows:
typedef long LONG;
https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-12-01 23:53 +0000 |
| Message-ID | <tmbeqk$q2q$1@gioia.aioe.org> |
| In reply to | #168424 |
On 01/12/2022 20:41, Chris M. Thomasson wrote:
> On 12/1/2022 12:14 AM, David Brown wrote:
>> On 01/12/2022 08:47, James Kuyper wrote:
>>> On 12/1/22 02:31, A wrote:
>>>>
>>>> So, let's say a developer wrote some code like this:
>>>>
>>>> error_t copy_bytes(void *dest, const void *src, long n)
>>>> {
>>>>
>>>> if ((!dest) || (!src))
>>>> return ENULL;
>>>>
>>>> if (n < 0)
>>>> return ENEGATIVESIZE;
>>>>
>>>> memcpy(dest, src, size_t(n));
>>>>
>>>> return ESUCCESS;
>>>>
>>>> }
>>>>
>>>> Now, the above code comes to you for review.
>>>>
>>>> So, will you tell the developer to use size_t for 'n' or let the
>>>> developer keep using long for 'n'.
>>>
>>> If LONG_MAX > SIZE_MAX, this code fails to catch all of the possible
>>> erroneous values for n. It should be if(n < 0 || n > SIZE_MAX).
>>>
>>> If LONG_MAX < SIZE_MAX, this code prevents copying of blocks of memory
>>> that memcpy() could be used for.
>>>
>>> Keep in mind that LONG_MAX can be (and on some real-world systems, has
>>> been) either much larger than SIZE_MAX, or much smaller than it, so
>>> these are not minor quibbles. For instance, long might be a 64 bit type,
>>> while size_t could be a 32 bit type, or vice-versa.
>>>
>>
>> It is not just "has been", but "is". On 64-bit Windows (which, I
>> hear, is quite popular in some circles) you have 64-bit "size_t" and
>> 32-bit "long".
>>
>> On 8-bit and 16-bit microcontrollers - which outsell 64-bit processors
>> by a long way - you have 16-bit "size_t" and 32-bit "long".
>
> Iirc, LONG on windows has to be 32-bits or the proverbial shi% will hit
> the fan? Legacy from their internal impl?
So, what /is/ the purpose of long?
Since you already have 'int', and 'long long' which is usually wider,
why a third type which will be the same width as one of those?
If int/long long are assumed to be 32/64 bits, is 'long' then used on
Linux as a type which matches the machine word size?
I suspect that it's rarely used for that purpose!
What is the history of long anyway: was it typically 32 bits when int
was 16 bits? Then it's a question of what happened when int became 32
bits too.
One OS took the decision to keep 'long' the same on both 32 and 64
machines, and another decided it would vary between 32 and 64 bits
machines, also deciding that 'long long' should be 64 bits on both and
not 64/128 bits.
So people used to writing 'long' everywhere for a 32-bit value instead
of 'int', now had a type wider than expected and taking more memory on
the 64-bit machine.
And those using relying on 'long' being 64-bits, may get a surprise when
their program is compiled for 64 bits.
Which OS made the right decision?
My view is that it's crazy having 5 integer types to represent 4 widths
anyway, and you see that on both OSes.
While a target-specific type (related to machine word size rather than
address size) should not be one of those general integer types.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-02 21:30 -0800 |
| Message-ID | <tmemuf$39ung$3@dont-email.me> |
| In reply to | #168433 |
On 12/1/2022 3:53 PM, Bart wrote:
> On 01/12/2022 20:41, Chris M. Thomasson wrote:
>> On 12/1/2022 12:14 AM, David Brown wrote:
>>> On 01/12/2022 08:47, James Kuyper wrote:
>>>> On 12/1/22 02:31, A wrote:
>>>>>
>>>>> So, let's say a developer wrote some code like this:
>>>>>
>>>>> error_t copy_bytes(void *dest, const void *src, long n)
>>>>> {
>>>>>
>>>>> if ((!dest) || (!src))
>>>>> return ENULL;
>>>>>
>>>>> if (n < 0)
>>>>> return ENEGATIVESIZE;
>>>>>
>>>>> memcpy(dest, src, size_t(n));
>>>>>
>>>>> return ESUCCESS;
>>>>>
>>>>> }
>>>>>
>>>>> Now, the above code comes to you for review.
>>>>>
>>>>> So, will you tell the developer to use size_t for 'n' or let the
>>>>> developer keep using long for 'n'.
>>>>
>>>> If LONG_MAX > SIZE_MAX, this code fails to catch all of the possible
>>>> erroneous values for n. It should be if(n < 0 || n > SIZE_MAX).
>>>>
>>>> If LONG_MAX < SIZE_MAX, this code prevents copying of blocks of memory
>>>> that memcpy() could be used for.
>>>>
>>>> Keep in mind that LONG_MAX can be (and on some real-world systems, has
>>>> been) either much larger than SIZE_MAX, or much smaller than it, so
>>>> these are not minor quibbles. For instance, long might be a 64 bit
>>>> type,
>>>> while size_t could be a 32 bit type, or vice-versa.
>>>>
>>>
>>> It is not just "has been", but "is". On 64-bit Windows (which, I
>>> hear, is quite popular in some circles) you have 64-bit "size_t" and
>>> 32-bit "long".
>>>
>>> On 8-bit and 16-bit microcontrollers - which outsell 64-bit
>>> processors by a long way - you have 16-bit "size_t" and 32-bit "long".
>>
>> Iirc, LONG on windows has to be 32-bits or the proverbial shi% will
>> hit the fan? Legacy from their internal impl?
>
> So, what /is/ the purpose of long?
[...]
Wrt to the realm of Windows, imvvho, the purpose of long is to be
32-bits, ala their compiler, MSVC? LONG vs long, well, we make a
compiler... All your base or belong to us?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-03 13:48 -0800 |
| Message-ID | <tmgg7m$3e896$1@dont-email.me> |
| In reply to | #168454 |
On 12/2/2022 9:30 PM, Chris M. Thomasson wrote:
> On 12/1/2022 3:53 PM, Bart wrote:
>> On 01/12/2022 20:41, Chris M. Thomasson wrote:
>>> On 12/1/2022 12:14 AM, David Brown wrote:
>>>> On 01/12/2022 08:47, James Kuyper wrote:
>>>>> On 12/1/22 02:31, A wrote:
>>>>>>
>>>>>> So, let's say a developer wrote some code like this:
>>>>>>
>>>>>> error_t copy_bytes(void *dest, const void *src, long n)
>>>>>> {
>>>>>>
>>>>>> if ((!dest) || (!src))
>>>>>> return ENULL;
>>>>>>
>>>>>> if (n < 0)
>>>>>> return ENEGATIVESIZE;
>>>>>>
>>>>>> memcpy(dest, src, size_t(n));
>>>>>>
>>>>>> return ESUCCESS;
>>>>>>
>>>>>> }
>>>>>>
>>>>>> Now, the above code comes to you for review.
>>>>>>
>>>>>> So, will you tell the developer to use size_t for 'n' or let the
>>>>>> developer keep using long for 'n'.
>>>>>
>>>>> If LONG_MAX > SIZE_MAX, this code fails to catch all of the possible
>>>>> erroneous values for n. It should be if(n < 0 || n > SIZE_MAX).
>>>>>
>>>>> If LONG_MAX < SIZE_MAX, this code prevents copying of blocks of memory
>>>>> that memcpy() could be used for.
>>>>>
>>>>> Keep in mind that LONG_MAX can be (and on some real-world systems, has
>>>>> been) either much larger than SIZE_MAX, or much smaller than it, so
>>>>> these are not minor quibbles. For instance, long might be a 64 bit
>>>>> type,
>>>>> while size_t could be a 32 bit type, or vice-versa.
>>>>>
>>>>
>>>> It is not just "has been", but "is". On 64-bit Windows (which, I
>>>> hear, is quite popular in some circles) you have 64-bit "size_t" and
>>>> 32-bit "long".
>>>>
>>>> On 8-bit and 16-bit microcontrollers - which outsell 64-bit
>>>> processors by a long way - you have 16-bit "size_t" and 32-bit "long".
>>>
>>> Iirc, LONG on windows has to be 32-bits or the proverbial shi% will
>>> hit the fan? Legacy from their internal impl?
>>
>> So, what /is/ the purpose of long?
>
> [...]
>
> Wrt to the realm of Windows, imvvho, the purpose of long is to be
> 32-bits, ala their compiler, MSVC? LONG vs long, well, we make a
> compiler... All your base or belong to us?
>
Fwiw and afaict, this is source code to the real nt 4.0 kernel:
https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos
LONG, or long in MSVC, has to be 32-bits for legacy reasons.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-05 00:17 +0100 |
| Message-ID | <tmj9q3$3oq5l$6@dont-email.me> |
| In reply to | #168478 |
On 03/12/2022 22:48, Chris M. Thomasson wrote: > > Fwiw and afaict, this is source code to the real nt 4.0 kernel: Please do not post links to unlicensed copyrighted material. In most countries, it is unlawful to share or perhaps even view such material - in some other countries, it is also a crime. Certainly it is never a good thing, and completely unnecessary for your point.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-13 13:12 -0800 |
| Message-ID | <tnapsn$2jff0$4@dont-email.me> |
| In reply to | #168489 |
On 12/4/2022 3:17 PM, David Brown wrote: > On 03/12/2022 22:48, Chris M. Thomasson wrote: >> >> Fwiw and afaict, this is source code to the real nt 4.0 kernel: > > Please do not post links to unlicensed copyrighted material. In most > countries, it is unlawful to share or perhaps even view such material - > in some other countries, it is also a crime. Certainly it is never a > good thing, and completely unnecessary for your point. > > Argh!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-03 14:55 +0100 |
| Message-ID | <tmfkga$3bvnb$3@dont-email.me> |
| In reply to | #168433 |
On 02/12/2022 00:53, Bart wrote:
> On 01/12/2022 20:41, Chris M. Thomasson wrote:
>> On 12/1/2022 12:14 AM, David Brown wrote:
>>> On 01/12/2022 08:47, James Kuyper wrote:
>>>> On 12/1/22 02:31, A wrote:
>>>>>
>>>>> So, let's say a developer wrote some code like this:
>>>>>
>>>>> error_t copy_bytes(void *dest, const void *src, long n)
>>>>> {
>>>>>
>>>>> if ((!dest) || (!src))
>>>>> return ENULL;
>>>>>
>>>>> if (n < 0)
>>>>> return ENEGATIVESIZE;
>>>>>
>>>>> memcpy(dest, src, size_t(n));
>>>>>
>>>>> return ESUCCESS;
>>>>>
>>>>> }
>>>>>
>>>>> Now, the above code comes to you for review.
>>>>>
>>>>> So, will you tell the developer to use size_t for 'n' or let the
>>>>> developer keep using long for 'n'.
>>>>
>>>> If LONG_MAX > SIZE_MAX, this code fails to catch all of the possible
>>>> erroneous values for n. It should be if(n < 0 || n > SIZE_MAX).
>>>>
>>>> If LONG_MAX < SIZE_MAX, this code prevents copying of blocks of memory
>>>> that memcpy() could be used for.
>>>>
>>>> Keep in mind that LONG_MAX can be (and on some real-world systems, has
>>>> been) either much larger than SIZE_MAX, or much smaller than it, so
>>>> these are not minor quibbles. For instance, long might be a 64 bit
>>>> type,
>>>> while size_t could be a 32 bit type, or vice-versa.
>>>>
>>>
>>> It is not just "has been", but "is". On 64-bit Windows (which, I
>>> hear, is quite popular in some circles) you have 64-bit "size_t" and
>>> 32-bit "long".
>>>
>>> On 8-bit and 16-bit microcontrollers - which outsell 64-bit
>>> processors by a long way - you have 16-bit "size_t" and 32-bit "long".
>>
>> Iirc, LONG on windows has to be 32-bits or the proverbial shi% will
>> hit the fan? Legacy from their internal impl?
>
> So, what /is/ the purpose of long?
>
> Since you already have 'int', and 'long long' which is usually wider,
> why a third type which will be the same width as one of those?
>
That's like asking why there is the number "2" when we already have "1"
and "3". "long" came before "long long".
> If int/long long are assumed to be 32/64 bits, is 'long' then used on
> Linux as a type which matches the machine word size?
int/long should /not/ be assumed to be a particular length. "int" is
intended to be a fast general purpose signed integer type, of minimum
size 16-bit. "long" has minimum size 32-bit, and "long long" has
minimum size 64-bit. Beyond that, it's all platform specific.
If you live in the world of PC's and "big" systems, "int" is 32-bit. If
your code is already using graphics, files, networking, Windows calls,
POSIX calls, then I see nothing wrong with assuming "int" is 32-bit -
it's never going to work on a 16-bit microcontroller or a 64-bit int
Cray supercomputer.
Assuming anything about "long", beyond its minimum size, is another
matter. There are lots of targets for which it is 32-bit, and lots for
which it is 64-bit. It's not a type size I personally make use of,
except occasionally to match existing API's or code.
>
> I suspect that it's rarely used for that purpose!
>
> What is the history of long anyway: was it typically 32 bits when int
> was 16 bits? Then it's a question of what happened when int became 32
> bits too.
Yes. Long has always been "at least 32-bit", and before 64-bit
computing, it was almost always /exactly/ 32-bit, matching register
sizes. When 64-bit came to the *nix world in the late 1980's and early
1990's, it was clear that C implementations needed a 64-bit integer
type, so "long" was made 64-bit - C99 did not exist at that point, so
"long long" was not an option. As with the move to 32-bit, MS Windows
was about a decade late in their first steps into 64-bit computing (XP
for the Itanium, used by almost no one) and took another decade before
making it mainstream. For some reason, they decided to be awkward and
keep "long" as 32-bit - despite not supporting C99 and "long long", and
thus having no "normal" 64-bit integer type. Maybe it was intentional
as part of their war against C and cross-platform software.
>
> One OS took the decision to keep 'long' the same on both 32 and 64
> machines, and another decided it would vary between 32 and 64 bits
> machines, also deciding that 'long long' should be 64 bits on both and
> not 64/128 bits.
>
> So people used to writing 'long' everywhere for a 32-bit value instead
> of 'int', now had a type wider than expected and taking more memory on
> the 64-bit machine.
>
When you make unwarranted assumptions, you get things wrong. People
have always made assumptions that break later. The size of "long" in C
is a fine example of this, but it is not unique to C. (If you assumed
"long" was always 32-bit, you were wrong on 64-bit *nix. If you assumed
it was the same size as "size_t" or as pointers, you were wrong on
Windows 64-bit. If you assumed merely that "long" is at least 32-bit
and used "size_t" appropriately, your code was fine on any system. You
also got things right by using "uintptr_t", "int64_t", etc., but those
did not exist before C99.)
> And those using relying on 'long' being 64-bits, may get a surprise when
> their program is compiled for 64 bits.
>
Don't rely on unwarranted assumptions - especially ones that are clearly
wrong.
> Which OS made the right decision?
*nix. It was inevitable that unwarranted assumptions would be broken,
but 64-bit "long" broke less. The MS decision to use 32-bit "long" for
64-bit Itanium was a bad idea, different from what everyone else was
doing in 64-bit computing. Having got it wrong then, they stuck with it
for x86-64.
Outside of Windows, "int" can be thought of as "simple and efficient
general-purpose integer type", and "long" can be thought of as "biggest
native general purpose type".
>
> My view is that it's crazy having 5 integer types to represent 4 widths
> anyway, and you see that on both OSes.
>
> While a target-specific type (related to machine word size rather than
> address size) should not be one of those general integer types.
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-12-03 09:35 -0500 |
| Message-ID | <W8JiL.48551$f9D6.14175@fx09.iad> |
| In reply to | #168463 |
On 12/3/22 8:55 AM, David Brown wrote: >> > > Yes. Long has always been "at least 32-bit", and before 64-bit > computing, it was almost always /exactly/ 32-bit, matching register > sizes. When 64-bit came to the *nix world in the late 1980's and early > 1990's, it was clear that C implementations needed a 64-bit integer > type, so "long" was made 64-bit - C99 did not exist at that point, so > "long long" was not an option. As with the move to 32-bit, MS Windows > was about a decade late in their first steps into 64-bit computing (XP > for the Itanium, used by almost no one) and took another decade before > making it mainstream. For some reason, they decided to be awkward and > keep "long" as 32-bit - despite not supporting C99 and "long long", and > thus having no "normal" 64-bit integer type. Maybe it was intentional > as part of their war against C and cross-platform software. My understanding was that they had too much code the assumed long was 32 bits, and they remebered the problems when int moved from 16 to 32 bits, so they didn't want a repeat. Microsoft has long been more focused on their own developer needs for their compliers than their actual outside customers, which is one reason their C complier lagged so badly, they didn't need, or want, a more modern C, as their focus was C++ (and later language) for new applications, and they didn't want to break the exsiting C base.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-12-03 14:56 +0000 |
| Message-ID | <tmfo26$371$1@gioia.aioe.org> |
| In reply to | #168463 |
On 03/12/2022 13:55, David Brown wrote:
> On 02/12/2022 00:53, Bart wrote:
>> So, what /is/ the purpose of long?
>>
>> Since you already have 'int', and 'long long' which is usually wider,
>> why a third type which will be the same width as one of those?
>>
>
> That's like asking why there is the number "2" when we already have "1"
> and "3". "long" came before "long long".
Let's call the first 3 integer types of C, "A", "B", "C" corresponding
to 'int', 'long', 'long long'.
So, on the typical hardware I'm talking about, it will have started like
this:
A B C
Any system 16 32 -- bits
That seems reasonable enough (I don't know when 'long long' arrived).
When 'int' moved to 32 bits however, the landscape eventually looked
like this:
A B C
Windows 32 32 32 64 bits
Windows 64 32 32 64
Linux 32 32 32 64
Linux 64 32 64 64
Whichever way you look at it, this looks wrong:
* 3 columns but only two different widths
* A and B are the same in Windows and Linux 32
* B and C are the same in Linux 64
* Where is the 128-bit width?
At least Windows here has consistent types!
If you want 32-bit int, column A is guaranteed to provide that.
If you want 64-bit int, column C is guaranteed to provide that.
So, what /is/ the purpose of column B, ie. 'long'?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-12-03 15:33 -0500 |
| Message-ID | <8oOiL.44413$i761.8583@fx17.iad> |
| In reply to | #168465 |
On 12/3/22 9:56 AM, Bart wrote: > On 03/12/2022 13:55, David Brown wrote: >> On 02/12/2022 00:53, Bart wrote: > >>> So, what /is/ the purpose of long? >>> >>> Since you already have 'int', and 'long long' which is usually wider, >>> why a third type which will be the same width as one of those? >>> >> >> That's like asking why there is the number "2" when we already have >> "1" and "3". "long" came before "long long". > > Let's call the first 3 integer types of C, "A", "B", "C" corresponding > to 'int', 'long', 'long long'. > > So, on the typical hardware I'm talking about, it will have started like > this: > > A B C > > Any system 16 32 -- bits > > That seems reasonable enough (I don't know when 'long long' arrived). > > When 'int' moved to 32 bits however, the landscape eventually looked > like this: > > A B C > > Windows 32 32 32 64 bits > Windows 64 32 32 64 > > Linux 32 32 32 64 > Linux 64 32 64 64 > > Whichever way you look at it, this looks wrong: > > * 3 columns but only two different widths > > * A and B are the same in Windows and Linux 32 > > * B and C are the same in Linux 64 > > * Where is the 128-bit width? > > At least Windows here has consistent types! > > If you want 32-bit int, column A is guaranteed to provide that. > If you want 64-bit int, column C is guaranteed to provide that. > > So, what /is/ the purpose of column B, ie. 'long'? > > > You are missing the earlier definition char short int long 16 bit systems 8 16 16 32 32 bit systems 8 16 32 32 later long long 32 8 16 32 32 64 W64 8 16 32 32 64 L64 8 16 32 64 64 So, int started out being the variable size, that was typically 16 or 32 bits depeding on which one best fit the machine. When the registers moved to 64 bits, it was generally agreed that int shouldn't move up to that, as that left a hole at 32 bits, which is a handy size, you could have moved short to 32 bits, but then their is missing a 16 bit size. Windows left long at 32 bits, (from what I understood) because too much software and API's had assumed and fixed "long" to be 32 bits. so they kept it that size. Linux didn't have as much base with that assumption built in, so was able to go to the more reasonable option. For the 128 bit type, there is always the ability to just define an int128_t. The problem is that this messes up the definiton of intmax_t in API, so it is often spelt as __int128_t and define in a way to NOT need to change the type of intmax_t.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2022-12-03 20:51 +0000 |
| Message-ID | <tmgcs2$3c4vr$1@dont-email.me> |
| In reply to | #168472 |
On Sat, 03 Dec 2022 15:33:05 -0500, Richard Damon wrote:
[snip]
> You are missing the earlier definition
And, an even earlier definition
DEC Honeywell IBM Interdata
PDP11 6000 370 8/38
------- ------- ------- -------
(ASCII) (ASCII) (EBCDIC) (ASCII)
char 8 bits 9 bits 8 bits 8 bits
int 16 bits 36 bits 32 bits 32 bits
short 16 bits 36 bits 16 bits 16 bits
long 32 bits 36 bits 32 bits 32 bits
float 32 bits 36 bits 32 bits 32 bits
double 64 bits 72 bits 64 bits 64 bits
(from "Appendix A: C Reference Manual"
"The C Programming Language" by Brian W. Kernighan and Dennis M. Ritchie
Copyright 1978 by Bell Telephone Laboratories, Incorporated)
[snip]
The "standards" have often codified current practice, with
an eye on future directions. It helps to know where the language
started and how it was used to see where it is going.
--
Lew Pitcher
"In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-12-03 15:58 -0500 |
| Message-ID | <pMOiL.105478$Q0m1.85084@fx18.iad> |
| In reply to | #168474 |
On 12/3/22 3:51 PM, Lew Pitcher wrote: > On Sat, 03 Dec 2022 15:33:05 -0500, Richard Damon wrote: > > [snip] >> You are missing the earlier definition > > And, an even earlier definition > > DEC Honeywell IBM Interdata > PDP11 6000 370 8/38 > ------- ------- ------- ------- > (ASCII) (ASCII) (EBCDIC) (ASCII) > char 8 bits 9 bits 8 bits 8 bits > int 16 bits 36 bits 32 bits 32 bits > short 16 bits 36 bits 16 bits 16 bits > long 32 bits 36 bits 32 bits 32 bits > float 32 bits 36 bits 32 bits 32 bits > double 64 bits 72 bits 64 bits 64 bits > > (from "Appendix A: C Reference Manual" > "The C Programming Language" by Brian W. Kernighan and Dennis M. Ritchie > Copyright 1978 by Bell Telephone Laboratories, Incorporated) > > [snip] > > The "standards" have often codified current practice, with > an eye on future directions. It helps to know where the language > started and how it was used to see where it is going. > But I know that Bart isn't interested in any processor that isn't like his x86 machines with 8 bit addressable bytes.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2022-12-03 21:12 +0000 |
| Message-ID | <tmge44$3c4vr$2@dont-email.me> |
| In reply to | #168475 |
On Sat, 03 Dec 2022 15:58:58 -0500, Richard Damon wrote: > On 12/3/22 3:51 PM, Lew Pitcher wrote: >> On Sat, 03 Dec 2022 15:33:05 -0500, Richard Damon wrote: >> >> [snip] >>> You are missing the earlier definition >> >> And, an even earlier definition >> >> DEC Honeywell IBM Interdata >> PDP11 6000 370 8/38 >> ------- ------- ------- ------- >> (ASCII) (ASCII) (EBCDIC) (ASCII) >> char 8 bits 9 bits 8 bits 8 bits >> int 16 bits 36 bits 32 bits 32 bits >> short 16 bits 36 bits 16 bits 16 bits >> long 32 bits 36 bits 32 bits 32 bits >> float 32 bits 36 bits 32 bits 32 bits >> double 64 bits 72 bits 64 bits 64 bits >> >> (from "Appendix A: C Reference Manual" >> "The C Programming Language" by Brian W. Kernighan and Dennis M. Ritchie >> Copyright 1978 by Bell Telephone Laboratories, Incorporated) >> >> [snip] >> >> The "standards" have often codified current practice, with >> an eye on future directions. It helps to know where the language >> started and how it was used to see where it is going. >> > > But I know that Bart isn't interested in any processor that isn't like > his x86 machines with 8 bit addressable bytes. So? That leaves the DEC PDP11, IBM 370 and Interdata 8/32 sizes still in play. Each had 8bit addressable bytes (the Honeywell's bytes were 9bit, but still byte addressable). -- Lew Pitcher "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-12-03 17:22 -0500 |
| Message-ID | <Q_PiL.105498$Q0m1.67153@fx18.iad> |
| In reply to | #168477 |
On 12/3/22 4:12 PM, Lew Pitcher wrote: > On Sat, 03 Dec 2022 15:58:58 -0500, Richard Damon wrote: > >> On 12/3/22 3:51 PM, Lew Pitcher wrote: >>> On Sat, 03 Dec 2022 15:33:05 -0500, Richard Damon wrote: >>> >>> [snip] >>>> You are missing the earlier definition >>> >>> And, an even earlier definition >>> >>> DEC Honeywell IBM Interdata >>> PDP11 6000 370 8/38 >>> ------- ------- ------- ------- >>> (ASCII) (ASCII) (EBCDIC) (ASCII) >>> char 8 bits 9 bits 8 bits 8 bits >>> int 16 bits 36 bits 32 bits 32 bits >>> short 16 bits 36 bits 16 bits 16 bits >>> long 32 bits 36 bits 32 bits 32 bits >>> float 32 bits 36 bits 32 bits 32 bits >>> double 64 bits 72 bits 64 bits 64 bits >>> >>> (from "Appendix A: C Reference Manual" >>> "The C Programming Language" by Brian W. Kernighan and Dennis M. Ritchie >>> Copyright 1978 by Bell Telephone Laboratories, Incorporated) >>> >>> [snip] >>> >>> The "standards" have often codified current practice, with >>> an eye on future directions. It helps to know where the language >>> started and how it was used to see where it is going. >>> >> >> But I know that Bart isn't interested in any processor that isn't like >> his x86 machines with 8 bit addressable bytes. > > So? That leaves the DEC PDP11, IBM 370 and Interdata 8/32 > sizes still in play. Each had 8bit addressable bytes (the > Honeywell's bytes were 9bit, but still byte addressable). > And DEC PDP11 is the 16 bit valus, and the others the 32 bit values that I mentioned, so they are covered.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-12-03 23:58 +0000 |
| Message-ID | <tmgnqk$1rn5$1@gioia.aioe.org> |
| In reply to | #168475 |
On 03/12/2022 20:58, Richard Damon wrote: > On 12/3/22 3:51 PM, Lew Pitcher wrote: >> On Sat, 03 Dec 2022 15:33:05 -0500, Richard Damon wrote: >> >> [snip] >>> You are missing the earlier definition >> >> And, an even earlier definition >> >> DEC Honeywell IBM Interdata >> PDP11 6000 370 8/38 >> ------- ------- ------- ------- >> (ASCII) (ASCII) (EBCDIC) (ASCII) >> char 8 bits 9 bits 8 bits 8 bits >> int 16 bits 36 bits 32 bits 32 bits >> short 16 bits 36 bits 16 bits 16 bits >> long 32 bits 36 bits 32 bits 32 bits >> float 32 bits 36 bits 32 bits 32 bits >> double 64 bits 72 bits 64 bits 64 bits >> >> (from "Appendix A: C Reference Manual" >> "The C Programming Language" by Brian W. Kernighan and Dennis M. >> Ritchie >> Copyright 1978 by Bell Telephone Laboratories, Incorporated) >> >> [snip] >> >> The "standards" have often codified current practice, with >> an eye on future directions. It helps to know where the language >> started and how it was used to see where it is going. >> > > But I know that Bart isn't interested in any processor that isn't like > his x86 machines with 8 bit addressable bytes. No, and why should I be? For at least the last 40 years all machines of interest have been byte-addressable and with power-of-two word sizes. It wasn't just x86, but pretty much all of them. Including three in that chart. To go with the Honeywell, you could have added the PDP10 also with 36-bit word sizes. That one I /was/ interested in for a while as I used it for some years and wrote my first compiler for. But that's now history. There must be at least a dozen languages with fixed-width 8/16/32/64-bit integer types. There the denotations for those types make it quite clear what the sizes are, with no ambiguity and no overlap. In my 2017 C implementation, I tried to design out the need for 'long', but had to have it because programs used it. Then it was just a synonym for 'int' since it targeted Windows.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-12-03 19:25 -0500 |
| Message-ID | <uORiL.75022$Use.49896@fx15.iad> |
| In reply to | #168481 |
On 12/3/22 6:58 PM, Bart wrote: > On 03/12/2022 20:58, Richard Damon wrote: >> On 12/3/22 3:51 PM, Lew Pitcher wrote: >>> On Sat, 03 Dec 2022 15:33:05 -0500, Richard Damon wrote: >>> >>> [snip] >>>> You are missing the earlier definition >>> >>> And, an even earlier definition >>> >>> DEC Honeywell IBM Interdata >>> PDP11 6000 370 8/38 >>> ------- ------- ------- ------- >>> (ASCII) (ASCII) (EBCDIC) (ASCII) >>> char 8 bits 9 bits 8 bits 8 bits >>> int 16 bits 36 bits 32 bits 32 bits >>> short 16 bits 36 bits 16 bits 16 bits >>> long 32 bits 36 bits 32 bits 32 bits >>> float 32 bits 36 bits 32 bits 32 bits >>> double 64 bits 72 bits 64 bits 64 bits >>> >>> (from "Appendix A: C Reference Manual" >>> "The C Programming Language" by Brian W. Kernighan and Dennis M. >>> Ritchie >>> Copyright 1978 by Bell Telephone Laboratories, Incorporated) >>> >>> [snip] >>> >>> The "standards" have often codified current practice, with >>> an eye on future directions. It helps to know where the language >>> started and how it was used to see where it is going. >>> >> >> But I know that Bart isn't interested in any processor that isn't like >> his x86 machines with 8 bit addressable bytes. > > No, and why should I be? For at least the last 40 years all machines of > interest have been byte-addressable and with power-of-two word sizes. It > wasn't just x86, but pretty much all of them. > > Including three in that chart. To go with the Honeywell, you could have > added the PDP10 also with 36-bit word sizes. > > That one I /was/ interested in for a while as I used it for some years > and wrote my first compiler for. But that's now history. > > There must be at least a dozen languages with fixed-width 8/16/32/64-bit > integer types. > > There the denotations for those types make it quite clear what the sizes > are, with no ambiguity and no overlap. > > In my 2017 C implementation, I tried to design out the need for 'long', > but had to have it because programs used it. Then it was just a synonym > for 'int' since it targeted Windows. Non-byte addressable still lives on in DSP type processors, which still have desire for parts of the code to be reasonably portable. Some implementaitons choose to make char large, and some choose to make char* pointers fat.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-12-03 23:44 +0000 |
| Message-ID | <tmgn1m$1ejb$1@gioia.aioe.org> |
| In reply to | #168474 |
On 03/12/2022 20:51, Lew Pitcher wrote: > On Sat, 03 Dec 2022 15:33:05 -0500, Richard Damon wrote: > > [snip] >> You are missing the earlier definition > > And, an even earlier definition > > DEC Honeywell IBM Interdata > PDP11 6000 370 8/38 > ------- ------- ------- ------- > (ASCII) (ASCII) (EBCDIC) (ASCII) > char 8 bits 9 bits 8 bits 8 bits > int 16 bits 36 bits 32 bits 32 bits > short 16 bits 36 bits 16 bits 16 bits Wasn't PDP11 one of the earliest machines for which C was implemented? If so it was add to have invented a 'short' type for which there was no need.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-12-03 19:22 -0500 |
| Message-ID | <8LRiL.75021$Use.68137@fx15.iad> |
| In reply to | #168480 |
On 12/3/22 6:44 PM, Bart wrote: > On 03/12/2022 20:51, Lew Pitcher wrote: >> On Sat, 03 Dec 2022 15:33:05 -0500, Richard Damon wrote: >> >> [snip] >>> You are missing the earlier definition >> >> And, an even earlier definition >> >> DEC Honeywell IBM Interdata >> PDP11 6000 370 8/38 >> ------- ------- ------- ------- >> (ASCII) (ASCII) (EBCDIC) (ASCII) >> char 8 bits 9 bits 8 bits 8 bits >> int 16 bits 36 bits 32 bits 32 bits >> short 16 bits 36 bits 16 bits 16 bits > > Wasn't PDP11 one of the earliest machines for which C was implemented? > > If so it was add to have invented a 'short' type for which there was no > need. > > No, because it wasn't the ONLY machine targeted. If you look at the early implementations, it started on both 16 and 32 bit machines (as well as the odd byte sizes), so int was a type that normally did double duty with another type, but having a type that scaled with the machine was very useful for the target task, OS / Application portability.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2022-12-03 16:41 +0000 |
| Message-ID | <I3idnSLN7sHK4Rb-nZ2dnZfqnPSdnZ2d@brightview.co.uk> |
| In reply to | #168433 |
On 01/12/2022 23:53, Bart wrote:
> On 01/12/2022 20:41, Chris M. Thomasson wrote:
>> On 12/1/2022 12:14 AM, David Brown wrote:
>>> On 01/12/2022 08:47, James Kuyper wrote:
>>>> On 12/1/22 02:31, A wrote:
>>>>>
>>>>> So, let's say a developer wrote some code like this:
>>>>>
>>>>> error_t copy_bytes(void *dest, const void *src, long n)
>>>>> {
>>>>>
>>>>> if ((!dest) || (!src))
>>>>> return ENULL;
>>>>>
>>>>> if (n < 0)
>>>>> return ENEGATIVESIZE;
>>>>>
>>>>> memcpy(dest, src, size_t(n));
>>>>>
>>>>> return ESUCCESS;
>>>>>
>>>>> }
>>>>>
>>>>> Now, the above code comes to you for review.
>>>>>
>>>>> So, will you tell the developer to use size_t for 'n' or let the developer keep using long for
>>>>> 'n'.
>>>>
>>>> If LONG_MAX > SIZE_MAX, this code fails to catch all of the possible
>>>> erroneous values for n. It should be if(n < 0 || n > SIZE_MAX).
>>>>
>>>> If LONG_MAX < SIZE_MAX, this code prevents copying of blocks of memory
>>>> that memcpy() could be used for.
>>>>
>>>> Keep in mind that LONG_MAX can be (and on some real-world systems, has
>>>> been) either much larger than SIZE_MAX, or much smaller than it, so
>>>> these are not minor quibbles. For instance, long might be a 64 bit type,
>>>> while size_t could be a 32 bit type, or vice-versa.
>>>>
>>>
>>> It is not just "has been", but "is". On 64-bit Windows (which, I hear, is quite popular in some
>>> circles) you have 64-bit "size_t" and 32-bit "long".
>>>
>>> On 8-bit and 16-bit microcontrollers - which outsell 64-bit processors by a long way - you have
>>> 16-bit "size_t" and 32-bit "long".
>>
>> Iirc, LONG on windows has to be 32-bits or the proverbial shi% will hit the fan? Legacy from their
>> internal impl?
>
> So, what /is/ the purpose of long?
>
> Since you already have 'int', and 'long long' which is usually wider, why a third type which will be
> the same width as one of those?
>
> If int/long long are assumed to be 32/64 bits, is 'long' then used on Linux as a type which matches
> the machine word size?
>
> I suspect that it's rarely used for that purpose!
>
> What is the history of long anyway: was it typically 32 bits when int was 16 bits? Then it's a
> question of what happened when int became 32 bits too.
>
> One OS took the decision to keep 'long' the same on both 32 and 64 machines, and another decided it
> would vary between 32 and 64 bits machines, also deciding that 'long long' should be 64 bits on both
> and not 64/128 bits.
(An OS does not get to decide the size of long - that's decided by the compiler.)
>
> So people used to writing 'long' everywhere for a 32-bit value instead of 'int', now had a type
> wider than expected and taking more memory on the 64-bit machine.
>
> And those using relying on 'long' being 64-bits, may get a surprise when their program is compiled
> for 64 bits.
>
> Which OS made the right decision?
I recall one of those Microsoft blogs by a compiler team person explaining that Microsoft took the
decision on the basis of ease of conversion of apps from 32 to 64 bit, based (I assume) on their own
internal apps experience. The thinking was that apps already using int didn't need 64 bits for
their ints, and automatically giving them 64 bits would result in 32 bits being "wasted". For many
apps that's hardly a problem, but for apps with lots of large tables containing ints this might mean
a significant increase in working set size which they wanted to avoid. [Specifically, I think the
MSVC compiler itself was one of these test bed cases, and this issue applied for MSVC.]
Mike.
>
> My view is that it's crazy having 5 integer types to represent 4 widths anyway, and you see that on
> both OSes.
>
> While a target-specific type (related to machine word size rather than address size) should not be
> one of those general integer types.
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-12-03 17:24 +0000 |
| Message-ID | <tmg0o5$6bu$1@gioia.aioe.org> |
| In reply to | #168469 |
On 03/12/2022 16:41, Mike Terry wrote: > On 01/12/2022 23:53, Bart wrote: >> One OS took the decision to keep 'long' the same on both 32 and 64 >> machines, and another decided it would vary between 32 and 64 bits >> machines, also deciding that 'long long' should be 64 bits on both and >> not 64/128 bits. > > (An OS does not get to decide the size of long - that's decided by the > compiler.) Not really. Compilers need to follow the choice made on that platform, otherwise there will be all sorts of problems in working with code across compilers and across languages. Hence all C compilers under an OS need to conform, as seems to be the case under both Windows and Linux. But who made that choice? If it's the compiler, who decides which compiler gets to choose? Is it the C compiler used to build some or all of the OS? Those who complain about C on Windows tend to blame MS, the same people responsible for the OS.
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web