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 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-11-19 01:41 -0500 |
| Message-ID | <tl9trn$367b8$2@dont-email.me> |
| In reply to | #168200 |
On 11/17/22 03:28, Amit wrote: > On Thursday, November 17, 2022 at 1:46:14 PM UTC+5:30, Amit wrote: ... >> Amit > > To shorten the discussion and making it to the point, I would like to > know why is size_t used in malloc() when a negative value (passed by > user by mistake) can crash the program. Using long and checking for > negative values can prevent the program from crashing. It shouldn't crash the program. Any negative value passed to malloc() automatically gets converted to size_t. Such conversions always succeed and have a well-defined result. Any value of type size_t is a valid argument for malloc(). If that value is too large to be allocated, malloc() may return a null value, but it is not permitted to crash the program. Since any non-zero value passed to malloc() might result in a failure, you should always check the value returned by malloc(), and take appropriate action if that value is null. If you do so, a null value shouldn't crash your program.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-11-17 09:37 +0000 |
| Message-ID | <20221117013152.957@kylheku.com> |
| In reply to | #168199 |
On 2022-11-17, Amit <amitchoudhary0523@gmail.com> wrote:
> On Thursday, November 17, 2022 at 1:14:49 PM UTC+5:30, james...@alumni.caltech.edu wrote:
>> On 11/17/22 01:20, Amit wrote:
>> > Hi,
>> >
>> > I prefer long over size_t.
> [ ... ]
> I am not talking about signed vs unsigned.
Effectively, you are, because long is signed, by definition; and size_t
is unsigned, by definition.
> What reasons glibc original authors had when they used size_t in these functions instead of long.
They were conforming to the requirements written in the ISO C standard,
which defines those functions.
>
> If we don't know those reasons then if a developer has to implement a function called allocate_memory() then which implementation should he use and WHY?
>
> Implementation 1:
> -----------------------------
>
> void *allocate_memory(size_t len)
> {
> }
This can easily express the allocation of 3Gb on a 32 bit system, or 48K on a 16 bit system.
>
> Implementation 2:
> -----------------------------
>
> void *allocate_memory(long len)
> {
> }
This forces a 16 bit system to wastefully pass the object size as a 32
bit operand, the top 16 bits of which will always be zero.
The function cannot express the allocation of more than 2Gb on a 32 bit system;
at least not with straightforward positive values.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-11-19 01:41 -0500 |
| Message-ID | <tl9tqu$367b8$1@dont-email.me> |
| In reply to | #168199 |
On 11/17/22 03:16, Amit wrote: > On Thursday, November 17, 2022 at 1:14:49 PM UTC+5:30, > james...@alumni.caltech.edu wrote: >> On 11/17/22 01:20, Amit wrote: >>> Hi, >>> I prefer long over size_t. >> For which purpose? C supports a large number of different types, >> precisely because different types are preferred for different >> purposes. More often than not, the type I need to use is dictated by >> the interfaces to standard and third-part libraries that I'm using. >> When I do have a choice in the matter, I prefer unsigned types like >> size_t in any context where bitwise operations are involved, because >> many of those operations can have undefined behavior under certain >> circumstances when using a signed types, but not with unsigned types. >> Unsigned types are often preferred when the quantity in question is >> incapable of being negative, though care must be used when applying >> this criterion. Operations involving quantities that cannot be >> negative, may have results that can be negative. If such operations >> are relevant to a particular variable, that variable should have a >> signed type. > > I am not talking about signed vs unsigned. True, but signed vs. unsigned is the most important difference between long and size_t that would affect decisions about which one to use. The only other difference is that long is guaranteed to be able to hold any value between -2147483648 and 2147483647, which requires at least 32 bits, while size_t is only required to have at least 16 bits (and on some systems is in fact that small). > What reasons glibc original authors had when they used size_t in these > functions instead of long. They wanted to match the existing implementations of malloc(). Keep in mind that C dates back to the early 70s. It was released to the general public by the publication of "The C programming language" in 1978. I started programming in C in 1979. What we now call the C standard library had already started taking form at that time, though it wasn't standardized until 1989. I'm not sure when in the process malloc() was added to that library, but I believe it was well before glibc came out in the late 1980s. > If we don't know those reasons then if a developer has to implement a > function called allocate_memory() then which implementation should he > use and WHY? Well, if he's creating an implementation of C, he should use the interface that has been specified for malloc(). If you were instead to ask the people who designed malloc() chose size_t, I would guess that it's because it is never valid to request a negative amount, so they chose an interface that guarantees that it will never receive a negative amount. It's also never valid for the size of a type to negative, which is why the value of a sizeof expression has the type size_t. In most cases, the value which should be passed to a malloc() call should be the result of a calculation involving size_t. Because of the way C's usual arithmetic conversions work, there's a very good chance that any such calculated value has, itself, a type of size_t, which is how it all fits together.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-19 12:56 -0800 |
| Message-ID | <87a64mmzmw.fsf@nosuchdomain.example.com> |
| In reply to | #168269 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 11/17/22 03:16, Amit wrote:
>> On Thursday, November 17, 2022 at 1:14:49 PM UTC+5:30,
>> james...@alumni.caltech.edu wrote:
>>> On 11/17/22 01:20, Amit wrote:
>>>> Hi,
>>>> I prefer long over size_t.
>>> For which purpose? C supports a large number of different types,
>>> precisely because different types are preferred for different
>>> purposes. More often than not, the type I need to use is dictated by
>>> the interfaces to standard and third-part libraries that I'm using.
>>> When I do have a choice in the matter, I prefer unsigned types like
>>> size_t in any context where bitwise operations are involved, because
>>> many of those operations can have undefined behavior under certain
>>> circumstances when using a signed types, but not with unsigned types.
>>> Unsigned types are often preferred when the quantity in question is
>>> incapable of being negative, though care must be used when applying
>>> this criterion. Operations involving quantities that cannot be
>>> negative, may have results that can be negative. If such operations
>>> are relevant to a particular variable, that variable should have a
>>> signed type.
>>
>> I am not talking about signed vs unsigned.
>
> True, but signed vs. unsigned is the most important difference between
> long and size_t that would affect decisions about which one to use. The
> only other difference is that long is guaranteed to be able to hold any
> value between -2147483648 and 2147483647, which requires at least 32
> bits, while size_t is only required to have at least 16 bits (and on
> some systems is in fact that small).
I suggest that the most important difference is that size_t is
guaranteed to be able to hold the size of any object, and long is not.
That difference is not directly implied by the standard's guarantees
about their ranges.
[...]
If there were a good reason to dislike size_t because it's an unsigned
type, one could probably use the signed type that corresponds to it,
which is long long in some implementations. That loses the ability to
represent very large size_t values, which might or might not matter
depending on the implementation. There is no straightforward way to
determine what that signed type is. (POSIX defines ssize_t, but it's not
specified to be the signed type corresponding to size_t, so for example
the "%du" format is not guaranteed to work with it.)
Or one could use a signed type that can hold all the values that size_t
can represent, but there might not be such a type. long long can almost
certainly hold all *meaningful* size_t values.
Unsigned types can be tricky, but anyone who wants to program in C needs
to deal with their idiosyncrasies. Accidentally passing a negative
value to malloc (which will be implicitly converted to a very large
positive value) just isn't a common enough error to be worth such a
drastic solution.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-11-19 13:03 -0800 |
| Message-ID | <tlbgae$39s3v$2@dont-email.me> |
| In reply to | #168292 |
On 11/19/2022 12:56 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On 11/17/22 03:16, Amit wrote: >>> On Thursday, November 17, 2022 at 1:14:49 PM UTC+5:30, >>> james...@alumni.caltech.edu wrote: >>>> On 11/17/22 01:20, Amit wrote: >>>>> Hi, >>>>> I prefer long over size_t. >>>> For which purpose? C supports a large number of different types, >>>> precisely because different types are preferred for different >>>> purposes. More often than not, the type I need to use is dictated by >>>> the interfaces to standard and third-part libraries that I'm using. >>>> When I do have a choice in the matter, I prefer unsigned types like >>>> size_t in any context where bitwise operations are involved, because >>>> many of those operations can have undefined behavior under certain >>>> circumstances when using a signed types, but not with unsigned types. >>>> Unsigned types are often preferred when the quantity in question is >>>> incapable of being negative, though care must be used when applying >>>> this criterion. Operations involving quantities that cannot be >>>> negative, may have results that can be negative. If such operations >>>> are relevant to a particular variable, that variable should have a >>>> signed type. >>> >>> I am not talking about signed vs unsigned. >> >> True, but signed vs. unsigned is the most important difference between >> long and size_t that would affect decisions about which one to use. The >> only other difference is that long is guaranteed to be able to hold any >> value between -2147483648 and 2147483647, which requires at least 32 >> bits, while size_t is only required to have at least 16 bits (and on >> some systems is in fact that small). > > I suggest that the most important difference is that size_t is > guaranteed to be able to hold the size of any object, and long is not. > That difference is not directly implied by the standard's guarantees > about their ranges. > > [...] > > If there were a good reason to dislike size_t because it's an unsigned > type, one could probably use the signed type that corresponds to it, [...] ptrdiff_t?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-11-19 21:17 +0000 |
| Message-ID | <QJbeL.70$zBQ2.65@fx40.iad> |
| In reply to | #168292 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On 11/17/22 03:16, Amit wrote: > (POSIX defines ssize_t, but it's not >specified to be the signed type corresponding to size_t, so for example >the "%du" format is not guaranteed to work with it.) %zu?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-19 17:41 -0800 |
| Message-ID | <87y1s6l7vw.fsf@nosuchdomain.example.com> |
| In reply to | #168294 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>> On 11/17/22 03:16, Amit wrote:
>> (POSIX defines ssize_t, but it's not
>>specified to be the signed type corresponding to size_t, so for example
>>the "%du" format is not guaranteed to work with it.)
>
> %zu?
No, I actually meant "%zd" (thanks for catching my error).
"%zu" expects an argument of type size_t. "%zd" expects an argument of
the signed type corresponding to size_t, but there's no good way to
determine what that type is.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-21 10:30 +0100 |
| Message-ID | <tlfgga$3pcmu$1@dont-email.me> |
| In reply to | #168298 |
On 20/11/2022 02:41, Keith Thompson wrote: > scott@slp53.sl.home (Scott Lurndal) writes: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >>>> On 11/17/22 03:16, Amit wrote: >>> (POSIX defines ssize_t, but it's not >>> specified to be the signed type corresponding to size_t, so for example >>> the "%du" format is not guaranteed to work with it.) >> >> %zu? > > No, I actually meant "%zd" (thanks for catching my error). > > "%zu" expects an argument of type size_t. "%zd" expects an argument of > the signed type corresponding to size_t, but there's no good way to > determine what that type is. > It's a pity you can't "return" a type from a _Generic. Otherwise you could have a _Generic macro Signed(T) that generated a signed version of its parameter. And even if your _Generic returns a number, it can't be used in pre-processing (for conditional compilation). sizeof(size_t) could be helpful, but I can't see any way to distinguish between different types of the same size (usually "long" is the same size as either "int" or "long long", but the type is different).
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-11-22 04:27 +0000 |
| Message-ID | <20221121202335.519@kylheku.com> |
| In reply to | #168320 |
On 2022-11-21, David Brown <david.brown@hesbynett.no> wrote: > It's a pity you can't "return" a type from a _Generic. Might it be that in GNU C you can, via typeof(_Generic(...))? -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-22 08:55 +0100 |
| Message-ID | <tlhv8p$22jq$1@dont-email.me> |
| In reply to | #168329 |
On 22/11/2022 05:27, Kaz Kylheku wrote: > On 2022-11-21, David Brown <david.brown@hesbynett.no> wrote: >> It's a pity you can't "return" a type from a _Generic. > > Might it be that in GNU C you can, via typeof(_Generic(...))? > That's a possibility I had not considered - I was trying to stick to standard C. If you allow common extensions, then "ssize_t" is surely the easiest solution! But it's an interesting idea and could give more general macros.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-11-20 01:33 -0500 |
| Message-ID | <tlchno$3f4tk$3@dont-email.me> |
| In reply to | #168292 |
On 11/19/22 15:56, Keith Thompson wrote: ... > I suggest that the most important difference is that size_t is > guaranteed to be able to hold the size of any object, and long is not. > That difference is not directly implied by the standard's guarantees > about their ranges. The standard doesn't quite say that about size_t. The standard does say that sizeof(type) gives the size of an object of that type, and that sizeof(expression) gives the size of an object of the type of that expression. But it's trivial to specify a type for which the size of that type cannot have a value within range of size_t: sizeof(char[2][SIZE_MAX]). Such an expression cannot have the behavior mandated by the C standard for such an expression, but it's less than perfectly clear how it's wrong. There's a great many functions in the C standard library that take a size_t parameter, and which therefore cannot be used in any context where the value to be passed to the function is larger than SIZE_MAX.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-19 22:50 -0800 |
| Message-ID | <87iljaktki.fsf@nosuchdomain.example.com> |
| In reply to | #168303 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 11/19/22 15:56, Keith Thompson wrote:
> ...
>> I suggest that the most important difference is that size_t is
>> guaranteed to be able to hold the size of any object, and long is not.
>> That difference is not directly implied by the standard's guarantees
>> about their ranges.
>
> The standard doesn't quite say that about size_t.
True (and I think I've actually said so here before).
> The standard does say that sizeof(type) gives the size of an object of
> that type, and that sizeof(expression) gives the size of an object of
> the type of that expression. But it's trivial to specify a type for
> which the size of that type cannot have a value within range of size_t:
> sizeof(char[2][SIZE_MAX]). Such an expression cannot have the behavior
> mandated by the C standard for such an expression, but it's less than
> perfectly clear how it's wrong.
My interpretation is that the sizeof operator can overflow, just like
most other operators can.
On the other hand, an implementation *should* IMHO make size_t big
enough to represent the size of any object it can create.
I vaguely recall a recent suggestion to require all objects to be no
more than SIZE_MAX bytes in size.
> There's a great many functions in the C standard library that take a
> size_t parameter, and which therefore cannot be used in any context
> where the value to be passed to the function is larger than SIZE_MAX.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2022-11-25 20:51 +0100 |
| Message-ID | <tlr6be$agkh$1@solani.org> |
| In reply to | #168307 |
Am 20.11.22 um 07:50 schrieb Keith Thompson: > > My interpretation is that the sizeof operator can overflow, just like > most other operators can. > > On the other hand, an implementation *should* IMHO make size_t big > enough to represent the size of any object it can create. Section 6.2.5, "Types", of the C23 standard has: "A complete type shall have a size that is less than or equal to SIZE_MAX. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-25 12:21 -0800 |
| Message-ID | <871qpqlr9p.fsf@nosuchdomain.example.com> |
| In reply to | #168350 |
Philipp Klaus Krause <pkk@spth.de> writes:
> Am 20.11.22 um 07:50 schrieb Keith Thompson:
>
>> My interpretation is that the sizeof operator can overflow, just
>> like
>> most other operators can.
>> On the other hand, an implementation *should* IMHO make size_t big
>> enough to represent the size of any object it can create.
>
> Section 6.2.5, "Types", of the C23 standard has: "A complete type
> shall have a size that is less than or equal to SIZE_MAX.
Yes (well, the N3054 draft does, but that will presumably be in the
published standard whenever it comes out).
Note that this is a "shall" outside a constraint, so any program that
violates it has undefined behavior.
Here's the proposal (by Jens Gustedt) that introduced that wording:
https://open-std.org/jtc1/sc22/wg14/www/docs/n2838.htm
The Rationale section says:
In view of our recent discussion about overflow in calloc, we did
some search into existing implementations and asked on the WG14
reflector and some other media if there could be objects defined
that with a size that exceeds SIZE_MAX. It turned out that all
interpret the current standard that huge objects make the behavior
implicitly undefined. This change here makes that explicit. In
particular, it makes it explicit that even requesting such a huge
object has no defined behavior.
and then:
This change is only a clarification and should not have an impact on
existing programs or implementations.
I would have suggested that the restriction should be a constraint (for
non-VLA types). It's likely that most or all existing compilers already
diagnose it.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-11-20 06:52 -0800 |
| Message-ID | <86r0xxadbj.fsf@linuxsc.com> |
| In reply to | #168303 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 11/19/22 15:56, Keith Thompson wrote:
> ...
>
>> I suggest that the most important difference is that size_t is
>> guaranteed to be able to hold the size of any object, and long is not.
>> That difference is not directly implied by the standard's guarantees
>> about their ranges.
>
> The standard doesn't quite say that about size_t.
>
> The standard does say that sizeof(type) gives the size of an object of
> that type, and that sizeof(expression) gives the size of an object of
> the type of that expression. But it's trivial to specify a type for
> which the size of that type cannot have a value within range of size_t:
> sizeof(char[2][SIZE_MAX]). Such an expression cannot have the behavior
> mandated by the C standard for such an expression, but it's less than
> perfectly clear how it's wrong.
Surely the intention is that such an expression runs afoul of the
constraint in 6.6 p4, and also that the program may be rejected
by virtue of exceeding a minimum implementation limit. On a
64-bit implementation, try compiling this:
printf( "%zu\n", sizeof (char[0xfffffffffffffffe]) );
Both gcc and clang reject this program, complaining about the
size implied by the type, even though the size is less than
SIZE_MAX (which is 0xffffffffffffffff in that compilation
environment).
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-11-17 09:31 +0000 |
| Message-ID | <20221117011851.690@kylheku.com> |
| In reply to | #168196 |
On 2022-11-17, Amit <amitchoudhary0523@gmail.com> wrote: > 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. The ANSI C standard was ratified in 1989; it specified a malloc function prototyped in <stdlib.h> like this: void *malloc(size_t); It has nothing to do with glibc. ANSI C made size_t an unsigned type because: - sizes of objects are never negative, so a type representing object size need not represent negative values. - at the time it was not unusual to have objects which needed the full unsigned range for expressing their size: like declaring a 60 kilobyte array under the "small" memory model on an Intel 8088 PC. The size would be a 16 bit type, which would have to be unsigned to capture the 60 kilobyte size. - Also relevant in 32 bits. Under 32 bits, a signed, 32 bit size_t means that only objects up to 2Gb have a meaningful sizeof value. Your preference for long spells trouble in a 16 bit system, because long must be at least 32 bits wide. That's wasteful and unnatural for object sizes in that system. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-17 02:43 -0800 |
| Message-ID | <02eee7cc-6d03-420f-adf6-d7b87592fe38n@googlegroups.com> |
| In reply to | #168201 |
> > - at the time it was not unusual to have objects which needed > the full unsigned range for expressing their size: > like declaring a 60 kilobyte array under the "small" > memory model on an Intel 8088 PC. The size would be a 16 > bit type, which would have to be unsigned to capture the > 60 kilobyte size. > Intel 8088 came in 1979. But C standard library came with C89 in 1989. In 1989, i486 was released. Size of "int" on i486 was 32 bits and probably RAM size was 4 MB (22 bits). I don't think that in 1989 C standard would have even thought about Intel 8088 (Intel 8088 would have been probably obsolete by 1989). In fact, i386 came in 1985 and size of "int" on it was also probably 32 bits. So, I don't think C89 would have thought about Intel 8088. Amit
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-17 10:02 -0800 |
| Message-ID | <87r0y1mpbk.fsf@nosuchdomain.example.com> |
| In reply to | #168207 |
A <amit234234234234@gmail.com> writes:
>> - at the time it was not unusual to have objects which needed
>> the full unsigned range for expressing their size:
>> like declaring a 60 kilobyte array under the "small"
>> memory model on an Intel 8088 PC. The size would be a 16
>> bit type, which would have to be unsigned to capture the
>> 60 kilobyte size.
>
> Intel 8088 came in 1979. But C standard library came with C89 in
> 1989. In 1989, i486 was released. Size of "int" on i486 was 32 bits
> and probably RAM size was 4 MB (22 bits). I don't think that in 1989 C
> standard would have even thought about Intel 8088 (Intel 8088 would
> have been probably obsolete by 1989).
>
> In fact, i386 came in 1985 and size of "int" on it was also probably 32 bits.
>
> So, I don't think C89 would have thought about Intel 8088.
In 1989, the Intel 8088 was 10 years old, and was still in extensive
use. Of course the ANSI C committee would have thought about 8088-based
systems. Even today, there are embedded systems with small word sizes.
And on Windows, size_t is 64 bits but long is only 32 bits.
C implementations are far more varied than the ones you or I have
encountered.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-18 10:19 +0100 |
| Message-ID | <tl7imq$2tihv$1@dont-email.me> |
| In reply to | #168207 |
On 17/11/2022 11:43, A wrote: >> >> - at the time it was not unusual to have objects which needed >> the full unsigned range for expressing their size: >> like declaring a 60 kilobyte array under the "small" >> memory model on an Intel 8088 PC. The size would be a 16 >> bit type, which would have to be unsigned to capture the >> 60 kilobyte size. >> > > Intel 8088 came in 1979. But C standard library came with C89 in 1989. In 1989, i486 was released. Size of "int" on i486 was 32 bits and probably RAM size was 4 MB (22 bits). I don't think that in 1989 C standard would have even thought about Intel 8088 (Intel 8088 would have been probably obsolete by 1989). > > In fact, i386 came in 1985 and size of "int" on it was also probably 32 bits. > > So, I don't think C89 would have thought about Intel 8088. > > Amit The 80386 and 80486 were used primarily as 16-bit systems, due to the incredible slowness of innovation in the Microsoft world - it wasn't until 2001 (with XP) that the most common versions of MS's OS's were actually 32-bit at core. They had hybrid Frankenstein's monsters with 16-bit kernel and some 32-bit user-land code (from Windows 3 through to Windows ME) or with 32-bit kernel and some 16-bit user-land code (original NT). So for most people, "int" on 80386 and 8046 was 16-bit. And your history of C is bizarre. The ANSI C standard in 1989 was a standardisation of /existing/ C common usage - it did not suddenly invent C and its standard library out of thin air. You also miss the point that the C standard is not remotely interested in what happens in the DOS/Windows/x86 world - it is designed to work with an enormous range of systems. That includes 8-bit devices, which still ship in similar numbers to 16-bit and 32-bit devices. (64-bit bit devices are minor in comparison, in terms of device numbers. Sale prices are a different matter entirely.)
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-18 01:46 -0800 |
| Message-ID | <2b19488a-2675-4dfd-9de8-11720bb222a7n@googlegroups.com> |
| In reply to | #168247 |
On Friday, 18 November 2022 at 14:49:36 UTC+5:30, David Brown wrote: > On 17/11/2022 11:43, A wrote: > >> > > And your history of C is bizarre. The ANSI C standard in 1989 was a > standardisation of /existing/ C common usage - it did not suddenly > invent C and its standard library out of thin air. > I was talking in context of glibc. glibc 0.1 came out in 1991. In 1988, glibc pre-release appeared. Link: https://sourceware.org/glibc/wiki/Glibc%20Timeline Amit
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web