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 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-11-24 20:09 +0000 |
| Message-ID | <20221124120723.91@kylheku.com> |
| In reply to | #168337 |
On 2022-11-23, Philipp Klaus Krause <pkk@spth.de> wrote: > 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. That's unproductive you can't "support" anything by flipping a digit in the new revision of a document. It has no meaning. It makes no difference as to what kinds of programs actually work or don't work on those systems. If some implementation can't make a 17 bit ptrdiff_t, it just won't conform in that regard, just the empty word semantics of what we call "conforming" or not. -- 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-25 08:29 +0100 |
| Message-ID | <tlpqsb$tkvg$1@dont-email.me> |
| In reply to | #168343 |
On 24/11/2022 21:09, Kaz Kylheku wrote: > On 2022-11-23, Philipp Klaus Krause <pkk@spth.de> wrote: >> 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. > > That's unproductive you can't "support" anything by flipping a digit in > the new revision of a document. It has no meaning. > > It makes no difference as to what kinds of programs actually work or > don't work on those systems. > > If some implementation can't make a 17 bit ptrdiff_t, it just won't > conform in that regard, just the empty word semantics of what we > call "conforming" or not. > The change is an acknowledgement that 16-bit and 8-bit systems are important to the C world, and that it is a good thing for compilers for such systems to aim for conformance rather than being content with lots of non-conformancies. A compiler for a 16-bit device can usually get quite close to conformance.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-17 11:16 +0100 |
| Message-ID | <tl51li$2kkvl$1@dont-email.me> |
| In reply to | #168196 |
On 17/11/2022 07:20, Amit wrote: > Hi, > > I prefer long over size_t. > > This is because, in case the user passes a negative number by mistake > then I will be able to check it if the type is long and return > immediately. > > But if size_t is used, then most probably, it will result in a crash > - like malloc(-1) will crash the program because unsigned -1 is > 0xFFFFFFFF and this much memory is not available on today's computers > and probably may not be available at all in future also (RAM size of > 2^64 bits is really really huge). You are mixing 64-bit and 32-bit here. Do you mean 0xffff'ffff'ffff'ffff ? After all, 0xffff'ffff is just shy of 4 GB, which is not excessive on modern computers. And do you mean "long long", rather than "size_t" ? On some platforms "long" is 32-bit and "size_t" is 64-bit. On some, "long" is 64-bit. On others, "long is 32-bit" and "size_t" is 16-bit. > > Another thing is that if size_t is used an array index then array[-1] > will result in wrong behavior or program crash. But with long, the > developer can check whether the index is negative, thus avoiding > program crash. > > So, in my opinion, long should be used instead of size_t. > > I know that original glibc authors had chosen size_t, so there must > be some reason for that, however that reason is not clear to me. > > Amit This all seems a pretty drastic decision based solely on spotting a very specific type of error that is unlikely to happen in practice, and which will immediately be found in testing. Why just check for negative values? What happens if the caller passes 0x0bad0bad0bad0bad as the size? It is perfectly good value in a 64-bit "long", yet just as unrealistic for a memory size as -1. You are drawing arbitrary lines that I don't think help anyone.
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-17 02:48 -0800 |
| Message-ID | <16817b9c-44af-4e97-8362-ac744b34750fn@googlegroups.com> |
| In reply to | #168205 |
> This all seems a pretty drastic decision based solely on spotting a very > specific type of error that is unlikely to happen in practice, and which > will immediately be found in testing. > Why just check for negative values? What happens if the caller passes > 0x0bad0bad0bad0bad as the size? It is perfectly good value in a 64-bit > "long", yet just as unrealistic for a memory size as -1. You are > drawing arbitrary lines that I don't think help anyone. Let's say that you have to design an allocate_memory() function. Would you choose a size_t argument over long and WHY? Amit
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-11-17 11:30 +0000 |
| Message-ID | <tl5601$1vj7$1@gioia.aioe.org> |
| In reply to | #168208 |
On 17/11/2022 10:48, A wrote: > >> This all seems a pretty drastic decision based solely on spotting a very >> specific type of error that is unlikely to happen in practice, and which >> will immediately be found in testing. > >> Why just check for negative values? What happens if the caller passes >> 0x0bad0bad0bad0bad as the size? It is perfectly good value in a 64-bit >> "long", yet just as unrealistic for a memory size as -1. You are >> drawing arbitrary lines that I don't think help anyone. > > Let's say that you have to design an allocate_memory() function. Would you choose a size_t argument over long and WHY? I'd assume a 64-bit target and use u64 or the C equivalent. I really wouldn't bother with 'long' at all, which on Windows 64 is 32 bits anyway.
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-17 03:52 -0800 |
| Message-ID | <40407184-249b-46e3-a362-ed809d9f6c84n@googlegroups.com> |
| In reply to | #168209 |
On Thursday, 17 November 2022 at 17:00:22 UTC+5:30, Bart wrote: > On 17/11/2022 10:48, A wrote: > > > >> This all seems a pretty drastic decision based solely on spotting a very > >> specific type of error that is unlikely to happen in practice, and which > >> will immediately be found in testing. > > > >> Why just check for negative values? What happens if the caller passes > >> 0x0bad0bad0bad0bad as the size? It is perfectly good value in a 64-bit > >> "long", yet just as unrealistic for a memory size as -1. You are > >> drawing arbitrary lines that I don't think help anyone. > > > > Let's say that you have to design an allocate_memory() function. Would you choose a size_t argument over long and WHY? > I'd assume a 64-bit target and use u64 or the C equivalent. > > I really wouldn't bother with 'long' at all, which on Windows 64 is 32 > bits anyway. So, the reason for not using long is that it is 32 bits on Windows 64. Lets assume that long is 64 bits on Windows. Then would you use long? If not WHY? No one is actually giving any compelling reason(s) for using size_t over long in malloc(). Amit
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-11-17 12:27 +0000 |
| Message-ID | <tl59bs$1lb4$1@gioia.aioe.org> |
| In reply to | #168210 |
On 17/11/2022 11:52, A wrote: > On Thursday, 17 November 2022 at 17:00:22 UTC+5:30, Bart wrote: >> On 17/11/2022 10:48, A wrote: >>> >>>> This all seems a pretty drastic decision based solely on spotting a very >>>> specific type of error that is unlikely to happen in practice, and which >>>> will immediately be found in testing. >>> >>>> Why just check for negative values? What happens if the caller passes >>>> 0x0bad0bad0bad0bad as the size? It is perfectly good value in a 64-bit >>>> "long", yet just as unrealistic for a memory size as -1. You are >>>> drawing arbitrary lines that I don't think help anyone. >>> >>> Let's say that you have to design an allocate_memory() function. Would you choose a size_t argument over long and WHY? >> I'd assume a 64-bit target and use u64 or the C equivalent. >> >> I really wouldn't bother with 'long' at all, which on Windows 64 is 32 >> bits anyway. > > So, the reason for not using long is that it is 32 bits on Windows 64. Lets assume that long is 64 bits on Windows. Then would you use long? If not WHY? > > No one is actually giving any compelling reason(s) for using size_t over long in malloc(). Because malloc takes a size_t parameter?
[toc] | [prev] | [next] | [standalone]
| From | Mark Bluemel <mark.bluemel@gmail.com> |
|---|---|
| Date | 2022-11-17 04:28 -0800 |
| Message-ID | <91e1ad2e-6d07-443c-aca3-0736e4d97a16n@googlegroups.com> |
| In reply to | #168210 |
On Thursday, 17 November 2022 at 11:52:13 UTC, A wrote: > No one is actually giving any compelling reason(s) for using size_t over long in malloc(). Your definition of compelling seems very personal, and can largely be ignored, I feel. I'm not sure that I'm going to worry too much about the views of someone who can't recognise the distinction between a standard (the C library definition) and an implementation (glibc). The most compelling reason for malloc to take a size_t argument is that that is what the standard mandates. It's a little late to try and debate the decision.
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-17 04:34 -0800 |
| Message-ID | <dd4a400b-e181-43c6-9eaa-b326bbd14218n@googlegroups.com> |
| In reply to | #168212 |
On Thursday, 17 November 2022 at 17:58:42 UTC+5:30, Mark Bluemel wrote: > On Thursday, 17 November 2022 at 11:52:13 UTC, A wrote: > I'm not sure that I'm going to worry too much about the views of someone who can't recognise the distinction between a standard (the C library definition) and an implementation (glibc). How did you came to the conclusion that I can't recognize the distinction between a standard (the C library definition) and an implementation (glibc)? Please explain. Amit
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-11-17 15:48 +0000 |
| Message-ID | <20221117074728.905@kylheku.com> |
| In reply to | #168214 |
On 2022-11-17, A <amit234234234234@gmail.com> wrote: > On Thursday, 17 November 2022 at 17:58:42 UTC+5:30, Mark Bluemel wrote: >> On Thursday, 17 November 2022 at 11:52:13 UTC, A wrote: > >> I'm not sure that I'm going to worry too much about the views of someone who can't recognise the distinction between a standard (the C library definition) and an implementation (glibc). > > How did you came to the conclusion that I can't recognize the > distinction between a standard (the C library definition) and an > implementation (glibc)? Because earlier you were writing nonsense about how the glibc authors chose the size_t parameter for malloc, and why did they do so. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Amit <amitchoudhary0523@gmail.com> |
|---|---|
| Date | 2022-11-17 22:36 -0800 |
| Message-ID | <7586d7f7-498a-42f7-9a17-afc26d7c6fe7n@googlegroups.com> |
| In reply to | #168229 |
On Thursday, November 17, 2022 at 9:19:07 PM UTC+5:30, Kaz Kylheku wrote: > On 2022-11-17, A <amit2342...@gmail.com> wrote: > > > > How did you came to the conclusion that I can't recognize the > > distinction between a standard (the C library definition) and an > > implementation (glibc)? >> > Because earlier you were writing nonsense about how the glibc authors > chose the size_t parameter for malloc, and why did they do so. Kaz, You are a stupid person. Amit
[toc] | [prev] | [next] | [standalone]
| From | A <amit234234234234@gmail.com> |
|---|---|
| Date | 2022-11-17 04:28 -0800 |
| Message-ID | <d5f64cd1-353c-4a8c-91f1-83c8a07e5e48n@googlegroups.com> |
| In reply to | #168210 |
On Thursday, 17 November 2022 at 17:22:13 UTC+5:30, A wrote:
> On Thursday, 17 November 2022 at 17:00:22 UTC+5:30, Bart wrote:
> > On 17/11/2022 10:48, A wrote:
> > >
> > >> This all seems a pretty drastic decision based solely on spotting a very
> > >> specific type of error that is unlikely to happen in practice, and which
> > >> will immediately be found in testing.
> > >
> > >> Why just check for negative values? What happens if the caller passes
> > >> 0x0bad0bad0bad0bad as the size? It is perfectly good value in a 64-bit
> > >> "long", yet just as unrealistic for a memory size as -1. You are
> > >> drawing arbitrary lines that I don't think help anyone.
> > >
> > > Let's say that you have to design an allocate_memory() function. Would you choose a size_t argument over long and WHY?
> > I'd assume a 64-bit target and use u64 or the C equivalent.
> >
> > I really wouldn't bother with 'long' at all, which on Windows 64 is 32
> > bits anyway.
> So, the reason for not using long is that it is 32 bits on Windows 64. Lets assume that long is 64 bits on Windows. Then would you use long? If not WHY?
>
> No one is actually giving any compelling reason(s) for using size_t over long in malloc().
>
> Amit
Let me ask a similar question.
Please see the function below:
void *allocate_memory(long size)
{
if (size < 0) {
errno = -ENEGATIVESIZE;
return NULL;
}
return (malloc((size_t)(size)));
}
Would you ask the developer to use size_t instead of long and WHY?
Amit
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-11-17 12:46 +0000 |
| Message-ID | <tl5af5$56s$1@gioia.aioe.org> |
| In reply to | #168213 |
On 17/11/2022 12:28, A wrote:
> On Thursday, 17 November 2022 at 17:22:13 UTC+5:30, A wrote:
>> On Thursday, 17 November 2022 at 17:00:22 UTC+5:30, Bart wrote:
>>> On 17/11/2022 10:48, A wrote:
>>>>
>>>>> This all seems a pretty drastic decision based solely on spotting a very
>>>>> specific type of error that is unlikely to happen in practice, and which
>>>>> will immediately be found in testing.
>>>>
>>>>> Why just check for negative values? What happens if the caller passes
>>>>> 0x0bad0bad0bad0bad as the size? It is perfectly good value in a 64-bit
>>>>> "long", yet just as unrealistic for a memory size as -1. You are
>>>>> drawing arbitrary lines that I don't think help anyone.
>>>>
>>>> Let's say that you have to design an allocate_memory() function. Would you choose a size_t argument over long and WHY?
>>> I'd assume a 64-bit target and use u64 or the C equivalent.
>>>
>>> I really wouldn't bother with 'long' at all, which on Windows 64 is 32
>>> bits anyway.
>> So, the reason for not using long is that it is 32 bits on Windows 64. Lets assume that long is 64 bits on Windows. Then would you use long? If not WHY?
>>
>> No one is actually giving any compelling reason(s) for using size_t over long in malloc().
>>
>> Amit
>
> Let me ask a similar question.
>
> Please see the function below:
>
> void *allocate_memory(long size)
> {
> if (size < 0) {
Why is the parameter signed?
> errno = -ENEGATIVESIZE;
> return NULL;
> }
> return (malloc((size_t)(size)));
> }
>
> Would you ask the developer to use size_t instead of long and WHY?
As I said, on Windows 'long' is always 32 bits. You can't change that,
so it would be silly to use what will be an i32 type on a 64-bit machine.
AIUI, 'size_t' is usually defined as either u32 or u64 depending on
whether the platform is 32 or 64 bits. So it's a conditional type.
I personally don't care about 32-bit systems, and for such a function,
I'd use u64, or even i64, but then you might need that check.
However, I think it's pointless to check for a size of -1, but not for
one of 2**52 for example. Passing -1 (0xFFFFFFFFFFFFFFFF interpreted as
unsigned) to malloc will make it fail too.
[toc] | [prev] | [next] | [standalone]
| From | Paul N <gw7rib@aol.com> |
|---|---|
| Date | 2022-11-17 05:24 -0800 |
| Message-ID | <b752826c-2111-4891-b98a-0ced266a8ae0n@googlegroups.com> |
| In reply to | #168213 |
On Thursday, November 17, 2022 at 12:29:04 PM UTC, A wrote:
> Please see the function below:
>
> void *allocate_memory(long size)
> {
> if (size < 0) {
> errno = -ENEGATIVESIZE;
> return NULL;
> }
> return (malloc((size_t)(size)));
> }
If you really want to do this test, you could always do:
void *allocate_memory(size_t size)
{
if ((long)size < 0) {
errno = -ENEGATIVESIZE;
return NULL;
}
return (malloc(size));
}
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-11-17 16:20 +0000 |
| Message-ID | <87cz9ltuwj.fsf@bsb.me.uk> |
| In reply to | #168223 |
Paul N <gw7rib@aol.com> writes:
> On Thursday, November 17, 2022 at 12:29:04 PM UTC, A wrote:
>> Please see the function below:
>>
>> void *allocate_memory(long size)
>> {
>> if (size < 0) {
>> errno = -ENEGATIVESIZE;
>> return NULL;
>> }
>> return (malloc((size_t)(size)));
>> }
>
> If you really want to do this test, you could always do:
>
> void *allocate_memory(size_t size)
> {
> if ((long)size < 0) {
> errno = -ENEGATIVESIZE;
> return NULL;
This won't work if long is wider than size (as is permitted).
> }
> return (malloc(size));
> }
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2022-11-17 15:55 +0000 |
| Message-ID | <20221117074914.392@kylheku.com> |
| In reply to | #168213 |
On 2022-11-17, A <amit234234234234@gmail.com> wrote:
> Let me ask a similar question.
>
> Please see the function below:
>
> void *allocate_memory(long size)
> {
> if (size < 0) {
> errno = -ENEGATIVESIZE;
errno values aren't negated; might you have been studying Linux kernel
code recently?
The existing ERANGE value might be suitable here.
> return NULL;
> }
> return (malloc((size_t)(size)));
> }
>
> Would you ask the developer to use size_t instead of long and WHY?
It depends on the expected uses and portability requirements
for the code.
If the code had to be portable to 32 bit systems, and it was expected
that the allocator would have to handle huge objects, I would flag it
as a problem. With a 32 bit long, you cannot express an allocation
larger than 2Gb, whereas a 32 bit size_t will let you do that.
A possible portability concern would be 64 bit targets that have not
chosen 64 bits for the long type.
Note also that the "sizeof" operator in C yields a value of type size_t.
So when we write malloc(sizeof (some_type)), the sizeof expressino
is yielding exactly the type which malloc expects. That's a powerful
argument to me. While you may get to define your own allocation
function, you don't get to redefine how sizeof works.
--
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:43 -0500 |
| Message-ID | <tl9tu0$367b8$4@dont-email.me> |
| In reply to | #168230 |
On 11/17/22 10:55, Kaz Kylheku wrote:
> On 2022-11-17, A <amit234234234234@gmail.com> wrote:
>> Let me ask a similar question.
>>
>> Please see the function below:
>>
>> void *allocate_memory(long size)
>> {
>> if (size < 0) {
>> errno = -ENEGATIVESIZE;
>
> errno values aren't negated; might you have been studying Linux kernel
> code recently?
Standard library routines are required to set errno to positive values,
specifically to allow users to use negative values for their own
purposes. allocate_memory() is not supposed to be a standard library
function, and therefore can use a negative value.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-19 12:47 -0800 |
| Message-ID | <87edtyn038.fsf@nosuchdomain.example.com> |
| In reply to | #168272 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 11/17/22 10:55, Kaz Kylheku wrote:
>> On 2022-11-17, A <amit234234234234@gmail.com> wrote:
>>> Let me ask a similar question.
>>>
>>> Please see the function below:
>>>
>>> void *allocate_memory(long size)
>>> {
>>> if (size < 0) {
>>> errno = -ENEGATIVESIZE;
>>
>> errno values aren't negated; might you have been studying Linux kernel
>> code recently?
>
> Standard library routines are required to set errno to positive values,
> specifically to allow users to use negative values for their own
> purposes. allocate_memory() is not supposed to be a standard library
> function, and therefore can use a negative value.
I don't think that's correct. The standard requires the values of EDOM,
EILSEQ, and ERANGE to be positive, but makes no such guarantee about any
implementation-defined E* macros, or about values that errno might be
set to by library function calls.
There is a convention for Linux kernel functions that implement system
calls to return negative values corresponding to E* macros, for example
`return -ENOENT;`; the wrapper typically sets errno to the corresponding
positive value and returns -1 to denote failure.
Somebody may have intended to reserve negative error values for user
code (though I've never heard of it), but that intent is not expressed
in the standard.
--
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-20 01:33 -0500 |
| Message-ID | <tlchn0$3f4tk$2@dont-email.me> |
| In reply to | #168291 |
On 11/19/22 15:47, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: ... >> Standard library routines are required to set errno to positive values, >> specifically to allow users to use negative values for their own >> purposes. allocate_memory() is not supposed to be a standard library >> function, and therefore can use a negative value. > > I don't think that's correct. The standard requires the values of EDOM, > EILSEQ, and ERANGE to be positive, but makes no such guarantee about any > implementation-defined E* macros, or about values that errno might be > set to by library function calls. The description of errno in 7.5p2 says "... the value of which is set to a positive error number by several library functions."
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-19 22:38 -0800 |
| Message-ID | <87mt8mku5m.fsf@nosuchdomain.example.com> |
| In reply to | #168302 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 11/19/22 15:47, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> ...
>>> Standard library routines are required to set errno to positive values,
>>> specifically to allow users to use negative values for their own
>>> purposes. allocate_memory() is not supposed to be a standard library
>>> function, and therefore can use a negative value.
>>
>> I don't think that's correct. The standard requires the values of EDOM,
>> EILSEQ, and ERANGE to be positive, but makes no such guarantee about any
>> implementation-defined E* macros, or about values that errno might be
>> set to by library function calls.
>
> The description of errno in 7.5p2 says "... the value of which is set to
> a positive error number by several library functions."
You're right, I missed that -- but p3 says "The value of errno may be
set to nonzero by a library function call whether or not there is an
error, provided the use of errno is not documented in the description of
the function in this International Standard."
And I'm sure the intent is that the "additional macro definitions"
beginning with E are supposed to expand to positive constant expressions
of type int, but the standard doesn't say so. (It would IMHO be nice if
it did.)
--
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]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web