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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-18 13:01 +0100 |
| Message-ID | <tl7s7j$2u9s6$1@dont-email.me> |
| In reply to | #168250 |
On 18/11/2022 10:46, A wrote: > > 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. > So when you wrote "C standard library came with C89 in 1989", you meant to write "glibc was released in 1991" ? It is /really/ difficult to figure out what you are trying to say here. Regardless of history, every C implementation of malloc() uses "size_t" because that is what the C standards have always said was required for the standard library. It's that simple. Pretty much every other allocation function written for C has followed the same style and used "size_t", because it is the appropriate type for the task.
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-18 04:56 -0800 |
| Message-ID | <a9ad1b4f-51a4-44fc-9998-fb473213176en@googlegroups.com> |
| In reply to | #168253 |
On Friday, 18 November 2022 at 17:32:09 UTC+5:30, David Brown wrote: > On 18/11/2022 10:46, A wrote: > > > > 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. > > > So when you wrote "C standard library came with C89 in 1989", you meant > to write "glibc was released in 1991" ? It is /really/ difficult to > figure out what you are trying to say here. > My assumption was that glibc original authors would have been part of C89 standardization committee. Amit
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-11-18 14:49 +0000 |
| Message-ID | <hYMdL.3892$dvL.3833@fx18.iad> |
| In reply to | #168258 |
A <amit234234234234@gmail.com> writes: >On Friday, 18 November 2022 at 17:32:09 UTC+5:30, David Brown wrote: >> On 18/11/2022 10:46, A wrote: >> > >> > 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. >> > >> So when you wrote "C standard library came with C89 in 1989", you meant >> to write "glibc was released in 1991" ? It is /really/ difficult to >> figure out what you are trying to say here. >> > >My assumption was that glibc original authors would have been part of C89 standardization committee. > You know what they say about assumptions.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-11-19 06:19 -0800 |
| Message-ID | <86mt8nc9h6.fsf@linuxsc.com> |
| In reply to | #168261 |
scott@slp53.sl.home (Scott Lurndal) writes: > A <amit234234234234@gmail.com> writes: > >> On Friday, 18 November 2022 at 17:32:09 UTC+5:30, David Brown wrote: >> >>> On 18/11/2022 10:46, A wrote: >>> >>>> 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. >>> >>> So when you wrote "C standard library came with C89 in 1989", you meant >>> to write "glibc was released in 1991" ? It is /really/ difficult to >>> figure out what you are trying to say here. >> >> My assumption was that glibc original authors would have been part of >> C89 standardization committee. > > You know what they say about assumptions. Makes an ass out of you and umption.
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-19 06:44 -0800 |
| Message-ID | <77ae6697-3960-46fe-9c32-fe4370038107n@googlegroups.com> |
| In reply to | #168277 |
On Saturday, 19 November 2022 at 19:50:04 UTC+5:30, Tim Rentsch wrote: > sc...@slp53.sl.home (Scott Lurndal) writes: > > > A <amit2342...@gmail.com> writes: > > > >> On Friday, 18 November 2022 at 17:32:09 UTC+5:30, David Brown wrote: > >> > >>> On 18/11/2022 10:46, A wrote: > >>> > >>>> 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. > >>> > >>> So when you wrote "C standard library came with C89 in 1989", you meant > >>> to write "glibc was released in 1991" ? It is /really/ difficult to > >>> figure out what you are trying to say here. > >> > >> My assumption was that glibc original authors would have been part of > >> C89 standardization committee. > > > > You know what they say about assumptions. > Makes an ass out of you and umption. People really lack group mail etiquettes. Tim, If your statement is directed at me, then I must say that you are an asshole. Amit
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-11-19 09:53 -0800 |
| Message-ID | <865yfade4s.fsf@linuxsc.com> |
| In reply to | #168281 |
A <amit234234234234@gmail.com> writes: > On Saturday, 19 November 2022 at 19:50:04 UTC+5:30, Tim Rentsch wrote: > >> sc...@slp53.sl.home (Scott Lurndal) writes: >> >>> A <amit2342...@gmail.com> writes: [...] >>>> My assumption was that glibc original authors would have been >>>> part of C89 standardization committee. >>> >>> You know what they say about assumptions. >> >> Makes an ass out of you and umption. > > People really lack group mail etiquettes. > > Tim, > > If your statement is directed at me, then I must say that you are > an asshole. My statement wasn't directed at you, nor at anyone else. Nothing in what I said was meant to be directed at anyone. It was simply a joke, a variation on the usual rejoinder to the word "assume". (Incidentally, I can't take credit for the joke - it's a line from the movie The Long Kiss Goodnight.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-11-19 02:23 -0500 |
| Message-ID | <tla09u$367b9$1@dont-email.me> |
| In reply to | #168258 |
On 11/18/22 07:56, A wrote: ... > My assumption was that glibc original authors would have been part of C89 standardization committee. When C89 was being created, not a single member of the committee was very familiar with either gcc or glibc. Many people have criticized the committee for this, but it was actually the fault of the Free Software Foundation (FSF). There's multiple committees that are relevant to this question, so I'll give a little background about the committees before directly explaining that comment. C89 was a US standard. It got taken over by ISO, which released almost exactly the same text as C90. They added 3 sections at the beginning of the standard to meet ISO requirements, which resulted in every section number after that being increased by 3 (which means every single cross-reference had to be updated, too), but it was otherwise almost identical. Each member of the ISO C committee is a national standardization organization. The single most influential member is the US one, primarily because it has better funding and a very large number of people working on it. When doing volunteer work, the people who can do the most work tend to have the most influence over what gets done. The US standardization committee is open to membership by almost anyone. As a result, many people who's country is not represented on the ISO committee, or whose national standard's organization is too expensive to join, participate by joining the US committee. That's one reason it has some many members. They only allow one committee member representing any given organization, except for "Self", but arbitrarily many people can choose "Self" as their organization. Non-voting membership is free, but you can be influential by participating in discussions even if you can't vote. Voting membership is slightly expensive for an individual, and includes a requirement that you attend in person at least 2 of the 3 annual meetings each year, but that's not a serious problem for any group as big as the Free Software Foundation. Despite that fact, no one from the FSF chose to participate in C89 (that changed in later versions of the standard). Keep in mind that gcc and glibc were both still very new at that time, and not many people outside FSF knew much about them.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-11-19 06:42 -0800 |
| Message-ID | <86edtzc8fc.fsf@linuxsc.com> |
| In reply to | #168274 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > C89 was a US standard. It got taken over by ISO, which released > almost exactly the same text as C90. They added 3 sections at the > beginning of the standard to meet ISO requirements, which resulted > in every section number after that being increased by 3 (which > means every single cross-reference had to be updated, too), but it > was otherwise almost identical. [...] For the most part the ISO (C90) standard uses exactly the same wording that was used in the ANSI (C89) standard (ignoring differences in numbering, like you say). In places though there are some non-trivial changes.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-19 10:00 -0500 |
| Message-ID | <Ub6eL.11105$fg35.3676@fx10.iad> |
| In reply to | #168280 |
On 11/19/22 9:42 AM, Tim Rentsch wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > >> C89 was a US standard. It got taken over by ISO, which released >> almost exactly the same text as C90. They added 3 sections at the >> beginning of the standard to meet ISO requirements, which resulted >> in every section number after that being increased by 3 (which >> means every single cross-reference had to be updated, too), but it >> was otherwise almost identical. [...] > > For the most part the ISO (C90) standard uses exactly the same > wording that was used in the ANSI (C89) standard (ignoring > differences in numbering, like you say). In places though there > are some non-trivial changes. My understanding was that, execpt for the early "boiler-plate" section added near the beginning which causes the numbering difference, the rest of the content was adopted verbatim. This accounts for the ISO version being adopted so quick after the ANSI version.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-11-19 10:09 -0800 |
| Message-ID | <861qpyddfd.fsf@linuxsc.com> |
| In reply to | #168283 |
Richard Damon <Richard@Damon-Family.org> writes: > On 11/19/22 9:42 AM, Tim Rentsch wrote: > >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> >>> C89 was a US standard. It got taken over by ISO, which released >>> almost exactly the same text as C90. They added 3 sections at the >>> beginning of the standard to meet ISO requirements, which resulted >>> in every section number after that being increased by 3 (which >>> means every single cross-reference had to be updated, too), but it >>> was otherwise almost identical. [...] >> >> For the most part the ISO (C90) standard uses exactly the same >> wording that was used in the ANSI (C89) standard (ignoring >> differences in numbering, like you say). In places though there >> are some non-trivial changes. > > My understanding was that, execpt for the early "boiler-plate" section > added near the beginning which causes the numbering difference, the > rest of the content was adopted verbatim. My observation is this. I have a copy of ansi.c.txt, which is supposed to be a text-based copy of the ANSI C standard (and presumably after the ANSI C standard was ratified). Perusing that document from time to time, and occasionally going back and forth between that and the first ISO C document, I happened to see passages in places that were different between the ANSI document and the ISO document. Indeed most of the text in the two documents is word-for-word identical, which made the few instances where there were discrepancies stand out rather vividly. Unfortunately I remember the fact of there being differences but not where they are specifically. But I am quite sure that I observed some differences in the wordings of the two documents.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-19 13:27 -0800 |
| Message-ID | <875yfamy8a.fsf@nosuchdomain.example.com> |
| In reply to | #168286 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 11/19/22 9:42 AM, Tim Rentsch wrote:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>> C89 was a US standard. It got taken over by ISO, which released
>>>> almost exactly the same text as C90. They added 3 sections at the
>>>> beginning of the standard to meet ISO requirements, which resulted
>>>> in every section number after that being increased by 3 (which
>>>> means every single cross-reference had to be updated, too), but it
>>>> was otherwise almost identical. [...]
>>>
>>> For the most part the ISO (C90) standard uses exactly the same
>>> wording that was used in the ANSI (C89) standard (ignoring
>>> differences in numbering, like you say). In places though there
>>> are some non-trivial changes.
>>
>> My understanding was that, execpt for the early "boiler-plate" section
>> added near the beginning which causes the numbering difference, the
>> rest of the content was adopted verbatim.
>
> My observation is this. I have a copy of ansi.c.txt, which is
> supposed to be a text-based copy of the ANSI C standard (and
> presumably after the ANSI C standard was ratified). Perusing
> that document from time to time, and occasionally going back and
> forth between that and the first ISO C document, I happened to
> see passages in places that were different between the ANSI
> document and the ISO document. Indeed most of the text in the
> two documents is word-for-word identical, which made the few
> instances where there were discrepancies stand out rather
> vividly. Unfortunately I remember the fact of there being
> differences but not where they are specifically. But I am quite
> sure that I observed some differences in the wordings of the two
> documents.
Assuming you have the same ansi.c.txt that I have, I believe it's a
pre-release draft of the 1989 ANSI C standard. The first paragraph is:
(This foreword is not a part of American National Standard for
Information Systems --- Programming Language C, X3.???-1988.)
The "???" and the 1988 date suggest to me that it had not yet been
finalized.
My original source for the file was
http://flash-gordon.me.uk/ansi.c.txt
but it's no longer there -- but a Google search indicates that
there are copies elsewhere.
I speculate that that explains any differences between ansi.c.txt and
the ISO C90 standard.
If you can find any specific differences, and if someone out there has a
copy of the published 1989 ANSI C standard (I don't), perhaps we can
clear this up.
I have a copy of Schildt's very bad book "The Annotated ANSI C
Standard", which has the text of the standard on every other page, but I
think it actually uses the 1990 ISO C standard, so it would not be
useful for this exercise -- and I can't find my copy anyway.
Background: https://www.lysator.liu.se/c/schildt.html
--
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-24 11:26 +0100 |
| Message-ID | <tlngsc$8ooq$1@solani.org> |
| In reply to | #168295 |
Am 19.11.22 um 22:27 schrieb Keith Thompson: > > I have a copy of Schildt's very bad book "The Annotated ANSI C > Standard", which has the text of the standard on every other page, but I > think it actually uses the 1990 ISO C standard, so it would not be > useful for this exercise -- and I can't find my copy anyway. > Background: https://www.lysator.liu.se/c/schildt.html > In case someone is looking for that style of book, "The New C Standard" by Derek M. Jones is a better alternative (it is about C99, though so not that relevant to the OP here). It also has much higher annotation to standard text ratio. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-12-04 06:29 -0800 |
| Message-ID | <86bkoj5jjg.fsf@linuxsc.com> |
| In reply to | #168295 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Richard Damon <Richard@Damon-Family.org> writes: >> >>> On 11/19/22 9:42 AM, Tim Rentsch wrote: >>> >>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >>>> >>>>> C89 was a US standard. It got taken over by ISO, which released >>>>> almost exactly the same text as C90. They added 3 sections at the >>>>> beginning of the standard to meet ISO requirements, which resulted >>>>> in every section number after that being increased by 3 (which >>>>> means every single cross-reference had to be updated, too), but it >>>>> was otherwise almost identical. [...] >>>> >>>> For the most part the ISO (C90) standard uses exactly the same >>>> wording that was used in the ANSI (C89) standard (ignoring >>>> differences in numbering, like you say). In places though there >>>> are some non-trivial changes. >>> >>> My understanding was that, execpt for the early "boiler-plate" section >>> added near the beginning which causes the numbering difference, the >>> rest of the content was adopted verbatim. >> >> My observation is this. I have a copy of ansi.c.txt, which is >> supposed to be a text-based copy of the ANSI C standard (and >> presumably after the ANSI C standard was ratified). Perusing >> that document from time to time, and occasionally going back and >> forth between that and the first ISO C document, I happened to >> see passages in places that were different between the ANSI >> document and the ISO document. Indeed most of the text in the >> two documents is word-for-word identical, which made the few >> instances where there were discrepancies stand out rather >> vividly. Unfortunately I remember the fact of there being >> differences but not where they are specifically. But I am quite >> sure that I observed some differences in the wordings of the two >> documents. > > Assuming you have the same ansi.c.txt that I have, I believe it's > a pre-release draft of the 1989 ANSI C standard. The first > paragraph is: > > (This foreword is not a part of American National Standard for > Information Systems --- Programming Language C, X3.???-1988.) > > The "???" and the 1988 date suggest to me that it had not yet been > finalized. > > My original source for the file was > http://flash-gordon.me.uk/ansi.c.txt > but it's no longer there -- but a Google search indicates that > there are copies elsewhere. > > I speculate that that explains any differences between ansi.c.txt > and the ISO C90 standard. > > If you can find any specific differences, and if someone out there > has a copy of the published 1989 ANSI C standard (I don't), > perhaps we can clear this up. As long as people generally use ansi.c.txt as a stand-in for the ANSI C (aka C89) standard, and as long as people generally do not reference the actual ANSI C document (and TTBOMK both of these conditions are true), I don't think it makes much difference whether any changes occurred between ansi.c.txt and C89 or between C89 and the first ISO C standard (aka C90). Either way, it's a mistake to think that citations from "C89" (meaning from the ansi.c.txt document) are always exactly faithful to C90. As a point of historical interest, it would be interesting to know which of the two steps had textual changes, and for that matter whether there may be changes in both steps. Since I don't have any way of investigating that question (I don't have a copy of the official ANSI C standard either), I offer no opinion as to what might be the case. As a rule I don't like to reach even speculative conclusions without some sort of hard evidence. I do recognize the possibility that changes between ansi.c.txt and the official ANSI C document may account for all of the discrepancies between "C89" and C90, and that the ANSI C standard might be essentially identical to the ISO C standard (taking into account section re-numbering, etc). In the future I will try to remember to put in a note saying that comments made by me about "C89" are based on ansi.c.txt rather than the official ANSI C document (of course, unless and until that changes).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-21 11:31 +0100 |
| Message-ID | <tlfk2g$3pku6$1@dont-email.me> |
| In reply to | #168258 |
On 18/11/2022 13:56, A wrote: > On Friday, 18 November 2022 at 17:32:09 UTC+5:30, David Brown wrote: >> On 18/11/2022 10:46, A wrote: >>> >>> 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. >>> >> So when you wrote "C standard library came with C89 in 1989", you meant >> to write "glibc was released in 1991" ? It is /really/ difficult to >> figure out what you are trying to say here. >> > > My assumption was that glibc original authors would have been part of C89 standardization committee. > That is a very odd assumption. glibc was quite young at that time, and neither glibc, nor gcc, nor their umbrella organisation the FSF, were one of the "big players" at the time. I don't know what time size_t and malloc became de facto standard in C prior to the first ANSI standard, but I think it would have been long before glibc was started. (I presume it was before the first edition of The C Programming Language in 1978.) So even if the glibc authors had been involved in the C89 standardisation committee, the use of "size_t" in malloc() would have preceded that standardisation by a decade at least. You do know that glibc is only one of perhaps (my estimates) several thousand standard C library implementations over the decades, as well as several thousand C compilers for various targets?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-21 08:51 -0800 |
| Message-ID | <87a64kl095.fsf@nosuchdomain.example.com> |
| In reply to | #168321 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> I don't know what time size_t and malloc became de facto standard in C
> prior to the first ANSI standard, but I think it would have been long
> before glibc was started. (I presume it was before the first edition
> of The C Programming Language in 1978.)
K&R1 doesn't mention size_t or malloc.
It does have a sample implementation of a memory allocator called
"alloc" (presented as an example, not as part of the standard library).
It returns an unsigned result; unsigned long didn't exist yet.
It does mention calloc() as part of the standard library.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-11-21 15:11 -0500 |
| Message-ID | <tlgm25$3s65k$1@dont-email.me> |
| In reply to | #168321 |
On 11/21/22 05:31, David Brown wrote: ... > I don't know what time size_t and malloc became de facto standard in C > prior to the first ANSI standard, but I think it would have been long > before glibc was started. (I presume it was before the first edition of > The C Programming Language in 1978.) There is no mention of malloc() in that edition. As an example of how to use C, it describes two functions named alloc() and free(). alloc() calls morecore() to allocate a new block of memory, which in turn calls the UNIX system routine sbrk(). It also describes talloc(), a function that calls alloc(). In one example a value of type int was passed to alloc(), in another it passed the result of a sizeof expression. The type returned by sizeof expressions is described only as an integer type, and a sizeof expression is said to be "is semantically an integer constant.". It describes a standard library function named calloc(), but fails to say whether it takes a signed or unsigned argument. Neither size_t nor function prototypes were part of C yet at that time.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-18 07:33 -0500 |
| Message-ID | <7YKdL.3172$BIx.131@fx14.iad> |
| In reply to | #168250 |
On 11/18/22 4:46 AM, A wrote: > > 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 And the glibc library was supposed to be an implementation of the C Standard Library, so the function signatures were definied by the C Standard. To deviate would have been an error.
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-18 04:55 -0800 |
| Message-ID | <48f199c0-16a0-4992-864e-1c7d4c4b7dcen@googlegroups.com> |
| In reply to | #168255 |
On Friday, 18 November 2022 at 18:03:20 UTC+5:30, Richard Damon wrote: > On 11/18/22 4:46 AM, A wrote: > > > > 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 > And the glibc library was supposed to be an implementation of the C > Standard Library, so the function signatures were definied by the C > Standard. > > To deviate would have been an error. My assumption was that glibc original authors would have been part of C89 standardization committee. Amit
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2022-11-18 11:01 +0100 |
| Message-ID | <tl7l6g$3r3$1@news.gegeweb.eu> |
| In reply to | #168247 |
On 11/18/22 10:19, David Brown wrote:
>
> So for most people, "int" on 80386 and 8046 was 16-bit.
I remember, back in the 80's, working on a DOS software
with the Lattice C compiler, where int was 32 bits.
Don't remeber if it was the default or an option, but
very nice when your soft has to be run on PC-Dos and
Atari ST :)
tTh
--
+------------------------------------------------------------------+
| https://danstonchat.com/1138.html |
+------------------------------------------------------------------+
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2022-11-23 09:23 +0100 |
| Message-ID | <tlklau$7e46$2@solani.org> |
| In reply to | #168207 |
Am 17.11.22 um 11:43 schrieb A: >> >> - 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. The future ISO C23 standard will change the minimum size of ptrdiff_t from 17 to 16 bits to better support 16- and 8-bit systems. Philipp
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web