Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #400968 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2026-08-11 03:01 -0500 |
| Last post | 2026-08-24 19:09 -0500 |
| Articles | 20 on this page of 208 — 17 participants |
Back to article view | Back to comp.lang.c
why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 03:01 -0500
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 13:11 +0200
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 12:45 +0100
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 14:34 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 14:55 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 15:19 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 15:27 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 16:08 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 16:18 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:11 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:20 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:32 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:39 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 18:33 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 18:39 +0200
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-11 23:31 +0300
Re: why is there not a ipow version of pow? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-08-11 11:46 -0400
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 18:35 +0200
Re: why is there not a ipow version of pow? antispam@fricas.org (Waldek Hebisch) - 2026-08-11 22:53 +0000
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-12 10:08 +0200
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-12 03:58 -0700
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-12 13:31 +0200
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-12 22:43 +0300
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-12 13:44 -0700
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-13 00:24 +0300
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-12 16:49 -0500
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-13 08:38 +0200
Re: Calculation of sine with tables (was Re: why is there not a ipow version of pow?) scott@slp53.sl.home (Scott Lurndal) - 2026-08-13 14:36 +0000
Re: Calculation of sine with tables (was Re: why is there not a ipow version of pow?) David Brown <david.brown@hesbynett.no> - 2026-08-13 17:07 +0200
Re: Calculation of sine with tables (was Re: why is there not a ipow version of pow?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-13 19:07 +0200
Re: Calculation of sine with tables (was Re: why is there not a ipow version of pow?) David Brown <david.brown@hesbynett.no> - 2026-08-13 22:24 +0200
Re: Calculation of sine with tables (was Re: why is there not a ipow version of pow?) Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-08-13 16:36 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-13 18:59 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-13 18:51 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 00:58 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:08 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 15:48 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 13:51 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 16:40 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 19:24 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 22:51 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 22:33 -0700
Re: why is there not a ipow version of pow? Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-08-15 10:40 -0700
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-15 11:41 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-17 14:48 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-16 14:58 -0700
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-14 08:57 +0200
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:46 -0700
Calculation of sine with tables (was Re: why is there not a ipow version of pow?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-13 14:45 +0200
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 13:00 -0700
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-15 23:17 +0300
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-17 10:07 -0700
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-18 00:35 +0300
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-18 11:22 +0200
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-18 22:22 +0300
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-18 21:59 +0200
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-18 08:38 -0700
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-18 22:17 +0300
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-18 15:42 -0700
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-18 17:44 -0700
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-19 21:55 +0300
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-19 18:25 -0700
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-20 22:03 +0300
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-21 07:31 -0700
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 04:53 +0800
Re: why is there not a ipow version of pow? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-08-13 12:59 -0400
Re: why is there not a ipow version of pow? antispam@fricas.org (Waldek Hebisch) - 2026-08-12 20:23 +0000
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-11 18:19 +0000
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 20:21 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-11 21:10 +0000
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-12 00:42 +0300
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 06:41 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-12 14:19 +0000
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 16:56 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-12 15:32 +0000
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-12 22:05 +0300
Re: why is there not a ipow version of pow? Paul <nospam@needed.invalid> - 2026-08-12 19:09 -0400
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-11 21:58 +0300
Re: why is there not a ipow version of pow? Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-08-11 21:44 -0700
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 15:45 +0100
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 16:56 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:23 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:24 +0200
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 16:23 +0100
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:26 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:54 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 18:40 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 08:49 +0200
Re: why is there not a ipow version of pow? Paul <nospam@needed.invalid> - 2026-08-12 09:11 -0400
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 16:05 +0200
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-12 12:40 -0700
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-13 15:46 +0200
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-13 14:28 -0700
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-11 16:20 -0700
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 18:43 +0100
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 19:56 +0200
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 20:41 +0100
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 06:42 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-12 10:23 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 20:24 +0200
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 20:27 +0100
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 06:45 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:16 +0200
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-16 07:33 -0700
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-16 17:12 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-16 17:51 +0200
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-16 18:35 +0200
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-16 18:41 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-16 21:30 +0200
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-16 23:41 +0100
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-17 08:56 +0200
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-17 03:32 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-17 08:59 +0200
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-17 11:08 +0200
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-17 03:48 -0700
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-17 04:25 -0700
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-17 13:44 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-17 14:26 +0000
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-17 16:58 +0200
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-17 16:49 -0700
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-23 09:14 -0700
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-26 02:27 +0200
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-25 17:56 -0700
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-26 03:56 +0200
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-25 19:57 -0700
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-26 05:33 +0200
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-25 22:52 -0700
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-26 09:48 +0200
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-26 20:29 +0200
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-26 03:29 -0700
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-26 15:40 +0000
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-23 06:50 -0700
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-17 10:22 -0700
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-17 19:49 +0200
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-17 20:00 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-17 20:37 +0200
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-26 02:48 +0200
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-18 18:18 -0700
Re: why is there not a ipow version of pow? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:26 +0000
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 15:17 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 15:28 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 16:43 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 16:47 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:24 +0200
Re: why is there not a ipow version of pow? Paul <nospam@needed.invalid> - 2026-08-11 09:36 -0400
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 16:42 -0500
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-11 19:15 +0200
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 16:41 -0500
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 16:49 -0500
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 23:28 +0100
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 17:51 -0500
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-11 15:33 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 17:49 -0500
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-11 16:19 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-12 00:32 -0500
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 14:08 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 18:40 +0200
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-14 02:50 +0000
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-12 04:26 +0000
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-12 01:37 -0500
Re: why is there not a ipow version of pow? Paul <nospam@needed.invalid> - 2026-08-13 00:12 -0400
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-14 11:22 +0800
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 01:00 -0500
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-14 14:47 +0800
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 13:54 -0500
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-16 22:49 +0000
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-17 14:56 -0500
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-17 23:53 +0000
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-17 19:59 -0500
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-18 02:47 +0000
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-17 15:17 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:03 -0700
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 03:51 +0800
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:52 -0700
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 04:01 +0800
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 13:27 -0700
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 13:29 -0700
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 04:49 +0800
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 20:32 -0700
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-12 11:28 +0100
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-12 23:52 +0000
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-13 01:30 +0100
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-13 02:24 +0000
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-12 21:13 -0700
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-13 14:33 +0000
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-13 16:45 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-13 14:55 +0000
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-13 18:10 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-13 16:16 +0000
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-13 16:21 +0000
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-17 06:37 +0000
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-17 21:37 +0800
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-13 17:19 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-13 16:09 +0000
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-13 18:52 +0200
Re: why is there not a ipow version of pow? antispam@fricas.org (Waldek Hebisch) - 2026-08-18 16:33 +0000
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-13 17:19 +0800
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-13 19:07 -0500
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-14 10:58 +0800
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 01:14 -0500
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-17 06:40 +0000
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-17 21:40 +0800
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-18 00:42 -0500
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-18 09:34 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-18 11:32 +0200
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-21 17:22 -0500
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-22 12:30 +0200
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-24 19:09 -0500
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-23 09:14 -0700 |
| Message-ID | <86v790yfu5.fsf@linuxsc.com> |
| In reply to | #401282 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > scott@slp53.sl.home (Scott Lurndal) writes: > >> David Brown <david.brown@hesbynett.no> writes: > > [...] > >>> Some people see that as an advantage - being able to write "unsigned >>> very_big = -1;". I dislike it personally, but styles and preferences >>> vary, and it has portability advantages over, say, 0xffff'ffff. >> >> I also dislike that use of -1. I prefer using ~0ul to get all-ones. > > I'd use ~0ul to get all-ones, -1 or -1u to get the largest value > of the type (or preferably UINT_MAX, but -1 is good if it's not > obvious *which* unsigned type I'm using). The idea that all ones and the largest value should be treated differently seems rather odd. Surely it is immediately obvious that the largest value (of any unsigned type) will have all bits set to one; using -1 will always provide both. > The fact that they happen to be the same value is a technical detail > that I don't necessarily want to worry about. Whether I use ~0ul > or -1 depends on which concept I want to express. This idea seems even odder. Presumably the point of expressing a concept is to convey it to the reader. I think very few readers would understand what distinction is intended by the different writings here. A simpler and more reliable way is just to use a comment size_t k = -1; // largest value size_t mask = -1; // all ones
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-26 02:27 +0200 |
| Message-ID | <116lbu1$32eog$5@dont-email.me> |
| In reply to | #401282 |
On 2026-08-18 01:49, Keith Thompson wrote: > scott@slp53.sl.home (Scott Lurndal) writes: >> David Brown <david.brown@hesbynett.no> writes: > [...] >>> Some people see that as an advantage - being able to write "unsigned >>> very_big = -1;". I dislike it personally, but styles and preferences >>> vary, and it has portability advantages over, say, 0xffff'ffff. >> >> I also dislike that use of -1. I prefer using ~0ul to get all-ones. > > I'd use ~0ul to get all-ones, Exactly. As '~' is the bit-complement operator it's the most obvious, most consistent, and thus to be expected to be understood by most if not all C-programmers. But do we need the type qualification at all? A quick test seems to indicate that '~0' can be used for all integral types. (That's what my compiler says, don't know about the standard.) > -1 or -1u to get the largest value > of the type (or preferably UINT_MAX, but -1 is good if it's not > obvious *which* unsigned type I'm using). Isn't SIZE_MAX supposed to cover that for size_t at least? Are there other unsigned types that lack such a constant? (I haven't checked.) > > The fact that they happen to be the same value is a technical detail > that I don't necessarily want to worry about. Whether I use ~0ul > or -1 depends on which concept I want to express. IMO bit-ops for bits, and predefined constants (if available) for the maxima of amount types. The '-1' I consider a typical C-kluge; in "C" I'm used to it so I've no problems if I see that or to use it in cases I'm not too much concerned about, um.., call it "symbolic exactness". Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-25 17:56 -0700 |
| Message-ID | <116ldkn$8blf$1@kst.eternal-september.org> |
| In reply to | #401489 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-08-18 01:49, Keith Thompson wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>>> Some people see that as an advantage - being able to write "unsigned
>>>> very_big = -1;". I dislike it personally, but styles and preferences
>>>> vary, and it has portability advantages over, say, 0xffff'ffff.
>>>
>>> I also dislike that use of -1. I prefer using ~0ul to get all-ones.
>> I'd use ~0ul to get all-ones,
>
> Exactly. As '~' is the bit-complement operator it's the most obvious,
> most consistent, and thus to be expected to be understood by most if
> not all C-programmers. But do we need the type qualification at all?
> A quick test seems to indicate that '~0' can be used for all integral
> types. (That's what my compiler says, don't know about the standard.)
>
>> -1 or -1u to get the largest value
>> of the type (or preferably UINT_MAX, but -1 is good if it's not
>> obvious *which* unsigned type I'm using).
-1 is an expression of type int. Converting it to an unsigned type
always yields the largest value of that type. Same for -1 of any signed
type.
-1u is of type unsigned int. Converting it to an unsigned type wider
than unsigned int will not give you the largest value of that type.
Using -1u makes sense only if you know you want a value of type unsigned
int.
#include <stdio.h>
int main(void) {
unsigned long long a = -1;
unsigned long long b = -1u;
printf("%llu\n%llu\n", a, b);
}
18446744073709551615
4294967295
(Results may vary.)
> Isn't SIZE_MAX supposed to cover that for size_t at least? Are there
> other unsigned types that lack such a constant? (I haven't checked.)
I don't know of any unsigned types defined in the standard library that
don't have *_MAX macros (I also haven't checked). User-defined unsigned
types likely won't have *_MAX macros. SIZE_MAX didn't exist in C90
(probably not a concern these days).
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-26 03:56 +0200 |
| Message-ID | <116lh3g$32eog$7@dont-email.me> |
| In reply to | #401492 |
On 2026-08-26 02:56, Keith Thompson wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-08-18 01:49, Keith Thompson wrote: >>> scott@slp53.sl.home (Scott Lurndal) writes: >>>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>>>> Some people see that as an advantage - being able to write "unsigned >>>>> very_big = -1;". I dislike it personally, but styles and preferences >>>>> vary, and it has portability advantages over, say, 0xffff'ffff. >>>> >>>> I also dislike that use of -1. I prefer using ~0ul to get all-ones. >>> I'd use ~0ul to get all-ones, >> >> Exactly. As '~' is the bit-complement operator it's the most obvious, >> most consistent, and thus to be expected to be understood by most if >> not all C-programmers. But do we need the type qualification at all? >> A quick test seems to indicate that '~0' can be used for all integral >> types. (That's what my compiler says, don't know about the standard.) >> >>> -1 or -1u to get the largest value >>> of the type (or preferably UINT_MAX, but -1 is good if it's not >>> obvious *which* unsigned type I'm using). > > -1 is an expression of type int. Converting it to an unsigned type > always yields the largest value of that type. Same for -1 of any signed > type. > > -1u is of type unsigned int. Converting it to an unsigned type wider > than unsigned int will not give you the largest value of that type. > Using -1u makes sense only if you know you want a value of type unsigned > int. I'm not sure it was clear that my "But do we need the type qualification at all?" remark was meant for the '~0' context and "all-bits-set case". Mind, you had previously written: "I prefer using ~0ul". - And I was asking whether that would be necessary here, i.e. for the bits-case and unknown sizes of the underlying types. - I'd think that a "generic" '~0' would suffice (and impose the least surprises). (To set _subsets_ of bits to all '1' is a different question.) Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-25 19:57 -0700 |
| Message-ID | <867bldzj0c.fsf@linuxsc.com> |
| In reply to | #401495 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 2026-08-26 02:56, Keith Thompson wrote: > >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> >>> On 2026-08-18 01:49, Keith Thompson wrote: >>> >>>> scott@slp53.sl.home (Scott Lurndal) writes: >>>> >>>>> David Brown <david.brown@hesbynett.no> writes: >>>> >>>> [...] >>>> >>>>>> Some people see that as an advantage - being able to write >>>>>> "unsigned very_big = -1;". I dislike it personally, but styles >>>>>> and preferences vary, and it has portability advantages over, >>>>>> say, 0xffff'ffff. >>>>> >>>>> I also dislike that use of -1. I prefer using ~0ul to get >>>>> all-ones. >>>> >>>> I'd use ~0ul to get all-ones, >>> >>> Exactly. As '~' is the bit-complement operator it's the most >>> obvious, most consistent, and thus to be expected to be understood >>> by most if not all C-programmers. But do we need the type >>> qualification at all? A quick test seems to indicate that '~0' >>> can be used for all integral types. (That's what my compiler >>> says, don't know about the standard.) >>> >>>> -1 or -1u to get the largest value >>>> of the type (or preferably UINT_MAX, but -1 is good if it's not >>>> obvious *which* unsigned type I'm using). >> >> -1 is an expression of type int. Converting it to an unsigned type >> always yields the largest value of that type. Same for -1 of any >> signed type. >> >> -1u is of type unsigned int. Converting it to an unsigned type >> wider than unsigned int will not give you the largest value of that >> type. Using -1u makes sense only if you know you want a value of >> type unsigned int. > > I'm not sure it was clear that my "But do we need the type > qualification at all?" remark was meant for the '~0' context and > "all-bits-set case". > > Mind, you had previously written: "I prefer using ~0ul". - And I > was asking whether that would be necessary here, i.e. for the > bits-case and unknown sizes of the underlying types. - I'd think > that a "generic" '~0' would suffice (and impose the least > surprises). The expression ~0 works for some conforming implementations. The expression -1 works for all conforming implementations. Generally I tend to prefer code that always works over code that only sometimes works.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-26 05:33 +0200 |
| Message-ID | <116lmqi$32eog$8@dont-email.me> |
| In reply to | #401497 |
On 2026-08-26 04:57, Tim Rentsch wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> On 2026-08-26 02:56, Keith Thompson wrote:
>>
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>
>>>> On 2026-08-18 01:49, Keith Thompson wrote:
>>>>
>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> Some people see that as an advantage - being able to write
>>>>>>> "unsigned very_big = -1;". I dislike it personally, but styles
>>>>>>> and preferences vary, and it has portability advantages over,
>>>>>>> say, 0xffff'ffff.
>>>>>>
>>>>>> I also dislike that use of -1. I prefer using ~0ul to get
>>>>>> all-ones.
>>>>>
>>>>> I'd use ~0ul to get all-ones,
>>>>
>>>> Exactly. As '~' is the bit-complement operator it's the most
>>>> obvious, most consistent, and thus to be expected to be understood
>>>> by most if not all C-programmers. But do we need the type
>>>> qualification at all? A quick test seems to indicate that '~0'
>>>> can be used for all integral types. (That's what my compiler
>>>> says, don't know about the standard.)
>>>>
>>>>> -1 or -1u to get the largest value
>>>>> of the type (or preferably UINT_MAX, but -1 is good if it's not
>>>>> obvious *which* unsigned type I'm using).
>>>
>>> -1 is an expression of type int. Converting it to an unsigned type
>>> always yields the largest value of that type. Same for -1 of any
>>> signed type.
>>>
>>> -1u is of type unsigned int. Converting it to an unsigned type
>>> wider than unsigned int will not give you the largest value of that
>>> type. Using -1u makes sense only if you know you want a value of
>>> type unsigned int.
>>
>> I'm not sure it was clear that my "But do we need the type
>> qualification at all?" remark was meant for the '~0' context and
>> "all-bits-set case".
>>
>> Mind, you had previously written: "I prefer using ~0ul". - And I
>> was asking whether that would be necessary here, i.e. for the
>> bits-case and unknown sizes of the underlying types. - I'd think
>> that a "generic" '~0' would suffice (and impose the least
>> surprises).
>
> The expression ~0 works for some conforming implementations.
Not sure I understand your formulation ("some conforming ...").
Are you implying that the following examples are non-portable,
undefined, or depending on the concrete (standard-)conforming
implementation, or something else?
short unsigned int sd = ~0;
unsigned int d = ~0;
long unsigned int ld = ~0;
long long unsigned int lld = ~0;
The comment in my K&R copy sounds as if it should work on any
integral type like that. - Have the C-standards changed that?
Can you provide some evidence or C-standard-quote where that is
documented? - I'm really interested to know.
Janis
> [...]
> Generally I tend to prefer code that always works over code
> that only sometimes works.
I'd say that most people would agree to that triviality.
I think we can spare us such Kindergarten-rhetorics; it neither
supports or affirmates the answer nor provides any evidence for
the expressed statement. - Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-25 22:52 -0700 |
| Message-ID | <86zey9xwbi.fsf@linuxsc.com> |
| In reply to | #401498 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-08-26 04:57, Tim Rentsch wrote:
>
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>>> On 2026-08-26 02:56, Keith Thompson wrote:
>>>
>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>>
>>>>> On 2026-08-18 01:49, Keith Thompson wrote:
>>>>>
>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>
>>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>>> Some people see that as an advantage - being able to write
>>>>>>>> "unsigned very_big = -1;". I dislike it personally, but styles
>>>>>>>> and preferences vary, and it has portability advantages over,
>>>>>>>> say, 0xffff'ffff.
>>>>>>>
>>>>>>> I also dislike that use of -1. I prefer using ~0ul to get
>>>>>>> all-ones.
>>>>>>
>>>>>> I'd use ~0ul to get all-ones,
>>>>>
>>>>> Exactly. As '~' is the bit-complement operator it's the most
>>>>> obvious, most consistent, and thus to be expected to be understood
>>>>> by most if not all C-programmers. But do we need the type
>>>>> qualification at all? A quick test seems to indicate that '~0'
>>>>> can be used for all integral types. (That's what my compiler
>>>>> says, don't know about the standard.)
>>>>>
>>>>>> -1 or -1u to get the largest value
>>>>>> of the type (or preferably UINT_MAX, but -1 is good if it's not
>>>>>> obvious *which* unsigned type I'm using).
>>>>
>>>> -1 is an expression of type int. Converting it to an unsigned type
>>>> always yields the largest value of that type. Same for -1 of any
>>>> signed type.
>>>>
>>>> -1u is of type unsigned int. Converting it to an unsigned type
>>>> wider than unsigned int will not give you the largest value of that
>>>> type. Using -1u makes sense only if you know you want a value of
>>>> type unsigned int.
>>>
>>> I'm not sure it was clear that my "But do we need the type
>>> qualification at all?" remark was meant for the '~0' context and
>>> "all-bits-set case".
>>>
>>> Mind, you had previously written: "I prefer using ~0ul". - And I
>>> was asking whether that would be necessary here, i.e. for the
>>> bits-case and unknown sizes of the underlying types. - I'd think
>>> that a "generic" '~0' would suffice (and impose the least
>>> surprises).
>>
>> The expression ~0 works for some conforming implementations.
>
> Not sure I understand your formulation ("some conforming ...").
>
> Are you implying that the following examples are non-portable,
> undefined, or depending on the concrete (standard-)conforming
> implementation, or something else?
Yes.
> short unsigned int sd = ~0;
> unsigned int d = ~0;
> long unsigned int ld = ~0;
> long long unsigned int lld = ~0;
>
> The comment in my K&R copy sounds as if it should work on any
> integral type like that. - Have the C-standards changed that?
If you mean the original K&R then yes.
> Can you provide some evidence or C-standard-quote where that is
> documented? - I'm really interested to know.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
Section 6.2.6, Representation of types, subsection 6.2.6.2,
Integer types. Give particular attention to paragraphs 2
through 4.
Also section 6.5 paragraph 4. I'm sorry I'm not able to quote
these passages here; some temporary difficulties are preventing
my doing that.
>> [...]
>> Generally I tend to prefer code that always works over code
>> that only sometimes works.
>
> I'd say that most people would agree to that triviality.
>
> I think we can spare us such Kindergarten-rhetorics; it neither
> supports or affirmates the answer nor provides any evidence for
> the expressed statement. - Thanks.
First my comment wasn't meant to be directed at you. I was
just stating a general principle.
Second I could agree that such statements should go without
saying, except that all too often there are examples given that
seem to violate them. Using ~0u or ~0ul are a case in point:
both of these forms are fragile. Yet such constructs or other
fragile patterns are frequently presented as conventional
wisdom.
Third for supporting statements I have given references above.
You should be able to find all the explanation needed in the
referenced passages.
Let me say again that nothing in these last two replies was
meant to be antagonistic. My aim has been simply to provide
factual answers, along with a general statement meant to explain
why one might want to prefer -1 over some of the suggested
alternatives.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-26 09:48 +0200 |
| Message-ID | <116m5oq$e2ct$3@dont-email.me> |
| In reply to | #401498 |
On 26/08/2026 05:33, Janis Papanagnou wrote:
> On 2026-08-26 04:57, Tim Rentsch wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>>> On 2026-08-26 02:56, Keith Thompson wrote:
>>>
>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>>
>>>>> On 2026-08-18 01:49, Keith Thompson wrote:
>>>>>
>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>
>>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>>> Some people see that as an advantage - being able to write
>>>>>>>> "unsigned very_big = -1;". I dislike it personally, but styles
>>>>>>>> and preferences vary, and it has portability advantages over,
>>>>>>>> say, 0xffff'ffff.
>>>>>>>
>>>>>>> I also dislike that use of -1. I prefer using ~0ul to get
>>>>>>> all-ones.
>>>>>>
>>>>>> I'd use ~0ul to get all-ones,
>>>>>
>>>>> Exactly. As '~' is the bit-complement operator it's the most
>>>>> obvious, most consistent, and thus to be expected to be understood
>>>>> by most if not all C-programmers. But do we need the type
>>>>> qualification at all? A quick test seems to indicate that '~0'
>>>>> can be used for all integral types. (That's what my compiler
>>>>> says, don't know about the standard.)
>>>>>
>>>>>> -1 or -1u to get the largest value
>>>>>> of the type (or preferably UINT_MAX, but -1 is good if it's not
>>>>>> obvious *which* unsigned type I'm using).
>>>>
>>>> -1 is an expression of type int. Converting it to an unsigned type
>>>> always yields the largest value of that type. Same for -1 of any
>>>> signed type.
>>>>
>>>> -1u is of type unsigned int. Converting it to an unsigned type
>>>> wider than unsigned int will not give you the largest value of that
>>>> type. Using -1u makes sense only if you know you want a value of
>>>> type unsigned int.
>>>
>>> I'm not sure it was clear that my "But do we need the type
>>> qualification at all?" remark was meant for the '~0' context and
>>> "all-bits-set case".
>>>
>>> Mind, you had previously written: "I prefer using ~0ul". - And I
>>> was asking whether that would be necessary here, i.e. for the
>>> bits-case and unknown sizes of the underlying types. - I'd think
>>> that a "generic" '~0' would suffice (and impose the least
>>> surprises).
>>
>> The expression ~0 works for some conforming implementations.
>
> Not sure I understand your formulation ("some conforming ...").
>
> Are you implying that the following examples are non-portable,
> undefined, or depending on the concrete (standard-)conforming
> implementation, or something else?
>
> short unsigned int sd = ~0;
> unsigned int d = ~0;
> long unsigned int ld = ~0;
> long long unsigned int lld = ~0;
>
The behaviours of these are all defined, but are at least partially
implementation-defined.
"0" is of type "int". So "~0" gives the "int" value where all bits are
set to 1. Given two's complement representation (since we are now on
C23), that means the initialisations are the same as if you had written
"= -1;", and in each case your variable gets the highest value of the
target unsigned integer type.
Prior to C23, two's complement was not the only representation
available. The bit-inversion of 0 is not necessarily the value 1. With
sign-magnitude, it would (I think) be INT_MIN, and the conversion to an
unsigned type would not be all ones.
(Padding bits, if any, should not affect the results here.)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-26 20:29 +0200 |
| Message-ID | <116nbac$32eog$9@dont-email.me> |
| In reply to | #401503 |
On 2026-08-26 09:48, David Brown wrote:
> On 26/08/2026 05:33, Janis Papanagnou wrote:
>> On 2026-08-26 04:57, Tim Rentsch wrote:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>
>>>> On 2026-08-26 02:56, Keith Thompson wrote:
>>>>
>>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>>>
>>>>>> On 2026-08-18 01:49, Keith Thompson wrote:
>>>>>>
>>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>>
>>>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>>> Some people see that as an advantage - being able to write
>>>>>>>>> "unsigned very_big = -1;". I dislike it personally, but styles
>>>>>>>>> and preferences vary, and it has portability advantages over,
>>>>>>>>> say, 0xffff'ffff.
>>>>>>>>
>>>>>>>> I also dislike that use of -1. I prefer using ~0ul to get
>>>>>>>> all-ones.
>>>>>>>
>>>>>>> I'd use ~0ul to get all-ones,
>>>>>>
>>>>>> Exactly. As '~' is the bit-complement operator it's the most
>>>>>> obvious, most consistent, and thus to be expected to be understood
>>>>>> by most if not all C-programmers. But do we need the type
>>>>>> qualification at all? A quick test seems to indicate that '~0'
>>>>>> can be used for all integral types. (That's what my compiler
>>>>>> says, don't know about the standard.)
>>>>>>
>>>>>>> -1 or -1u to get the largest value
>>>>>>> of the type (or preferably UINT_MAX, but -1 is good if it's not
>>>>>>> obvious *which* unsigned type I'm using).
>>>>>
>>>>> -1 is an expression of type int. Converting it to an unsigned type
>>>>> always yields the largest value of that type. Same for -1 of any
>>>>> signed type.
>>>>>
>>>>> -1u is of type unsigned int. Converting it to an unsigned type
>>>>> wider than unsigned int will not give you the largest value of that
>>>>> type. Using -1u makes sense only if you know you want a value of
>>>>> type unsigned int.
>>>>
>>>> I'm not sure it was clear that my "But do we need the type
>>>> qualification at all?" remark was meant for the '~0' context and
>>>> "all-bits-set case".
>>>>
>>>> Mind, you had previously written: "I prefer using ~0ul". - And I
>>>> was asking whether that would be necessary here, i.e. for the
>>>> bits-case and unknown sizes of the underlying types. - I'd think
>>>> that a "generic" '~0' would suffice (and impose the least
>>>> surprises).
>>>
>>> The expression ~0 works for some conforming implementations.
>>
>> Not sure I understand your formulation ("some conforming ...").
>>
>> Are you implying that the following examples are non-portable,
>> undefined, or depending on the concrete (standard-)conforming
>> implementation, or something else?
>>
>> short unsigned int sd = ~0;
>> unsigned int d = ~0;
>> long unsigned int ld = ~0;
>> long long unsigned int lld = ~0;
>>
> The behaviours of these are all defined, but are at least partially
> implementation-defined.
("defined", "partially", "implementation-defined", well... - what
can a C-user *reliably* deduce from that...)
>
> "0" is of type "int". So "~0" gives the "int" value where all bits are
> set to 1. Given two's complement representation (since we are now on
> C23), that means the initialisations are the same as if you had written
> "= -1;", and in each case your variable gets the highest value of the
> target unsigned integer type.
>
> Prior to C23, two's complement was not the only representation
> available. The bit-inversion of 0 is not necessarily the value 1. With
> sign-magnitude, it would (I think) be INT_MIN, and the conversion to an
> unsigned type would not be all ones.
>
> (Padding bits, if any, should not affect the results here.)
I had written a longish reply on that but abstain from sending it,
instead, for the moment, I just like to ask - to obtain a better
understanding! - which of the following declarations are reliable
or unreliable, portable, depending on specific compilers - you know
what I mean - in your understanding.
All of the following declarations produce (with my GNU C-compiler)
no error diagnostics and no warning, not even with -Wall -Wpedantic
and with various standards from c89 to c2x defined). And they all
(i.e. the below printed subset) produce the same result (-1).
#include <stdio.h>
unsigned long int ula0 = 0;
unsigned long int ula1 = 0UL;
unsigned long int ula2 = (unsigned long int) (0);
unsigned long int ulb0 = -1;
unsigned long int ulb1 = -1UL;
unsigned long int ulb2 = -(1UL);
unsigned long int ulb3 = (unsigned long int) (-1);
unsigned long int ulc0 = ~0;
unsigned long int ulc1 = ~0UL;
unsigned long int ulc2 = (~0UL);
unsigned long int ulc3 = (unsigned long int) (~0);
unsigned long int ulb4 = (short) (-1);
unsigned long int ulc4 = ~(short) 0;
int main (void)
{
printf ("%ld\t%ld\n", ulb4, ulc4);
printf ("%ld\t%ld\n", ulb3, ulc3);
printf ("%ld\t%ld\n", ulb2, ulc2);
printf ("%ld\t%ld\n", ulb1, ulc1);
printf ("%ld\t%ld\n", ulb0, ulc0);
return 0;
}
And the following comparisons produce also 1 (true) and no warnings
when compiling.
printf ("%d\n", -1L == -1);
printf ("%d\n", ~0L == ~0);
Without extending on details of my withheld post, the operation of
the '~' is in K&R speaking about the "integral types" not the 'int'
type, as opposed to other operators' context where specifically the
'int' type is addressed.
IOW, yet (and still) I have to observe any reliability issue with ~0.
(Historically I worked also with other C-compilers, mostly commercial
ones; I never had any issues with that in "C". A lot of other commonly
known issues of "C" (pointers and memory, for example), but certainly
not with the bit-ops or type-unqualified literals in that context.)
Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-26 03:29 -0700 |
| Message-ID | <116mf6j$hoqk$1@kst.eternal-september.org> |
| In reply to | #401497 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> The expression ~0 works for some conforming implementations.
>
> The expression -1 works for all conforming implementations.
>
> Generally I tend to prefer code that always works over code
> that only sometimes works.
Are you referring to implementations that don't use 2's-complement?
Such implementations are non-conforming as of the current C standard
(C23).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-08-26 15:40 +0000 |
| Message-ID | <kNDjS.84528$7uhf.34008@fx06.iad> |
| In reply to | #401489 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >On 2026-08-18 01:49, Keith Thompson wrote: >> scott@slp53.sl.home (Scott Lurndal) writes: >>> David Brown <david.brown@hesbynett.no> writes: >> [...] >>>> Some people see that as an advantage - being able to write "unsigned >>>> very_big = -1;". I dislike it personally, but styles and preferences >>>> vary, and it has portability advantages over, say, 0xffff'ffff. >>> >>> I also dislike that use of -1. I prefer using ~0ul to get all-ones. >> >> I'd use ~0ul to get all-ones, > >Exactly. As '~' is the bit-complement operator it's the most obvious, >most consistent, and thus to be expected to be understood by most if >not all C-programmers. But do we need the type qualification at all? >A quick test seems to indicate that '~0' can be used for all integral >types. (That's what my compiler says, don't know about the standard.) I consider it as a note to the reader, not to the compiler.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-23 06:50 -0700 |
| Message-ID | <868q5xymgw.fsf@linuxsc.com> |
| In reply to | #401257 |
scott@slp53.sl.home (Scott Lurndal) writes: > [on using -1 to produce all ones in an unsigned type] > > I also dislike that use of -1. I prefer using ~0ul to get all-ones. A problem with patterns like ~0ul is that they are type specific. If the type of the destination changes, a wrong value might be the result. Also constructs using a suffix on an integer constant are limited in which types they can accommodate. Recently I have found it useful to employ 128-bit types, including __uint128_t, which cannot be designated using a suffix. Using cast is even worse. By contrast using -1 always works, regardless of the target type, and even for types outside of the standard basic types. If someone feels the use of -1 needs explaining, that is easily done with a comment: some_unsigned_type foo = -1; // all ones Personally I think every serious C developer should be thoroughly familiar with the use of -1 in conjunction with unsigned types, and not even need the comment. But I recognize that some circumstances may benefit from an explicit gloss.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-17 10:22 -0700 |
| Message-ID | <864igs3bmj.fsf@linuxsc.com> |
| In reply to | #401232 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-08-16 16:33, Tim Rentsch wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>> [a C version of someone's ipow() function]
>>>
>>> long long int ipow(long long a, int n) {
>>> long long int res;
>>>
>>> res = 1;
>>> if (n < 0) {
>>> res = 0;
>>>
>>> } else if (n == 0) {
>>> res = 1;
>>>
>>> } else if (n == 1) {
>>> res = a;
>>>
>>> } else if ((n & 1) == 0) { // n is even
>>> res = ipow(a*a, n/2);
>>>
>>> } else { // n is odd
>>> res = ipow(a*a, (n-1)/2)*a;
>>> }
>>>
>>> return res;
>>> }
>>
>> Two observations:
>>
>> One: one of the recursive calls is not properly tail recursive so
>> the recursion isn't always optimized out.
>
> You could as well write that also from the beginning in an iterative
> form (and not rely on optimizations of recursive functions - in case
> that this is a problem for the compilers in mind).
I find it easier simply to write a properly tail-recursive
implementation from the outset, where I know compilers will have
no difficulty optimizing out the tail calls.
>> Two: it gets wrong answers for in some cases with negative
>> exponents.
>
> Ah, a typical non-answer! - Given that negative exponents are (here)
> generally handled to provide a result of 0 - and assuming that is
> accepted as result, since other libraries may provide an exception
> or error here - what are these "some cases with negative exponents"
> you have in mind; if you are so deign to give an answer this time.
What is typical is your usual fractious misdirection style. You
might consider trying to lower your talking-to-thinking ratio.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-17 19:49 +0200 |
| Message-ID | <115vhj2$183lr$9@dont-email.me> |
| In reply to | #401260 |
On 2026-08-17 19:22, Tim Rentsch wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-08-16 16:33, Tim Rentsch wrote: > >>> [...] >> >> Ah, a typical non-answer! - [...] > > What is typical is your usual fractious misdirection style. You > might consider trying to lower your talking-to-thinking ratio. I suppose you're too old to expose a sane level of self-reflection. And hypocritical as well. Just in your recent post you complained about "an overly long thread" and regularly contribute non-answers. You might consider thinking and reflecting about your own posts and socio-pathological behavior before suggesting others what they should do. Good luck! Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-17 20:00 +0200 |
| Message-ID | <115vi86$183lr$10@dont-email.me> |
| In reply to | #401260 |
On 2026-08-17 19:22, Tim Rentsch wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-08-16 16:33, Tim Rentsch wrote: >>> >>> One: one of the recursive calls is not properly tail recursive so >>> the recursion isn't always optimized out. >> >> You could as well write that also from the beginning in an iterative >> form (and not rely on optimizations of recursive functions - in case >> that this is a problem for the compilers in mind). > > I find it easier simply to write a properly tail-recursive > implementation from the outset, Fair enough. > where I know compilers will have > no difficulty optimizing out the tail calls. Not all might know whether and what sorts of constructs their compilers are able to optimize. To me it's not obvious that simple (but non-tail-) recursions are typically not optimized. YMMV, but sensible optimizations is IMO task of the compilers; it shouldn't be necessary that you have to formulate programs using a specific programming pattern; ideally - but "C" as had been discussed not long ago exposes anyway a peculiar view of optimizations. (I'm sure YMMV.) Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-17 20:37 +0200 |
| Message-ID | <115vkcp$17o4a$1@dont-email.me> |
| In reply to | #401262 |
On 17/08/2026 20:00, Janis Papanagnou wrote: > On 2026-08-17 19:22, Tim Rentsch wrote: >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>> On 2026-08-16 16:33, Tim Rentsch wrote: >>>> >>>> One: one of the recursive calls is not properly tail recursive so >>>> the recursion isn't always optimized out. >>> >>> You could as well write that also from the beginning in an iterative >>> form (and not rely on optimizations of recursive functions - in case >>> that this is a problem for the compilers in mind). >> >> I find it easier simply to write a properly tail-recursive >> implementation from the outset, > > Fair enough. > >> where I know compilers will have >> no difficulty optimizing out the tail calls. > > Not all might know whether and what sorts of constructs their > compilers are able to optimize. To me it's not obvious that > simple (but non-tail-) recursions are typically not optimized. > YMMV, but sensible optimizations is IMO task of the compilers; > it shouldn't be necessary that you have to formulate programs > using a specific programming pattern; ideally - but "C" as had > been discussed not long ago exposes anyway a peculiar view of > optimizations. (I'm sure YMMV.) > You are correct - it is not at all obvious when a compiler might be able to figure out a loop version of a recursive function. In this case, gcc and clang managed to do so with the code as-is. And there are plenty of compilers (or compiler option choices) that cannot manage any kind of tail recursion optimisation. But it is possible to increase the chances of tail recursion optimisation being applied, by writing code in an appropriate style. As I noted earlier, it will make very little difference in this case because the recursion depth is not going to me more than a couple of levels anyway.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-26 02:48 +0200 |
| Message-ID | <116ld5r$32eoh$1@dont-email.me> |
| In reply to | #401263 |
On 2026-08-17 20:37, David Brown wrote:
> [ [tail] recursion optimisation of ipow() ]
>
> As I noted earlier, it will make very little difference in this case
> because the recursion depth is not going to me more than a couple of
> levels anyway.
BTW, out of curiosity I compiled the iterative version that I've shown
upthread[*] with different optimization levels.
Given that the code primitives are, well, primitive and easily mapable
I didn't expect much but - with a bit of additional code-frame to not
constantly feed the same values for 'a' and 'b' - I recall to have had
got a comparably huge performance gain (2.65 vs. 3.65) for an optimized
ipow() function.
Janis
[*] which had been
long int ipow (long int a, unsigned int n)
{
long int res = 1;
for ( ; n > 0; n /= 2) {
if (n & 1)
res *= a;
a *= a;
}
return res;
}
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-18 18:18 -0700 |
| Message-ID | <86mrui29ih.fsf@linuxsc.com> |
| In reply to | #401262 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 2026-08-17 19:22, Tim Rentsch wrote: > >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> >>> On 2026-08-16 16:33, Tim Rentsch wrote: >>> >>>> One: one of the recursive calls is not properly tail recursive so >>>> the recursion isn't always optimized out. >>> >>> You could as well write that also from the beginning in an iterative >>> form (and not rely on optimizations of recursive functions - in case >>> that this is a problem for the compilers in mind). >> >> I find it easier simply to write a properly tail-recursive >> implementation from the outset, > > Fair enough. > >> where I know compilers will have >> no difficulty optimizing out the tail calls. > > Not all might know whether and what sorts of constructs their > compilers are able to optimize. I wasn't advising anyone else what to write; just saying what I would find easier. > To me it's not obvious that > simple (but non-tail-) recursions are typically not optimized. By always using a tail-recursive formulation I don't have to care about what other forms are optimized. As a rule when I write recursive calls that are not tail recursive I expect them to generate actual calls; I don't mind if such cases are optimized but I don't care if they aren't. > YMMV, but sensible optimizations is IMO task of the compilers; > it shouldn't be necessary that you have to formulate programs > using a specific programming pattern; Perhaps I have given a wrong impression. I write code in a functional, and sometimes tail-recursive, style, not because I am thinking about whether it will be optimized but because I find it simple and natural and easy to understand. Of course I wouldn't do that if I thought it were going to perform badly, but I know from experience that it usually gets optimized to a non-recursive form. > ideally - but "C" as had > been discussed not long ago exposes anyway a peculiar view of > optimizations. (I'm sure YMMV.) Tail call elimination has both a long history and a good theoretical underpinning. Part of why it is so attractive is that it's easy to accomplish; I've been aware of and making use of tail call elimination since the early 1970s. I don't find it surprising at all that C compilers (and also compilers for other languages) exploit the ease of effecting these transformation, not only to help runtime performance but also as a way of reducing pressure on stack size. It's like compilers recognizing that multiplying or dividing by powers of two can be turned into shifts -- it allows developers to write code in a natural way, without having to think about what low-level transformations might be helpful to get around simplistic code generators. We are well past the primitive code generators of the 1950s.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-08-18 20:26 +0000 |
| Message-ID | <1162f4o$ahi$1@reader1.panix.com> |
| In reply to | #401260 |
In article <864igs3bmj.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-08-16 16:33, Tim Rentsch wrote: >>> [snip] >>> Two observations: >>> >>> One: one of the recursive calls is not properly tail recursive so >>> the recursion isn't always optimized out. >> >> You could as well write that also from the beginning in an iterative >> form (and not rely on optimizations of recursive functions - in case >> that this is a problem for the compilers in mind). > >I find it easier simply to write a properly tail-recursive >implementation from the outset, where I know compilers will have >no difficulty optimizing out the tail calls. At the language level, C does not guarantees tail optimization of recursive calls. Thus, the idea of writing, "a proper tail-recursive implementation from the outset" is a non sequitur. At best, expecting tail call optimization in a C program would be highly dependent on the translation environment. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-11 15:17 +0200 |
| Message-ID | <115f7cq$1659$1@dont-email.me> |
| In reply to | #400971 |
On 11/08/2026 13:45, bart wrote:
> On 11/08/2026 12:11, Bonita Montero wrote:
>> Am 11.08.2026 um 10:01 schrieb Lynn McGuire:
>>
>>> Why is there not a ipow version of pow?
>>> ipow would return an int instead of a double. Or a long long int.
>>
>> Integer multiplies have nearly the same cost as floating point multi-
>> plies.
>
> Have you done any actual measurements?
Apparently Bonita has not done any such checking.
>
> My language has an "**" operator which is overloaded for ints and floats.
>
> Doing a**b, which uses a special recursive routine for integers, is 5
> times as fast as for floats where it calls out to 'pow()' inside msvcrt
> C library.
>
> (This was for a=4, b=3; it will likely vary for integers depending on b,
> but b is unlikely to be large, as the results would overflow anyway.
> However for 2**63 - I'm using 64 bits - the integer version was still
> twice as fast.)
>
> With C, you are dependent on how well a compiler may optimise it. But an
> expression like c = pow(a, b), where a/b/c are all ints, still seemed to
> call pow() even using gcc-O3.
>
> In fact it is slower than with floats since conversion between ints and
> floats is needed.
>
>
Absolutely.
For small values of b, an inlined integer ipow() function (or built-in
feature of a language or compiler extension) will be a lot faster than
an external floating point function. There are all sorts of overheads
involved in the floating point option - some of which you have mentioned
- that apply even if an individual floating point multiply has the same
cost as an integer multiply. (And they are only the same cost on some
processors, in some circumstances.)
For b = 3, you are just doing "a * a * a" - generated inline, that will
be /far/ smaller than the overheads of converting back and forth between
integer and floating point types, and far below the overhead of an
external dll-based function call, even before you get to the calculation.
And a general-purpose floating-point pow() implementation has to cope
with any possible values of "a" and "b" - that means calculating exp(b *
log(a)). Each of "exp" and "log" is perhaps 60 cycles, and you also
have to use various extra complications to retain accuracy for different
ranges of "a" and "b". I would be surprised to find any value of "a"
and "b" for which "(int64_t) pow(a, b)" was faster than a recursive
integer implementation:
int64_t ipow(int64_t a, uint64_t b) {
return b ? ((b & 1) ? a : 1) * ipow(a * a, b >> 1) : 1;
}
A slightly more sophisticated version could have quick checks for small
values of "b", and tail recursion will turn this into a loop (or that
can be done manually). At worst you have 63 rounds, which will likely
still be faster than an external "pow" function, but of course in real
usage "b" will be much smaller or you'd overflow.
I think the reason that there is no "integer power" function in the
standard C library is that integer powers normally use fixed and small
exponents that are easy enough to write it out manually.
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web