Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #391319 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2025-03-18 21:38 -0400 |
| Last post | 2025-03-23 12:29 -0400 |
| Articles | 20 on this page of 422 — 23 participants |
Back to article view | Back to comp.lang.c
Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-18 21:38 -0400
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-18 19:05 -0700
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-18 19:22 -0700
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-18 22:43 -0400
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-18 20:11 -0700
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-18 20:07 -0700
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-18 23:34 -0400
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-19 04:01 +0000
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-19 00:38 -0400
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-18 22:27 -0700
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-19 13:23 -0400
Re: Suggested method for returning a string from a C program? James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-19 13:40 -0400
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 11:56 -0700
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-19 15:06 -0400
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-19 12:52 -0700
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-19 11:55 +0200
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-19 13:23 -0400
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-19 17:38 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-19 20:19 +0200
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-19 19:03 +0000
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 05:09 -0700
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-20 12:23 +0000
Re: Suggested method for returning a string from a C program? scott@slp53.sl.home (Scott Lurndal) - 2025-03-20 13:36 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-20 14:00 +0000
Re: Suggested method for returning a string from a C program? scott@slp53.sl.home (Scott Lurndal) - 2025-03-20 14:32 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-20 15:11 +0000
Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-24 16:37 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) scott@slp53.sl.home (Scott Lurndal) - 2025-03-24 16:14 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-24 17:20 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-24 21:56 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-25 08:45 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-25 09:08 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-25 19:55 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 09:18 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-25 08:39 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-25 03:51 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Michael S <already5chosen@yahoo.com> - 2025-03-25 13:11 +0200
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-25 05:02 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-25 16:33 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-25 20:04 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 09:23 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-25 13:31 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 09:34 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-26 02:59 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 12:33 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-26 15:59 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 17:37 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-26 12:38 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-26 22:53 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-26 15:15 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-27 10:11 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-29 18:25 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) bart <bc@freeuk.com> - 2025-03-29 18:20 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-30 01:39 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Alan Mackenzie <acm@muc.de> - 2025-03-31 17:15 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-31 19:48 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-31 21:14 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-31 14:56 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-26 14:07 -0400
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-26 17:58 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-26 14:20 -0400
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-26 12:42 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-26 17:36 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-27 13:48 -0400
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-27 18:31 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-29 10:14 -0400
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) scott@slp53.sl.home (Scott Lurndal) - 2025-03-29 16:39 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-29 21:02 -0400
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-27 12:31 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) bart <bc@freeuk.com> - 2025-03-27 20:06 +0000
Newsgroup etiquette Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-28 11:03 -0700
Re: Newsgroup etiquette Richard Heathfield <rjh@cpax.org.uk> - 2025-03-28 18:39 +0000
Re: Newsgroup etiquette Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-28 18:45 +0000
Re: Newsgroup etiquette Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-27 12:28 -0700
Re: Newsgroup etiquette Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-27 14:40 -0700
Re: Newsgroup etiquette Ethan Carter <ec1828@somewhere.edu> - 2025-04-28 00:59 -0300
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-26 15:58 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Michael S <already5chosen@yahoo.com> - 2025-03-25 19:09 +0200
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Richard Heathfield <rjh@cpax.org.uk> - 2025-03-25 17:34 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-25 19:49 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-25 12:53 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-25 13:39 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-07 00:04 -0800
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-25 13:23 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 09:50 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-25 16:22 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Richard Harnden <richard.nospam@gmail.invalid> - 2025-03-25 18:18 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-25 19:55 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-25 13:41 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-25 23:35 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-25 16:38 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-25 19:55 -0400
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 10:00 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Michael S <already5chosen@yahoo.com> - 2025-03-26 16:01 +0200
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Richard Heathfield <rjh@cpax.org.uk> - 2025-03-26 14:45 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Michael S <already5chosen@yahoo.com> - 2025-03-26 17:16 +0200
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-26 08:55 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 17:45 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Richard Heathfield <rjh@cpax.org.uk> - 2025-03-26 17:22 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Richard Heathfield <rjh@cpax.org.uk> - 2025-03-26 17:19 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 17:40 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Richard Heathfield <rjh@cpax.org.uk> - 2025-03-26 17:25 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 21:27 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Richard Heathfield <rjh@cpax.org.uk> - 2025-03-26 20:34 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-26 13:50 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Richard Heathfield <rjh@cpax.org.uk> - 2025-03-26 21:04 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-26 14:12 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Richard Heathfield <rjh@cpax.org.uk> - 2025-03-26 21:18 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Michael S <already5chosen@yahoo.com> - 2025-03-26 23:22 +0200
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-26 14:38 -0400
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-26 18:52 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 17:32 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) antispam@fricas.org (Waldek Hebisch) - 2025-03-26 22:29 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-26 14:31 -0400
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 21:33 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) bart <bc@freeuk.com> - 2025-03-28 15:42 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-25 19:52 -0400
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-25 17:16 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-25 04:55 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-25 13:48 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Richard Heathfield <rjh@cpax.org.uk> - 2025-03-25 21:52 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-25 22:36 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Richard Heathfield <rjh@cpax.org.uk> - 2025-03-25 23:14 +0000
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 10:09 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-03 20:03 -0700
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-05-04 14:04 +0200
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-04 15:43 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-05-04 18:39 +0200
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-04 19:02 +0100
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-05-05 11:29 +0200
Re: Integral types and own type definitions (was Re: Suggested method for returning a string from a C program?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-15 23:02 -0700
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-20 14:50 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-20 16:59 +0200
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-20 15:16 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-20 17:29 +0200
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-20 15:55 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-23 11:01 +0200
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-23 12:56 -0700
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 11:47 -0700
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 12:28 -0700
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-20 15:40 +0000
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-20 15:57 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-20 20:46 +0200
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-20 19:15 +0000
Re: Suggested method for returning a string from a C program? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-20 19:58 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-20 22:57 +0200
Re: Suggested method for returning a string from a C program? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-20 21:10 +0000
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 16:10 -0700
The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-24 16:59 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-24 15:57 -0700
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-25 10:38 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-25 16:31 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-25 19:23 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-25 13:14 -0700
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 23:50 -0700
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 10:33 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-25 19:18 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) bart <bc@freeuk.com> - 2025-03-25 18:50 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-25 20:45 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) bart <bc@freeuk.com> - 2025-03-25 23:30 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-26 14:59 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 11:29 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-26 15:08 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 17:50 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-26 19:09 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 21:39 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) bart <bc@freeuk.com> - 2025-03-26 23:21 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) scott@slp53.sl.home (Scott Lurndal) - 2025-03-26 23:51 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) bart <bc@freeuk.com> - 2025-03-27 00:32 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) scott@slp53.sl.home (Scott Lurndal) - 2025-03-27 13:51 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) antispam@fricas.org (Waldek Hebisch) - 2025-03-27 01:10 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) bart <bc@freeuk.com> - 2025-03-27 01:33 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-27 10:54 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) scott@slp53.sl.home (Scott Lurndal) - 2025-03-27 14:09 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) antispam@fricas.org (Waldek Hebisch) - 2025-03-28 17:49 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) scott@slp53.sl.home (Scott Lurndal) - 2025-03-27 14:07 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-27 03:24 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) bart <bc@freeuk.com> - 2025-03-27 11:14 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) scott@slp53.sl.home (Scott Lurndal) - 2025-03-27 14:14 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-28 02:05 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-28 10:13 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-28 11:22 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Michael S <already5chosen@yahoo.com> - 2025-03-28 14:32 +0300
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-28 13:42 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) bart <bc@freeuk.com> - 2025-03-28 11:37 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-28 13:53 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-28 13:00 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-28 14:06 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-28 10:05 -0700
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) bart <bc@freeuk.com> - 2025-03-28 12:19 +0000
[OT] PC hardware prices [correction] (was Re: The integral type 'byte') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-31 21:35 +0200
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-27 15:04 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-28 02:59 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-27 19:03 -0700
[OT] SPARC (was Re: The integral type 'byte') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-28 03:26 +0100
Re: [OT] SPARC (was Re: The integral type 'byte') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-27 23:14 -0700
Re: [OT] SPARC (was Re: The integral type 'byte') Michael S <already5chosen@yahoo.com> - 2025-03-28 13:26 +0300
Re: [OT] SPARC (was Re: The integral type 'byte') David Brown <david.brown@hesbynett.no> - 2025-03-28 13:08 +0100
Re: [OT] SPARC (was Re: The integral type 'byte') Michael S <already5chosen@yahoo.com> - 2025-03-28 15:20 +0300
Re: [OT] SPARC (was Re: The integral type 'byte') David Brown <david.brown@hesbynett.no> - 2025-03-28 15:33 +0100
Re: [OT] SPARC (was Re: The integral type 'byte') "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-28 10:26 -0700
Re: [OT] SPARC (was Re: The integral type 'byte') "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-28 10:27 -0700
Re: [OT] SPARC (was Re: The integral type 'byte') Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-28 18:44 +0000
Re: [OT] SPARC (was Re: The integral type 'byte') Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-28 17:46 +0000
Re: [OT] SPARC (was Re: The integral type 'byte') Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-28 17:45 +0000
Re: [OT] SPARC (was Re: The integral type 'byte') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-28 13:20 +0100
Re: [OT] SPARC (was Re: The integral type 'byte') Michael S <already5chosen@yahoo.com> - 2025-03-28 15:56 +0300
Re: [OT] SPARC (was Re: The integral type 'byte') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-28 14:20 +0100
Re: [OT] SPARC (was Re: The integral type 'byte') David Brown <david.brown@hesbynett.no> - 2025-03-28 15:43 +0100
Re: [OT] SPARC (was Re: The integral type 'byte') Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-28 17:54 +0000
Re: [OT] SPARC (was Re: The integral type 'byte') "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-28 10:16 -0700
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-28 11:03 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Michael S <already5chosen@yahoo.com> - 2025-03-28 14:01 +0300
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) bart <bc@freeuk.com> - 2025-03-28 11:29 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-28 12:46 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-28 12:30 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 11:10 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Richard Harnden <richard.nospam@gmail.invalid> - 2025-03-26 11:02 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 12:47 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) bart <bc@freeuk.com> - 2025-03-26 13:12 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 14:48 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-26 15:40 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-26 18:29 +0000
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-26 15:22 +0100
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-26 13:09 -0700
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-25 13:16 -0700
Re: The integral type 'byte' (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 11:33 +0100
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 12:22 -0700
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 12:10 -0700
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-20 20:59 +0000
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 16:18 -0700
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-20 23:55 +0000
Re: Suggested method for returning a string from a C program? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-21 00:46 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-21 01:23 +0000
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 18:47 -0700
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-21 11:53 +0000
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-21 12:04 -0700
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-22 00:23 +0000
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-21 20:50 -0700
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-22 13:06 +0000
Re: Suggested method for returning a string from a C program? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-22 14:51 -0700
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-22 14:52 -0700
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-23 01:34 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-23 10:50 +0200
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-23 11:25 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-23 14:12 +0200
Re: Suggested method for returning a string from a C program? David Brown <david.brown@hesbynett.no> - 2025-03-24 12:51 +0100
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-24 14:07 +0000
Re: Suggested method for returning a string from a C program? David Brown <david.brown@hesbynett.no> - 2025-03-24 15:32 +0100
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-24 15:00 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-24 17:22 +0200
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-24 16:12 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-24 16:02 +0000
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-24 16:17 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-24 16:49 +0000
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-24 16:56 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-24 18:20 +0000
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-25 08:40 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-25 11:09 +0000
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-25 14:46 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-25 15:04 +0000
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-25 15:09 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-25 16:40 +0000
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-26 09:20 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-26 10:07 +0000
Re: Suggested method for returning a string from a C program? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-26 18:06 +0000
Re: Suggested method for returning a string from a C program? antispam@fricas.org (Waldek Hebisch) - 2025-03-27 00:22 +0000
Re: Suggested method for returning a string from a C program? scott@slp53.sl.home (Scott Lurndal) - 2025-03-27 14:22 +0000
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-27 10:54 -0700
Re: Suggested method for returning a string from a C program? scott@slp53.sl.home (Scott Lurndal) - 2025-03-28 16:13 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-28 16:40 +0000
Re: Suggested method for returning a string from a C program? scott@slp53.sl.home (Scott Lurndal) - 2025-03-28 20:41 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-28 22:18 +0000
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-28 15:33 -0700
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-28 22:48 +0000
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-28 16:53 -0700
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-29 00:32 +0000
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-28 18:50 -0700
Re: Suggested method for returning a string from a C program? scott@slp53.sl.home (Scott Lurndal) - 2025-03-29 16:24 +0000
Re: Suggested method for returning a string from a C program? David Brown <david.brown@hesbynett.no> - 2025-03-29 13:37 +0100
Re: Suggested method for returning a string from a C program? scott@slp53.sl.home (Scott Lurndal) - 2025-03-29 16:33 +0000
Re: Suggested method for returning a string from a C program? scott@slp53.sl.home (Scott Lurndal) - 2025-03-29 17:23 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-29 18:11 +0000
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-28 10:57 -0700
Re: Suggested method for returning a string from a C program? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-25 16:16 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-25 13:29 +0200
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-25 14:58 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-25 17:14 +0200
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-25 16:37 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-25 19:00 +0200
Re: Suggested method for returning a string from a C program? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-24 17:15 +0000
Code-change-to-run times (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-24 18:44 +0100
Re: Code-change-to-run times (was Re: Suggested method for returning a string from a C program?) Michael S <already5chosen@yahoo.com> - 2025-03-24 23:06 +0200
Re: Code-change-to-run times (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-24 23:44 +0100
Re: Code-change-to-run times (was Re: Suggested method for returning a string from a C program?) Michael S <already5chosen@yahoo.com> - 2025-03-25 13:00 +0200
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-24 21:16 +0000
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-25 08:41 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-25 11:04 +0000
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-25 14:43 +0000
Re: Suggested method for returning a string from a C program? scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 13:51 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-25 14:22 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-24 17:10 +0200
Re: Suggested method for returning a string from a C program? David Brown <david.brown@hesbynett.no> - 2025-03-24 19:07 +0100
Re: Suggested method for returning a string from a C program? scott@slp53.sl.home (Scott Lurndal) - 2025-03-24 15:44 +0000
Re: Suggested method for returning a string from a C program? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 11:27 -0700
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-24 20:13 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-24 23:01 +0200
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-25 11:17 +0000
Re: Suggested method for returning a string from a C program? scott@slp53.sl.home (Scott Lurndal) - 2025-03-24 15:42 +0000
Re: Suggested method for returning a string from a C program? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 11:27 -0700
Compiler speed (ad nauseam) (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-24 18:01 +0100
Re: Suggested method for returning a string from a C program? James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-24 19:25 -0400
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-25 00:53 +0000
Re: Suggested method for returning a string from a C program? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 19:00 -0700
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-24 21:50 -0700
Re: Suggested method for returning a string from a C program? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-25 08:19 +0100
Re: Suggested method for returning a string from a C program? David Brown <david.brown@hesbynett.no> - 2025-03-22 14:41 +0100
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-23 11:41 +0200
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-23 14:13 -0700
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-23 23:19 +0200
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-22 07:05 -0700
Re: Suggested method for returning a string from a C program? antispam@fricas.org (Waldek Hebisch) - 2025-03-22 02:37 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-22 12:20 +0000
Re: Suggested method for returning a string from a C program? antispam@fricas.org (Waldek Hebisch) - 2025-03-22 13:50 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-22 15:47 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-22 17:00 +0000
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-22 15:31 -0700
Re: Suggested method for returning a string from a C program? antispam@fricas.org (Waldek Hebisch) - 2025-03-21 17:51 +0000
Re: Suggested method for returning a string from a C program? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-21 18:51 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-22 02:16 +0000
Re: Suggested method for returning a string from a C program? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-22 04:15 +0000
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-21 21:24 -0700
Re: Suggested method for returning a string from a C program? antispam@fricas.org (Waldek Hebisch) - 2025-03-22 14:07 +0000
Fast division (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-26 02:04 +0100
Re: Fast division (was Re: Suggested method for returning a string from a C program?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-25 22:35 -0400
Re: Fast division (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 12:40 +0100
Re: Fast division (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-26 14:47 +0100
Re: Fast division (was Re: Suggested method for returning a string from a C program?) David Brown <david.brown@hesbynett.no> - 2025-03-26 17:55 +0100
Re: Fast division (was Re: Suggested method for returning a string from a C program?) Michael S <already5chosen@yahoo.com> - 2025-03-26 19:36 +0200
Re: Fast division (was Re: Suggested method for returning a string from a C program?) antispam@fricas.org (Waldek Hebisch) - 2025-03-26 13:44 +0000
Re: Fast division (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-26 16:19 +0100
Re: Fast division (was Re: Suggested method for returning a string from a C program?) antispam@fricas.org (Waldek Hebisch) - 2025-03-26 02:37 +0000
Re: Fast division (was Re: Suggested method for returning a string from a C program?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-26 14:42 +0100
Re: Fast division (was Re: Suggested method for returning a string from a C program?) Rosario19 <Ros@invalid.invalid> - 2025-03-26 19:01 +0100
Re: Fast division (was Re: Suggested method for returning a string from a C program?) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-26 18:49 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-22 00:01 +0000
Re: Suggested method for returning a string from a C program? antispam@fricas.org (Waldek Hebisch) - 2025-03-22 01:41 +0000
Re: Suggested method for returning a string from a C program? scott@slp53.sl.home (Scott Lurndal) - 2025-03-22 14:22 +0000
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-22 14:32 +0000
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-22 16:25 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-20 16:35 +0200
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-20 14:42 +0000
Re: Suggested method for returning a string from a C program? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-20 16:20 +0000
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 11:33 -0700
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 12:07 -0700
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-19 12:59 -0700
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-19 22:12 +0200
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 05:19 -0700
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-18 20:26 -0700
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-19 00:42 -0400
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-19 04:51 +0000
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-19 01:02 -0400
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-19 05:23 +0000
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 06:06 -0700
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-20 13:27 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-20 16:50 +0200
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 11:24 -0700
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-20 18:53 +0000
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 16:56 -0700
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-22 16:46 -0700
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-23 08:25 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-23 12:06 +0200
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-23 10:15 +0000
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-23 12:35 -0700
Re: Suggested method for returning a string from a C program? David Brown <david.brown@hesbynett.no> - 2025-03-24 13:09 +0100
Re: Suggested method for returning a string from a C program? Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2025-03-22 19:07 +1100
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-22 13:25 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-22 19:12 +0200
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-22 19:17 +0200
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-22 17:22 +0000
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-22 10:29 -0400
Re: Suggested method for returning a string from a C program? Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2025-03-25 21:41 +1100
Re: Suggested method for returning a string from a C program? scott@slp53.sl.home (Scott Lurndal) - 2025-03-22 14:30 +0000
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-22 11:31 -0400
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-22 19:19 +0200
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-22 14:54 -0700
Re: Suggested method for returning a string from a C program? Ike Naar <ike@sdf.org> - 2025-03-19 07:16 +0000
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 01:53 -0700
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-19 16:45 -0400
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-19 21:21 +0000
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-19 21:35 +0000
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 14:56 -0700
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-19 22:34 -0400
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 19:46 -0700
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-19 11:25 -0400
Re: Suggested method for returning a string from a C program? bart <bc@freeuk.com> - 2025-03-19 10:15 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-19 12:40 +0200
Re: Suggested method for returning a string from a C program? David Brown <david.brown@hesbynett.no> - 2025-03-19 17:42 +0100
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-19 09:03 -0400
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-19 14:40 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-19 17:39 +0200
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-19 15:42 +0000
Re: Suggested method for returning a string from a C program? Alexis <flexibeast@gmail.com> - 2025-03-22 15:05 +1100
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-22 10:19 +0000
Re: Suggested method for returning a string from a C program? Alexis <flexibeast@gmail.com> - 2025-03-23 11:05 +1100
Re: Suggested method for returning a string from a C program? Muttley@dastardlyhq.com - 2025-03-23 16:22 +0000
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-19 13:13 -0700
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-20 09:50 +0000
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 04:59 -0700
Re: Suggested method for returning a string from a C program? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-20 16:14 +0000
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-20 16:29 +0000
Re: Suggested method for returning a string from a C program? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-20 16:49 +0000
Re: Suggested method for returning a string from a C program? Muttley@DastardlyHQ.org - 2025-03-21 09:09 +0000
Re: Suggested method for returning a string from a C program? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-21 17:12 +0000
Re: Suggested method for returning a string from a C program? Michael S <already5chosen@yahoo.com> - 2025-03-19 12:36 +0200
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-19 09:13 -0400
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 05:15 -0700
Re: Suggested method for returning a string from a C program? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 12:14 -0700
Re: Suggested method for returning a string from a C program? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-21 00:05 -0700
Re: Suggested method for returning a string from a C program? Richard Heathfield <rjh@cpax.org.uk> - 2025-03-21 07:48 +0000
Re: Suggested method for returning a string from a C program? Lynn McGuire <lynnmcguire5@gmail.com> - 2025-03-22 13:32 -0500
Re: Suggested method for returning a string from a C program? DFS <nospam@dfs.com> - 2025-03-23 12:29 -0400
Page 17 of 22 — ← Prev page 1 … 15 16 [17] 18 19 … 22 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-03-22 07:05 -0700 |
| Message-ID | <86tt7lkvnv.fsf@linuxsc.com> |
| In reply to | #391472 |
bart <bc@freeuk.com> writes: > On 21/03/2025 01:47, Keith Thompson wrote: > >> I just >> did a quick test comparing complation times for an empty program >> with no #include directives and an empty program with #include >> directives for <stdint.h> and <inttypes.h>. The difference was >> about 3 milliseconds. I quite literally could not care care less. > > I'm sorry but that's a really poor attitude, with bad > consequences. I'm with Keith on this one, and I expect most other C developers are also. > You're saying it doesn't matter how complex a header or > set of headers is, even when out of proportion to the task. This paraphrasing doesn't match what Keith said. Whether deliberately or not, your interpretation is off base.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-03-22 02:37 +0000 |
| Message-ID | <vrl7p7$2lnkl$1@paganini.bofh.team> |
| In reply to | #391453 |
bart <bc@freeuk.com> wrote:
>
> Sorry, but there's something wrong if you have to write all that to get
> a handful of fixed-width types. (And if this is for a multitude of
> targets, then there should be a dedicated header per target).
>
> GCC's stdint.h is 200 lines. Mine is 75 lines. It these types were part
> of the core language, it would be zero lines.
You need few (say 3) lines of compiler code to define a type.
AFAICS there are 24 types in intXX... and uintXX... family.
So about 72 lines in compiler. For compatiblity with older
code you probably should define types under internal names
and have 24 lines in stdint.h (+3 lines of include guard).
stdint.h defines quite a bit more than just types, so actual
saving from having them built into compiler would be small,
in particular since preprocessor is fast. On my machine
I see 91 code lines after preprocessing of stdint.h. And
actually, several of definitions like '__pid_t' go beyond C
and are needed by other headers. So, really is not a big
deal.
BTW: I just tried
/tmp$ time gcc -E foo.c | wc
1000006 2000022 12889013
real 0m0.359s
user 0m0.351s
sys 0m0.085s
So gcc preprocessor is able to handle almost 3 million lines
per second. The lines were short, but gcc goes trough
piles of header files resonably fast, probably much faster
than you think.
I also tried to compile file contaning 100000 declarations
like:
extern int a0(void);
....
extern int a999999(void);
Compilation of such file takes 1.737s, so about 575000 lines
per second. So a lot of function declarations in header
files should not slow gcc too much. Typedefs seem to
trigger quadratic behaviour, so a lot of typedefs is likely
to slow down gcc quite a lot. But a limited bunch of
typedefs should not be too bad. And it probably does not
make much difference if the typedefs are in source file
or built into compiler.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-03-22 12:20 +0000 |
| Message-ID | <vrm9v3$3uioh$1@dont-email.me> |
| In reply to | #391489 |
On 22/03/2025 02:37, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>>
>> Sorry, but there's something wrong if you have to write all that to get
>> a handful of fixed-width types. (And if this is for a multitude of
>> targets, then there should be a dedicated header per target).
>>
>> GCC's stdint.h is 200 lines. Mine is 75 lines. It these types were part
>> of the core language, it would be zero lines.
>
> You need few (say 3) lines of compiler code to define a type.
> AFAICS there are 24 types in intXX... and uintXX... family.
There's about 8, unless you include FAST/LEAST which are of interest to
a minority of the minority who are even aware of them.
> So about 72 lines in compiler. For compatiblity with older
> code you probably should define types under internal names
> and have 24 lines in stdint.h (+3 lines of include guard).
It's a lot more than 72 lines in a compiler to support numeric types.
But this is about exposing fixed-size type aliases to existing types,
which can be done fairly tidily in a compiler, but not as tidily as when
all the built-in types can be expressed as one token; some need multiple
tokens.
Also C requires those aliases to be hidden unless a particular header is
used.
Still, I was remarking on those Q8 headers requiring 1300 lines to add
these aliases.
> stdint.h defines quite a bit more than just types, so actual
> saving from having them built into compiler would be small,
> in particular since preprocessor is fast. On my machine
> I see 91 code lines after preprocessing of stdint.h. And
> actually, several of definitions like '__pid_t' go beyond C
> and are needed by other headers. So, really is not a big
> deal.
>
> BTW: I just tried
>
> /tmp$ time gcc -E foo.c | wc
> 1000006 2000022 12889013
>
> real 0m0.359s
> user 0m0.351s
> sys 0m0.085s
>
> So gcc preprocessor is able to handle almost 3 million lines
> per second. The lines were short, but gcc goes trough
> piles of header files resonably fast, probably much faster
> than you think.
Testing -E is tricky, since the output is textual, and usually
interspersed with # lines giving source line number info.
What was in foo.c?
In any case, I know that gcc can process headers reasonably fast
(otherwise it would take 10 seconds to plough through windows.h at the
speed of compiling code).
But it's the sheer size and scale of some headers that is the problem.
Why do you think precompiled headers were invented?
Compiling this program:
#define SDL_MAIN_HANDLED
#include "SDL2/SDL.h"
int main(){}
took gcc 0.85 seconds on my machine (however hello.c takes 0.2 seconds)
(SDL2 headers comprise 75 .h files and 50K lines; so about 75Kloc
throughput.)
Compiling this program:
#include <windows.h>
int main(){}
took 1.36 seconds. window.h might comprise 100 or 165 unique headers,
with 100-200K unique lines of code; I forget.
These figures are for each module that uses those headers. (My bcc took
0.07 seconds for the SDL test. The windows.h test can't be compared as
my version of that header is much smaller.)
> I also tried to compile file contaning 100000 declarations
> like:
>
> extern int a0(void);
> ....
> extern int a999999(void);
>
> Compilation of such file takes 1.737s, so about 575000 lines
> per second. So a lot of function declarations in header
> files should not slow gcc too much.
I get these results (the test file has 'int main(){}' at the end):
c:\c>tim gcc fred.c
Time: 4.832
c:\c>tim tcc fred.c
Time: 4.620
c:\c>tim bcc fred.c
Compiling fred.c to fred.exe
Time: 1.324
Bear in mind that both gcc/tcc are presumably optimised code; bcc isn't)
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-03-22 13:50 +0000 |
| Message-ID | <vrmf6u$2nif7$1@paganini.bofh.team> |
| In reply to | #391495 |
bart <bc@freeuk.com> wrote:
> On 22/03/2025 02:37, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>>>
>>> Sorry, but there's something wrong if you have to write all that to get
>>> a handful of fixed-width types. (And if this is for a multitude of
>>> targets, then there should be a dedicated header per target).
>>>
>>> GCC's stdint.h is 200 lines. Mine is 75 lines. It these types were part
>>> of the core language, it would be zero lines.
>>
>> You need few (say 3) lines of compiler code to define a type.
>> AFAICS there are 24 types in intXX... and uintXX... family.
>
> There's about 8, unless you include FAST/LEAST which are of interest to
> a minority of the minority who are even aware of them.
Well, FAST/LEAST types are mandatory for standard compliance.
>> So about 72 lines in compiler. For compatiblity with older
>> code you probably should define types under internal names
>> and have 24 lines in stdint.h (+3 lines of include guard).
>
> It's a lot more than 72 lines in a compiler to support numeric types.
>
> But this is about exposing fixed-size type aliases to existing types,
> which can be done fairly tidily in a compiler,
Yes, there is complex machinery to support types and compiler
data structires in general. But once machinery is in place
you need to create type node and insert it into symbol table.
In gcc creation of type node may look like:
sizetype = make_node (INTEGER_TYPE);
TYPE_NAME (sizetype) = get_identifier ("sizetype");
TYPE_PRECISION (sizetype) = precision;
TYPE_UNSIGNED (sizetype) = 1;
scalar_int_mode mode = smallest_int_mode_for_size (precision);
SET_TYPE_MODE (sizetype, mode);
SET_TYPE_ALIGN (sizetype, GET_MODE_ALIGNMENT (TYPE_MODE (sizetype)));
TYPE_SIZE (sizetype) = bitsize_int (precision);
TYPE_SIZE_UNIT (sizetype) = size_int (GET_MODE_SIZE (mode));
set_min_and_max_values_for_integral_type (sizetype, precision, UNSIGNED);
But such things are repeated for several types, so one can have
function like 'create_integer_type_node' which is doing the above,
but for type name and precision which are arguments to the function.
Of course, if you need to do soemthing special to a type, then
you may need a lot of code. But integer types should be handled
anyway, so there is really no special code beyond what is already
there.
> but not as tidily as when
> all the built-in types can be expressed as one token; some need multiple
> tokens.
Unlike classic integer types, types in stdint.h have names which
are single token, so all you need to do is to insert entry in the
symbol table.
> Also C requires those aliases to be hidden unless a particular header is
> used.
Yes, so either one need some mechanism to hide/expose builtin
indentifiers, or (what is typically done) one need to use
reserved names for builtin indentifiers and use stdint.h to
define standard name as an alias.
> Still, I was remarking on those Q8 headers requiring 1300 lines to add
> these aliases.
I am not sure if Q8 really needed all those lines. But you
should take into account that it provided type without
cooperation with the compiler.
>> stdint.h defines quite a bit more than just types, so actual
>> saving from having them built into compiler would be small,
>> in particular since preprocessor is fast. On my machine
>> I see 91 code lines after preprocessing of stdint.h. And
>> actually, several of definitions like '__pid_t' go beyond C
>> and are needed by other headers. So, really is not a big
>> deal.
>>
>> BTW: I just tried
>>
>> /tmp$ time gcc -E foo.c | wc
>> 1000006 2000022 12889013
>>
>> real 0m0.359s
>> user 0m0.351s
>> sys 0m0.085s
>>
>> So gcc preprocessor is able to handle almost 3 million lines
>> per second. The lines were short, but gcc goes trough
>> piles of header files resonably fast, probably much faster
>> than you think.
>
> Testing -E is tricky, since the output is textual, and usually
> interspersed with # lines giving source line number info.
>
> What was in foo.c?
Just 1000000 lines of declarations (no includes etc.). The
point was that skipping input is easier than copying things to
the output, so that should give reasonable estimate of time
spent on parts that disappear after preprocessing.
> In any case, I know that gcc can process headers reasonably fast
> (otherwise it would take 10 seconds to plough through windows.h at the
> speed of compiling code).
>
> But it's the sheer size and scale of some headers that is the problem.
> Why do you think precompiled headers were invented?
Some headers are pretty big. But fact that at source level
stdint.h has some hundreds of lines is not big problem, it
is still rather small. Note that it is convenient to have
common headers for variants of architecure, on my Linux
I can run 3 kinds of programs: classic 32-bit ones, 64-bit ones
and x32 (which uses 32-bit addresses, but uses 64-bit
instructions). Each needs slightly different definitions
in header files. This is handled by conditionals in
header files. And in fact large part of headers are shared
with different architecures (and even different OS-es using
the same libc).
> Compiling this program:
>
> #define SDL_MAIN_HANDLED
> #include "SDL2/SDL.h"
> int main(){}
>
> took gcc 0.85 seconds on my machine (however hello.c takes 0.2 seconds)
>
> (SDL2 headers comprise 75 .h files and 50K lines; so about 75Kloc
> throughput.)
>
> Compiling this program:
>
> #include <windows.h>
> int main(){}
>
> took 1.36 seconds. window.h might comprise 100 or 165 unique headers,
> with 100-200K unique lines of code; I forget.
>
> These figures are for each module that uses those headers. (My bcc took
> 0.07 seconds for the SDL test. The windows.h test can't be compared as
> my version of that header is much smaller.)
>
>
>> I also tried to compile file contaning 100000 declarations
^^^^^^
Oops, should be 1000000.
>> like:
>>
>> extern int a0(void);
>> ....
>> extern int a999999(void);
>>
>> Compilation of such file takes 1.737s, so about 575000 lines
>> per second. So a lot of function declarations in header
>> files should not slow gcc too much.
>
> I get these results (the test file has 'int main(){}' at the end):
>
> c:\c>tim gcc fred.c
> Time: 4.832
>
> c:\c>tim tcc fred.c
> Time: 4.620
>
> c:\c>tim bcc fred.c
> Compiling fred.c to fred.exe
> Time: 1.324
>
> Bear in mind that both gcc/tcc are presumably optimised code; bcc isn't)
On my machine tcc preprocesses probably about 20% faster than gcc.
For timing compilation I used 'gcc -c' to generate linkable object
file, so no need to have 'main'. When actually compilning on my
machine tcc is significantly faster, on the same file 'tcc -c'
takes 0.418s, so more than 4 times faster than 'gcc -c'.
I do not know why 'tcc' is that much faster. One possibility
is that 'gcc' contains various extra info in compiler data
structures that help when optimizing, but require extra effort
even when not optimiziong.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-03-22 15:47 +0000 |
| Message-ID | <vrmm2d$933o$1@dont-email.me> |
| In reply to | #391501 |
On 22/03/2025 13:50, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> On 22/03/2025 02:37, Waldek Hebisch wrote:
>>> bart <bc@freeuk.com> wrote:
>>>>
>>>> Sorry, but there's something wrong if you have to write all that to get
>>>> a handful of fixed-width types. (And if this is for a multitude of
>>>> targets, then there should be a dedicated header per target).
>>>>
>>>> GCC's stdint.h is 200 lines. Mine is 75 lines. It these types were part
>>>> of the core language, it would be zero lines.
>>>
>>> You need few (say 3) lines of compiler code to define a type.
>>> AFAICS there are 24 types in intXX... and uintXX... family.
>>
>> There's about 8, unless you include FAST/LEAST which are of interest to
>> a minority of the minority who are even aware of them.
>
> Well, FAST/LEAST types are mandatory for standard compliance.
>
>>> So about 72 lines in compiler. For compatiblity with older
>>> code you probably should define types under internal names
>>> and have 24 lines in stdint.h (+3 lines of include guard).
>>
>> It's a lot more than 72 lines in a compiler to support numeric types.
>>
>> But this is about exposing fixed-size type aliases to existing types,
>> which can be done fairly tidily in a compiler,
>
> Yes, there is complex machinery to support types and compiler
> data structires in general. But once machinery is in place
> you need to create type node and insert it into symbol table.
> In gcc creation of type node may look like:
>
> sizetype = make_node (INTEGER_TYPE);
> TYPE_NAME (sizetype) = get_identifier ("sizetype");
> TYPE_PRECISION (sizetype) = precision;
> TYPE_UNSIGNED (sizetype) = 1;
> scalar_int_mode mode = smallest_int_mode_for_size (precision);
> SET_TYPE_MODE (sizetype, mode);
> SET_TYPE_ALIGN (sizetype, GET_MODE_ALIGNMENT (TYPE_MODE (sizetype)));
> TYPE_SIZE (sizetype) = bitsize_int (precision);
> TYPE_SIZE_UNIT (sizetype) = size_int (GET_MODE_SIZE (mode));
> set_min_and_max_values_for_integral_type (sizetype, precision, UNSIGNED);
>
> But such things are repeated for several types, so one can have
> function like 'create_integer_type_node' which is doing the above,
> but for type name and precision which are arguments to the function.
>
> Of course, if you need to do soemthing special to a type, then
> you may need a lot of code. But integer types should be handled
> anyway, so there is really no special code beyond what is already
> there.
>
>> but not as tidily as when
>> all the built-in types can be expressed as one token; some need multiple
>> tokens.
>
> Unlike classic integer types, types in stdint.h have names which
> are single token, so all you need to do is to insert entry in the
> symbol table.
I've done an experiment to add such types to my C compiler. It's
slightly tricky because "int" etc are not independent types; they are
special tokens that work together to form a full type spec.
Anyway it involved these additional lines. First in the symbol table
(what is used to initialise the main ST):
("int8", kstdtypesym, ti8),
("int16", kstdtypesym, ti16),
("int32", kstdtypesym, ti32),
("int64", kstdtypesym, ti64),
("uint8", kstdtypesym, tu8),
("uint16", kstdtypesym, tu16),
("uint32", kstdtypesym, tu32),
("uint64", kstdtypesym, tu64),
(I didn't add _t to avoid a clash; this is still a working compiler.)
In the set of tokens:
(kstdtypesym, $, "k", 0),
In the parser, for the code that deals with a typespec:
when kstdtypesym then
d.typeno := lx.subcode
lex()
Then a further 3 lines were modified to add 'kstdtypesym' to a list of
type-starter tokens.
So in all, 12 new lines were added, and 3 lines modified. The extra 16
types of stdint.h would need 16 extra lines in the symbol table. The
types there are hard-coded: the compiler knows its target!
(Some compilers may work with multiple targets, then it would be a
little more elaborate.)
The size of the compiler increased by 38 code bytes, and 238 data bytes
(or 254 if "_t" was used!).
The corresponding portion of stdint.h is 240 bytes, so actually there
isn't much in it. It's just a more professional way of doing this stuff,
and now the types really are part of the core language (support for
suffixes and format codes is still needed).
However adding a feature such as MAXOF(T) definitely would be more
efficient than those dozens of macros, and replaces much of limits.h
too. Unfortunately you can't just add features like this.
>>> I also tried to compile file contaning 100000 declarations
> ^^^^^^
> Oops, should be 1000000.
Yeah, I got that!
>>> like:
>>>
>>> extern int a0(void);
>>> ....
>>> extern int a999999(void);
>>>
>>> Compilation of such file takes 1.737s, so about 575000 lines
>>> per second. So a lot of function declarations in header
>>> files should not slow gcc too much.
>>
>> I get these results (the test file has 'int main(){}' at the end):
>>
>> c:\c>tim gcc fred.c
>> Time: 4.832
>>
>> c:\c>tim tcc fred.c
>> Time: 4.620
>>
>> c:\c>tim bcc fred.c
>> Compiling fred.c to fred.exe
>> Time: 1.324
>>
>> Bear in mind that both gcc/tcc are presumably optimised code; bcc isn't)
>
> On my machine tcc preprocesses probably about 20% faster than gcc.
Given that now tcc has a quite conformant preprocessor (unlike 0.9.26
which was very buggy), I had a theory that many compilers are just
sharing the same one working implementation of it!
A difference of 20% is not significant when gcc is involved; the latter
could be doing all sorts of extra things.
> For timing compilation I used 'gcc -c' to generate linkable object
> file, so no need to have 'main'.
I created EXEs since on bcc there was a tiny bug when generating OBJ
without 'main', which meant I couldn't time it. (I'll deal with that later.)
However if I leave the main() in, then all can generate OBJ files
instead, and the timings are pretty much the same.
> When actually compilning on my
> machine tcc is significantly faster, on the same file 'tcc -c'
> takes 0.418s, so more than 4 times faster than 'gcc -c'.
>
> I do not know why 'tcc' is that much faster.
On mine it's roughly the same as gcc, even a locally built tcc. That was
surprising. I thought it might be a poor hash function, as the 1M names
are very similar. I tried a version with 1M random function names, but
tcc was even slower (7.x seconds); gcc was the same, and bcc was 1.6
seconds.
If this was my product, I would investigate what was slowing it down.
> One possibility
> is that 'gcc' contains various extra info in compiler data
> structures that help when optimizing, but require extra effort
> even when not optimiziong.
My test was with gcc 14.1. gcc 10.3 was about 4 seconds; faster than
tcc! (Yeah, something 'off' there.)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-03-22 17:00 +0000 |
| Message-ID | <vrmqba$933o$3@dont-email.me> |
| In reply to | #391449 |
On 20/03/2025 23:18, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
>> On 20/03/2025 19:10, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
> [...]
>>>> stdint.h et al are just ungainly bolt-ons, not fully supported by the
>>>> language.
>>> No, they're fully supported by the language. They've been in the ISO
>>> standard since 1999.
>>
>> I don't think so. They are add-ons that could have been created in
>> user-code even prior to C99 (user-defined typedefs for 64 bits would
>> 'need long long').
>
> Sure, they could; see Doug Gwyn's q8, for example.
>
>> All that's happened is that 'stdint.h' has been blessed.
>
> I.e., it was made part of the language, specifically the standard
> library that's part of the language standard. Which is what I said,
> but for some reason you disagreed.
>
> Yes, the format specifiers are a bit awkward. Boo hoo.
There's a further problem here:
-------------------------------------
#include <stdio.h>
#include <stdint.h>
#define strtype(x) _Generic((x),\
default: "other",\
char: "char",\
signed char: "signed char",\
short: "short",\
int: "int",\
long: "long",\
long long: "long long",\
unsigned char: "unsigned char",\
unsigned short: "unsigned short",\
unsigned int: "unsigned int",\
unsigned long: "unsigned long",\
unsigned long long: "unsigned long long",\
int8_t: "int8",\
int16_t: "int16",\
int32_t: "int32",\
int64_t: "int64",\
uint8_t: "uint8",\
uint16_t: "uint16",\
uint32_t: "uint32",\
uint64_t: "uint64"\
)
int main(void) {
uint64_t x;
puts(strtype(x));
}
-------------------------------------
Many of the types are aliases of each other. Which ones will be aliases,
can vary by platform.
This is another reason that this was a poor solution.
(My language also has some aliases, but they are defined as such.
The built-in types are the set 'i8 ... u64', with aliases defined on top
such as 'byte' for 'u8', and 'int' for 'i64' on a particular implementation.
This is the opposite of how it works in stdint.h, where specific-width
types are defined on top of non-specific-width ones! It's just backwards.
It also doesn't need _Generic for this purpose; this will work:)
u64 x
puts(x.typestr)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-03-22 15:31 -0700 |
| Message-ID | <87pli88zpq.fsf@nosuchdomain.example.com> |
| In reply to | #391517 |
bart <bc@freeuk.com> writes:
> On 20/03/2025 23:18, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 20/03/2025 19:10, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>> [...]
>>>>> stdint.h et al are just ungainly bolt-ons, not fully supported by the
>>>>> language.
>>>> No, they're fully supported by the language. They've been in the ISO
>>>> standard since 1999.
>>>
>>> I don't think so. They are add-ons that could have been created in
>>> user-code even prior to C99 (user-defined typedefs for 64 bits would
>>> 'need long long').
>> Sure, they could; see Doug Gwyn's q8, for example.
>>
>>> All that's happened is that 'stdint.h' has been blessed.
>> I.e., it was made part of the language, specifically the standard
>> library that's part of the language standard. Which is what I said,
>> but for some reason you disagreed.
>> Yes, the format specifiers are a bit awkward. Boo hoo.
>
> There's a further problem here:
>
> -------------------------------------
> #include <stdio.h>
> #include <stdint.h>
>
> #define strtype(x) _Generic((x),\
> default: "other",\
> char: "char",\
> signed char: "signed char",\
> short: "short",\
> int: "int",\
> long: "long",\
> long long: "long long",\
> unsigned char: "unsigned char",\
> unsigned short: "unsigned short",\
> unsigned int: "unsigned int",\
> unsigned long: "unsigned long",\
> unsigned long long: "unsigned long long",\
> int8_t: "int8",\
> int16_t: "int16",\
> int32_t: "int32",\
> int64_t: "int64",\
> uint8_t: "uint8",\
> uint16_t: "uint16",\
> uint32_t: "uint32",\
> uint64_t: "uint64"\
> )
>
> int main(void) {
> uint64_t x;
>
> puts(strtype(x));
> }
> -------------------------------------
>
> Many of the types are aliases of each other. Which ones will be
> aliases, can vary by platform.
Yes, that's a known problem.
Has it actually inconvenienced you?
[...]
> This is the opposite of how it works in stdint.h, where specific-width
> types are defined on top of non-specific-width ones! It's just
> backwards.
The non-specific-width types have been in the language nearly since
the beginning (K&R1, 1978 had most of them). The C99 committee
decided to add fixed-width types, and <stdint.h> was how they did
it, defining them on top of the existing types (which absolutely
weren't going away). Any solution that you would not consider to be
"backwards" would have been impractical.
I'll note that an implementation *could* define all the typedefs
in <stdint.h> in terms of new extended integer types, which might
solve the _Generic problem above *for that implementation*. For that
matter, C99 could have required it. The committee and implementers
likely didn't think of it at the time, or didn't think it was
worth the added complication to the language. (As far as I know,
no implementations have implemented any extended integer types;
gcc's __int128 doesn't qualify.)
Or, rather than typedefs, they could have defined new language syntax
that would allow things like uint8_t to be specified -- but any such
syntax would be either excessively verbose or excessively terse,
and programmers would inevitably define their own typedefs.
With the solution they chose, the new types could be defined just
in the library, with no changes to the compiler.
In any case, I suggest that fixed-width types are not as fundamental
as you seem to think they are. They're useful when you need to
conform to an externally defined interface, but if I'm writing
FizzBuzz, for example, I don't care what the upper bound of an
integer type is a long as it's at least 101.
[...]
--
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 | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-03-21 17:51 +0000 |
| Message-ID | <vrk8vm$2f4gc$1@paganini.bofh.team> |
| In reply to | #391401 |
bart <bc@freeuk.com> wrote:
> On 20/03/2025 13:36, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 20/03/2025 12:09, Tim Rentsch wrote:
>>>> Michael S <already5chosen@yahoo.com> writes:
>>>
>>>>> I suspected that, but was not sure, so suggested to DFS a type that I am
>>>>> sure about.
>>>>
>>>> The width of char and [un]signed char must be at least 8 bits.
>>>> The width of [un]signed short must be at least 16 bits.
>>>> The width of [un]signed int must be at least 16 bits.
>>>> The width of [un]signed long must be at least 32 bits.
>>>> The width of [un]signed long long must be at least 64 bits.
>>>>
>>>> That should be easy enough to remember now.
>>>
>>> That table suggests that any program mixing 'short' and 'int' is
>>> suspect. If 'int' doesn't need to store values beyond 16 bits, then why
>>> not use 'short'?
>>>
>>> 'long' is another troublesome one. If the need is for 32-bit values,
>>> then it's surprisingly rare in source code.
>>
>> Long is useless, because Microsoft made the mistake of defining
>> 'long' as 32-bits on 64-bit architectures, while unix and linux
>> define it as 64-bits.
>
> Unix and Linux define it as 32 bits on 32-bit architectures and 64 bits
> on 64-bit ones.
>
>> So long can't be used in programs intended to be portable to
>> other operating systems.
>
> As defined by Unix/Linux, long is not portable between different
> Unix/Linux OSes if they run on a different architecture.
It portably between 32 and 64 bit machines gives word-sized
integer type.
> As defined by Microsoft, long is portable between Windows OSes even on
> different architectures.
It gives 'long' different meaning than it had previously. And to
that matters rather useless meaning, as already 'int' gives 32
bit integers on bigger machines.
> 'long long' is defined as a 64-bit
>> type in both Windows and Linux.
>>
>> Using the defined width types is far better (e.g. uint64_t);
>> even if the standard allows the type to not exist on a particular
>> implementation. No useful implementation would fail to define
>> uint64_t in these modern times.
>
<snip>
> The problem with 'long' manifests itself there too, since on Linux,
> 'int64_t' appears to be commonly defined on top of 'long' for 32-bit
> systems, and 'long long' for 64-bit ones.
You mixed up this: 'int64_t' is defined as 'long long' for 32-bit
systems and as 'long' for 64-bit ones. Doing it as you wrote
would give you variable length type. Of course, if you need
word-sized integer in Windows you may define it as 'long' for 32-bit
Windows and as 'long long' for 64-bit ones.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-03-21 18:51 +0000 |
| Message-ID | <20250321113316.506@kylheku.com> |
| In reply to | #391477 |
On 2025-03-21, Waldek Hebisch <antispam@fricas.org> wrote: > bart <bc@freeuk.com> wrote: >> On 20/03/2025 13:36, Scott Lurndal wrote: >>> bart <bc@freeuk.com> writes: >>>> On 20/03/2025 12:09, Tim Rentsch wrote: >>>>> Michael S <already5chosen@yahoo.com> writes: >>>> >>>>>> I suspected that, but was not sure, so suggested to DFS a type that I am >>>>>> sure about. >>>>> >>>>> The width of char and [un]signed char must be at least 8 bits. >>>>> The width of [un]signed short must be at least 16 bits. >>>>> The width of [un]signed int must be at least 16 bits. >>>>> The width of [un]signed long must be at least 32 bits. >>>>> The width of [un]signed long long must be at least 64 bits. >>>>> >>>>> That should be easy enough to remember now. >>>> >>>> That table suggests that any program mixing 'short' and 'int' is >>>> suspect. If 'int' doesn't need to store values beyond 16 bits, then why >>>> not use 'short'? >>>> >>>> 'long' is another troublesome one. If the need is for 32-bit values, >>>> then it's surprisingly rare in source code. >>> >>> Long is useless, because Microsoft made the mistake of defining >>> 'long' as 32-bits on 64-bit architectures, while unix and linux >>> define it as 64-bits. >> >> Unix and Linux define it as 32 bits on 32-bit architectures and 64 bits >> on 64-bit ones. >> >>> So long can't be used in programs intended to be portable to >>> other operating systems. >> >> As defined by Unix/Linux, long is not portable between different >> Unix/Linux OSes if they run on a different architecture. > > It portably between 32 and 64 bit machines gives word-sized > integer type. The bitness of modern mainstream machines is their address size. C99 gaves us address-sized integers: intptr_t and uintptr_t. If you want a 64 bit type on a 64 bit system and 32 bit type on a 32 bit system, use those. (The problem is that idea observed in Unix-like environments that long is expected to be address-sized precedes C99.) >> As defined by Microsoft, long is portable between Windows OSes even on >> different architectures. > > It gives 'long' different meaning than it had previously. And to > that matters rather useless meaning, as already 'int' gives 32 > bit integers on bigger machines. In Microsoft land, there is a LONG type, which is involved in the Win32 ABIs. That was their mistake. In plenty of interfaces, Windows uses the types WORD and DWORD, which are 16 and 32 bits wide unsigned types. (As well as QWORD, a 64 bitter). The problem is, when someone needed the signed versions of WORD and DWORD, they found them to be missing, and stupidly came up with the names INT and LONG (and derived typedefs like LPARAM). Nobody caught this code smell and so it got woven into the Windows API. Probably long before 32 bit Windows, I'm guessing. Thus, LONG has to continue to be a 32 bit type, since it is used as a "signed DWORD". But it's inconceivable for LONG to to be a typedef for anything other than long. Too much code depends on the wrong idea that LONG and long are interchangeable. Thus long has to be stuck on 32 bits. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-03-22 02:16 +0000 |
| Message-ID | <vrl6hp$2qg20$1@dont-email.me> |
| In reply to | #391478 |
On 21/03/2025 18:51, Kaz Kylheku wrote:
> On 2025-03-21, Waldek Hebisch <antispam@fricas.org> wrote:
>> bart <bc@freeuk.com> wrote:
>>> On 20/03/2025 13:36, Scott Lurndal wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 20/03/2025 12:09, Tim Rentsch wrote:
>>>>>> Michael S <already5chosen@yahoo.com> writes:
>>>>>
>>>>>>> I suspected that, but was not sure, so suggested to DFS a type that I am
>>>>>>> sure about.
>>>>>>
>>>>>> The width of char and [un]signed char must be at least 8 bits.
>>>>>> The width of [un]signed short must be at least 16 bits.
>>>>>> The width of [un]signed int must be at least 16 bits.
>>>>>> The width of [un]signed long must be at least 32 bits.
>>>>>> The width of [un]signed long long must be at least 64 bits.
>>>>>>
>>>>>> That should be easy enough to remember now.
>>>>>
>>>>> That table suggests that any program mixing 'short' and 'int' is
>>>>> suspect. If 'int' doesn't need to store values beyond 16 bits, then why
>>>>> not use 'short'?
>>>>>
>>>>> 'long' is another troublesome one. If the need is for 32-bit values,
>>>>> then it's surprisingly rare in source code.
>>>>
>>>> Long is useless, because Microsoft made the mistake of defining
>>>> 'long' as 32-bits on 64-bit architectures, while unix and linux
>>>> define it as 64-bits.
>>>
>>> Unix and Linux define it as 32 bits on 32-bit architectures and 64 bits
>>> on 64-bit ones.
>>>
>>>> So long can't be used in programs intended to be portable to
>>>> other operating systems.
>>>
>>> As defined by Unix/Linux, long is not portable between different
>>> Unix/Linux OSes if they run on a different architecture.
>>
>> It portably between 32 and 64 bit machines gives word-sized
>> integer type.
>
> The bitness of modern mainstream machines is their address size.
>
> C99 gaves us address-sized integers: intptr_t and uintptr_t.
> If you want a 64 bit type on a 64 bit system and 32 bit type
> on a 32 bit system, use those.
>
> (The problem is that idea observed in Unix-like environments that long
> is expected to be address-sized precedes C99.)
>
>>> As defined by Microsoft, long is portable between Windows OSes even on
>>> different architectures.
>>
>> It gives 'long' different meaning than it had previously. And to
>> that matters rather useless meaning, as already 'int' gives 32
>> bit integers on bigger machines.
>
> In Microsoft land, there is a LONG type, which is involved in
> the Win32 ABIs. That was their mistake.
>
> In plenty of interfaces, Windows uses the types WORD and DWORD, which
> are 16 and 32 bits wide unsigned types. (As well as QWORD,
> a 64 bitter).
Those types are an invention of Microsoft and only appear in WinAPIs.
There seem to be hundreds of them, but they are well defined. Mostly
they are consistent between 32- and 64-bit systems too.
Since I've mostly used WinAPI via an FFI, I'm used to creating my own
bindings and using my own aliases for this ttypes. (Mostly it comes down
to one of i32 i64 u32 u64 plus a pointer type.)
> The problem is, when someone needed the signed versions of
> WORD and DWORD, they found them to be missing, and stupidly came up with
> the names INT and LONG (and derived typedefs like LPARAM).
> Nobody caught this code smell and so it got woven into the Windows API.
> Probably long before 32 bit Windows, I'm guessing.
>
> Thus, LONG has to continue to be a 32 bit type, since it is
> used as a "signed DWORD".
>
> But it's inconceivable for LONG to to be a typedef for anything other
> than long. Too much code depends on the wrong idea that LONG and long
> are interchangeable.
>
> Thus long has to be stuck on 32 bits.
There really isn't much in it. Here's the evolution as I see it (I stand
to be corrected if necessary):
C-Windows C-Linux My stuff
Machine int long int long int 'dint'
16 bits 16 32 16 32 16 32
32 bits 32 32 32 32 32 64
64 bits 32 32 32 64 64 [128]
The most logical and consistent progression seems to be with 'my
stuff'!Except I no longer support 128-bit types after doing so briefly.
The point is that there was usually a size exactly double the width of
'int', but it become less necessary when 'int' reached 64 bits.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-03-22 04:15 +0000 |
| Message-ID | <20250321210228.508@kylheku.com> |
| In reply to | #391488 |
On 2025-03-22, bart <bc@freeuk.com> wrote: > Since I've mostly used WinAPI via an FFI, I'm used to creating my own > bindings and using my own aliases for this ttypes. (Mostly it comes down > to one of i32 i64 u32 u64 plus a pointer type.) When I FFI to Windows, I tend to be a stickler for using names that are exactly the same, wherever possible. I have DWORD, HWND, and whatnot. You can see it in this code; it is self-contained. It defines all the symbols it needs, and requires just the DLLs: https://rosettacode.org/wiki/Window_creation#Win32/Win64 >> Thus long has to be stuck on 32 bits. > > There really isn't much in it. Here's the evolution as I see it (I stand > to be corrected if necessary): There isn't much in it, but it doesn't take much in order to pin things down and prevent change. > The point is that there was usually a size exactly double the width of > 'int', but it become less necessary when 'int' reached 64 bits. Yes, because other than for masks of 128 bits, there isn't a whole lot of stuff you can *count* for which you need such large integers. Money? In an accounting system, if you use signed 64 bits for pennies, you can go to 9.2 x 10^16 dollars. Large integers are needed for crypto and such, but then 128 isn't enough anyway. Obviously, IPv4 addresses are 128. In protocol stacks, switching and routing, it could be useful to have 128 bit operations on them for masking and comparing and whatnot. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-03-21 21:24 -0700 |
| Message-ID | <878qoxae0a.fsf@nosuchdomain.example.com> |
| In reply to | #391492 |
Kaz Kylheku <643-408-1753@kylheku.com> writes:
[...]
> Obviously, IPv4 addresses are 128. In protocol stacks, switching and
> routing, it could be useful to have 128 bit operations on them for
> masking and comparing and whatnot.
Off-by-two error. IPv4 addresses are 32 bits. You're thinking of IPv6
addresses.
--
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 | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-03-22 14:07 +0000 |
| Message-ID | <vrmg7d$2nif7$2@paganini.bofh.team> |
| In reply to | #391492 |
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> On 2025-03-22, bart <bc@freeuk.com> wrote:
>
>> The point is that there was usually a size exactly double the width of
>> 'int', but it become less necessary when 'int' reached 64 bits.
>
> Yes, because other than for masks of 128 bits, there isn't a whole
> lot of stuff you can *count* for which you need such large integers.
>
> Money?
>
> In an accounting system, if you use signed 64 bits for pennies, you can
> go to 9.2 x 10^16 dollars.
Actually, to do fast division of N-bit number by fixed N-bit number
one need 2N-bit multiplication. Such divisions appear in base
convertions (to decimal) and when doing "decimal" rounding.
Also, converting between currencies needs extra accuracy. So
_fast_ financial arithmetic may need rather large number of digits,
current tendecy is to allow up to 37 digits in intermediate quantities.
Note that 64-bit _result_ type means that 32-bit integers are
largest that can be multiplied exactly, that is very limiting.
> Large integers are needed for crypto and such, but then 128 isn't enough
> anyway.
Double word arthmetic is crucial if you want efficient high-level
implementation of multiple precision arithmetic. So, 64-bit is
enough on 32-bit machines, 128-bit is needed on 64-bit machines
and hypotetical 128-bit machines would need 256-bit integer
type as a building block for efficient multiple precision
arithmetic.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-03-26 02:04 +0100 |
| Subject | Fast division (was Re: Suggested method for returning a string from a C program?) |
| Message-ID | <vrvjr9$i7gg$1@dont-email.me> |
| In reply to | #391503 |
On 22.03.2025 15:07, Waldek Hebisch wrote: > > Actually, to do fast division of N-bit number by fixed N-bit number > one need 2N-bit multiplication. I just stumbled across your post and above sentence. Do you mean *one* multiplication of 2N bit numbers? - Could you please explain that (by an example, or could you provide a reference)? (The reason for my question is that for integer divisions of length N an old DSP I used required besides shifts effectively N subtractions to create the result and modulus; it didn't use any multiplications.) Janis
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-03-25 22:35 -0400 |
| Subject | Re: Fast division (was Re: Suggested method for returning a string from a C program?) |
| Message-ID | <vrvp60$m53l$1@dont-email.me> |
| In reply to | #391648 |
On 3/25/25 21:04, Janis Papanagnou wrote: > On 22.03.2025 15:07, Waldek Hebisch wrote: >> >> Actually, to do fast division of N-bit number by fixed N-bit number >> one need 2N-bit multiplication. > > I just stumbled across your post and above sentence. Do you mean *one* > multiplication of 2N bit numbers? I think he meant "one needs 2N-bit multiplication". "one" is a pronoun in this context, not a number.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-03-26 12:40 +0100 |
| Subject | Re: Fast division (was Re: Suggested method for returning a string from a C program?) |
| Message-ID | <vs0p2o$1look$1@dont-email.me> |
| In reply to | #391649 |
On 26/03/2025 03:35, James Kuyper wrote: > On 3/25/25 21:04, Janis Papanagnou wrote: >> On 22.03.2025 15:07, Waldek Hebisch wrote: >>> >>> Actually, to do fast division of N-bit number by fixed N-bit number >>> one need 2N-bit multiplication. >> >> I just stumbled across your post and above sentence. Do you mean *one* >> multiplication of 2N bit numbers? > I think he meant "one needs 2N-bit multiplication". "one" is a pronoun > in this context, not a number. While that is probably correct, coincidentally it is also just /one/ multiplication. Roughly speaking, when you want division of "y" by a fixed - i.e., constant value known at compile time - number "x", you can do it by pre-calculating z = 2^n / x and then you implement "y / x" by "y * z / 2^n". (There's also some stuff to handle correct rounding, especially with signed types.) So that is one use of multiplications that need longer bit-lengths, beyond the size of the numbers you actually want to count (pennies or whatever).
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-03-26 14:47 +0100 |
| Subject | Re: Fast division (was Re: Suggested method for returning a string from a C program?) |
| Message-ID | <vs10go$1sing$1@dont-email.me> |
| In reply to | #391667 |
On 26.03.2025 12:40, David Brown wrote: >>> >>> [ substituting a division by multiplication (and some primitives) ] > > Roughly speaking, when you want division of "y" by a fixed - i.e., > constant value known at compile time - number "x", you can do it by > pre-calculating z = 2^n / x and then you implement "y / x" by "y * z / > 2^n". (There's also some stuff to handle correct rounding, especially > with signed types.) Thanks for the terse explanation; the formulas helped me to detect that the constants in Waldek's assembler code are the pre-computed reciprocals. First I thought that there's a trick to avoid division of non-const expressions. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-03-26 17:55 +0100 |
| Subject | Re: Fast division (was Re: Suggested method for returning a string from a C program?) |
| Message-ID | <vs1bhh$24nub$6@dont-email.me> |
| In reply to | #391672 |
On 26/03/2025 14:47, Janis Papanagnou wrote: > On 26.03.2025 12:40, David Brown wrote: >>>> >>>> [ substituting a division by multiplication (and some primitives) ] >> >> Roughly speaking, when you want division of "y" by a fixed - i.e., >> constant value known at compile time - number "x", you can do it by >> pre-calculating z = 2^n / x and then you implement "y / x" by "y * z / >> 2^n". (There's also some stuff to handle correct rounding, especially >> with signed types.) > > Thanks for the terse explanation; the formulas helped me to detect > that the constants in Waldek's assembler code are the pre-computed > reciprocals. > > First I thought that there's a trick to avoid division of non-const > expressions. > For non-constant divisors, it's a bit more difficult! If you are going to use the same divisor several times, it can be worth computing the scaled reciprocal, so that you only have one hard operation. I believe that hardware floating point units do that anyway for division.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-26 19:36 +0200 |
| Subject | Re: Fast division (was Re: Suggested method for returning a string from a C program?) |
| Message-ID | <20250326193657.000040b6@yahoo.com> |
| In reply to | #391667 |
On Wed, 26 Mar 2025 12:40:08 +0100 David Brown <david.brown@hesbynett.no> wrote: > On 26/03/2025 03:35, James Kuyper wrote: > > On 3/25/25 21:04, Janis Papanagnou wrote: > >> On 22.03.2025 15:07, Waldek Hebisch wrote: > >>> > >>> Actually, to do fast division of N-bit number by fixed N-bit > >>> number one need 2N-bit multiplication. > >> > >> I just stumbled across your post and above sentence. Do you mean > >> *one* multiplication of 2N bit numbers? > > I think he meant "one needs 2N-bit multiplication". "one" is a > > pronoun in this context, not a number. > > While that is probably correct, coincidentally it is also just /one/ > multiplication. > > Roughly speaking, when you want division of "y" by a fixed - i.e., > constant value known at compile time - number "x", you can do it by > pre-calculating z = 2^n / x and then you implement "y / x" by "y * z > / 2^n". (There's also some stuff to handle correct rounding, > especially with signed types.) > > So that is one use of multiplications that need longer bit-lengths, > beyond the size of the numbers you actually want to count (pennies or > whatever). > Strictly speaking, n-bit reciprocal is insufficient for arbitrary n-bit [unsigned] integer division. For approximately 10% of divisors one needs either n+1 bits of reciprocal or an adjustment step after multiplication. In cases like those compilers that implement division by constant via multiplication by reciprocal are emulating multiplication by (n+1)-bit reciprocal via multiplication by n-bit number followed by ether subtraction or addition and shifts.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-03-26 13:44 +0000 |
| Subject | Re: Fast division (was Re: Suggested method for returning a string from a C program?) |
| Message-ID | <vs10cd$3rsg0$1@paganini.bofh.team> |
| In reply to | #391649 |
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 3/25/25 21:04, Janis Papanagnou wrote:
>> On 22.03.2025 15:07, Waldek Hebisch wrote:
>>>
>>> Actually, to do fast division of N-bit number by fixed N-bit number
>>> one need 2N-bit multiplication.
>>
>> I just stumbled across your post and above sentence. Do you mean *one*
>> multiplication of 2N bit numbers?
> I think he meant "one needs 2N-bit multiplication". "one" is a pronoun
> in this context, not a number.
Yes, of course "one" in my text above is a pronoun. I do not know
how Janis guessed one multiplication, but it is correct guess.
There is also Newton method which uses multiple multiplications,
but but it is less useful for software at moderate precision
and it is _not_ what I meant.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
Page 17 of 22 — ← Prev page 1 … 15 16 [17] 18 19 … 22 Next page →
Back to top | Article view | comp.lang.c
csiph-web