Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #385836 > unrolled thread
| Started by | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| First post | 2024-06-11 10:13 +0100 |
| Last post | 2024-06-11 18:21 +0000 |
| Articles | 20 on this page of 351 — 23 participants |
Back to article view | Back to comp.lang.c
Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 10:13 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-11 13:59 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 14:35 +0100
Mac users (Was: Baby X is bor nagain) gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-12 10:04 +0000
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-11 15:16 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 15:35 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-12 00:34 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 00:50 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-11 18:02 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 17:15 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 07:40 +0200
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-12 09:01 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 10:51 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-12 15:20 +0200
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 13:07 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-12 12:27 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 14:35 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-12 14:13 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 15:43 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-12 14:52 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-12 15:46 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-13 00:29 +0300
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 23:22 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-13 13:53 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-13 14:46 +0100
Re: Baby X is bor nagain tTh <tth@none.invalid> - 2024-06-13 17:11 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-13 16:32 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-14 08:47 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-13 19:13 +0300
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-13 17:43 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-14 18:43 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-14 19:24 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-15 12:35 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 02:22 -0400
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-17 07:30 +0000
Are Javascript and Python similarly slow ? (Was: Baby X is bor nagain) Michael S <already5chosen@yahoo.com> - 2024-06-17 12:11 +0300
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-17 12:25 +0300
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 10:54 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 15:23 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-18 11:56 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 14:36 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 14:48 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 18:11 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 17:38 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 18:54 +0200
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-18 14:14 -0400
Re: Baby X is bor nagain Mark Bourne <nntp.mbourne@spamgourmet.com> - 2024-06-18 20:52 +0100
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-18 16:07 -0400
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 15:30 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 18:15 +0200
Re: Baby X is bor nagain Mark Bourne <nntp.mbourne@spamgourmet.com> - 2024-06-18 21:09 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-18 18:40 +0300
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 17:39 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 15:49 -0700
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 10:25 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 12:42 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 17:52 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 19:49 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 21:42 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-19 22:51 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 12:34 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 14:37 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 17:07 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 17:58 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-20 20:28 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 20:11 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 22:16 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 23:40 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 10:02 +0200
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 09:55 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-20 09:37 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 13:18 +0200
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-20 12:24 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-20 13:36 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-20 22:26 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-20 08:05 -0700
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-20 17:56 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-20 17:45 +0000
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-20 13:55 -0400
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-20 19:01 +0000
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 13:41 -0700
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:34 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 13:44 -0700
Re: Baby X is bor nagain vallor <vallor@cultnix.org> - 2024-06-20 22:21 +0000
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-20 22:34 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 11:19 +0200
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 13:37 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-20 22:39 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-21 00:56 +0300
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-21 22:07 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 14:57 -0700
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-20 20:59 -0400
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 18:42 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-21 21:10 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 12:19 +0100
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-23 10:30 -0400
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-23 11:04 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 23:33 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 03:28 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-25 01:35 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-25 05:38 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-23 16:33 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 07:40 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-24 14:25 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-23 09:47 -0700
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-23 19:55 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 09:34 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 23:30 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 01:53 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-25 01:30 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-26 12:59 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-26 23:46 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-26 17:48 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-19 13:23 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 07:44 +0200
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-19 02:27 -0700
sort - C, python, C++, glibc Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-19 13:17 +0300
Re: sort - C, python, C++, glibc Was: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 12:53 +0200
Re: sort - C, python, C++, glibc Was: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 18:42 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 07:39 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 03:26 -0400
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:13 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-17 11:30 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 15:43 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 16:48 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 18:21 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 20:17 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 21:29 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 22:06 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 08:44 +0200
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:21 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 11:46 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 11:42 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 15:34 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 22:47 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-23 14:25 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-23 19:21 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-23 22:09 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-24 00:52 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 01:25 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 00:56 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 10:28 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 12:17 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 13:46 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 14:01 +0100
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-26 11:54 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 10:16 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-24 16:09 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 15:00 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 17:09 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 17:19 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 19:15 +0200
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 17:25 +0000
Re: Baby X is bor nagain "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-25 20:29 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 22:15 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 21:34 +0000
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 22:03 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 10:19 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 12:18 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 17:08 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-26 00:28 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:17 +0200
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-25 12:52 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 20:39 +0100
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-25 16:28 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-26 00:23 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-25 13:13 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:23 +0200
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-26 15:18 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-27 15:45 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-25 12:04 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:21 +0200
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-26 08:31 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-25 13:15 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 12:56 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-24 18:10 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 17:51 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 17:02 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 18:50 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 18:10 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 20:33 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-25 11:36 +0300
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 13:48 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 15:56 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 15:08 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 17:12 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 16:59 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 16:27 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 19:51 +0200
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 18:11 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-26 00:42 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:35 +0200
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-26 13:15 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 12:16 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-27 15:24 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 14:13 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-27 14:31 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 17:28 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-27 21:51 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 22:47 +0100
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-28 03:23 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:19 +0100
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-28 10:26 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 15:14 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-29 08:38 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 17:11 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 19:42 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-29 21:49 +0300
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-29 15:43 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-30 01:43 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 11:23 +0200
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-30 00:36 +0000
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-03 17:12 -0400
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-30 01:49 -0700
Re: Baby X is bor nagain Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-29 18:46 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 20:55 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-30 12:18 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 17:54 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-30 19:10 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-01 00:20 +0200
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-08 19:48 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-29 16:23 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 10:47 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 12:11 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 11:05 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-30 11:48 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 17:47 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-01 12:22 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-01 13:09 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-01 15:14 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 14:20 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 16:00 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-02 16:44 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-03 00:58 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-03 01:23 +0100
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-03 00:47 +0000
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-03 01:18 +0000
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-03 01:54 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-03 09:08 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-03 10:36 +0100
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-07-03 09:41 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-03 17:58 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 21:33 +0300
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-04 09:14 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-03 22:58 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-04 10:24 +0200
Re: Baby X is bor nagain DFS <guhnoo-basher@linux.advocaca> - 2025-01-02 13:16 -0500
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2025-01-02 20:46 +0000
Re: Baby X is bor nagain Phillip <nntp@fulltermprivacy.com> - 2025-01-02 16:47 -0500
Re: Baby X is bor nagain antispam@fricas.org (Waldek Hebisch) - 2025-01-02 22:22 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2025-01-03 13:48 +0100
Re: Baby X is bor nagain DFS <guhnoo-basher@linux.advocaca> - 2025-01-03 12:04 -0500
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2025-01-03 18:12 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-04 10:18 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-03 11:23 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-03 13:13 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-28 06:56 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 11:20 +0300
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 13:52 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 11:05 +0200
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-29 09:15 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 19:11 +0200
Re: Baby X is bor nagain Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-29 18:51 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-29 21:56 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 11:17 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:05 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-28 06:57 +0200
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 13:23 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-27 15:44 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 17:50 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 00:16 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-27 23:58 +0000
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 18:21 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:15 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 13:53 +0000
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 18:08 -0700
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-28 03:30 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 11:11 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:41 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 13:48 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 15:36 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 15:48 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 20:37 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 15:42 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 16:01 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 19:45 +0300
tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-01 20:09 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-01 12:14 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 14:48 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 15:09 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 11:54 +0300
Re: tcc - first impression. Was: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-02 12:22 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 16:27 +0300
Re: tcc - first impression. Was: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-02 15:18 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 17:55 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 13:57 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-02 06:50 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-02 06:47 -0700
Re: tcc - first impression. Was: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-02 11:50 -0400
Re: tcc - first impression. Was: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-02 10:35 +0100
Re: tcc - first impression. Was: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-07-02 14:33 +0000
Re: tcc - first impression. Was: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 15:43 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 18:17 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 16:32 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 18:45 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 17:12 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 00:42 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-04 00:04 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 21:07 +0300
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-27 23:24 +0100
Re: Baby X is bor nagain Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-28 00:44 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-24 20:41 +0300
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 19:39 +0300
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-26 11:31 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 16:43 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-17 22:01 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 09:01 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 19:52 -0400
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 11:26 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-17 20:24 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 14:40 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 14:55 +0100
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 09:39 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 14:58 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-18 14:33 +0000
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 13:02 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 19:06 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 11:07 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 19:22 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 16:34 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 10:05 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-19 11:52 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 19:53 +0200
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:31 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 12:46 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 14:25 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 15:51 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 19:43 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-23 14:56 +0200
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-23 15:22 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 22:05 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-23 15:11 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 14:09 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 18:38 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 03:28 -0400
Topicality is not your strong suit (Was: Baby X is bor nagain) gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-12 09:40 +0000
Re: Topicality is not your strong suit (Was: Baby X is bor nagain) Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 12:59 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-11 18:09 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-11 20:22 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-11 20:31 +0100
Re: Baby X is bor nagain kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-06-11 18:21 +0000
Page 5 of 18 — ← Prev page 1 … 3 4 [5] 6 7 … 18 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-20 13:41 -0700 |
| Message-ID | <87zfrfwdmt.fsf@nosuchdomain.example.com> |
| In reply to | #386279 |
scott@slp53.sl.home (Scott Lurndal) writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>On 6/20/24 13:45, Scott Lurndal wrote:
>>> Spaces have no place in filenames.
>>
>>Unix-like OSs and Windows both allow them, and they are used frequently.
>
> True, yet the point stands.
I share you dislike of spaces in filenames, but any code that ignores
them is practically broken.
--
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 | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2024-06-20 21:34 +0100 |
| Message-ID | <v523nr$2nli8$5@dont-email.me> |
| In reply to | #386277 |
On 20/06/2024 18:45, Scott Lurndal wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> Incidentally you might like the default sort in my ls command, now in >> the Baby X FileSystem shell. There's also a separate programs that runs >> under the native shell - of course I developed the command on native >> host filesystems first. It uses a natural sort so that "Chapter 10" >> sorts after and not before "Chapter 2". > > Spaces have no place in filenames. > > chapter02 sorts efore chapter10 naturally. What do you do when you write Chapter101? Andy
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-20 13:44 -0700 |
| Message-ID | <87v823wdhw.fsf@nosuchdomain.example.com> |
| In reply to | #386274 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> And I see that using Python's getkey() function to swap "_D" and "_H"
> would be a way to solve this. But it's far from obvious how to set up
> a custom sort.
And you still think comp.lang.c is the place to talk about it?
If the links I already posted aren't sufficiently helpful (I expected
they would be), comp.lang.python exists and is reasonably active.
> Incidentally you might like the default sort in my ls command, now in
> the Baby X FileSystem shell. There's also a separate programs that
> runs under the native shell - of course I developed the command on
> native host filesystems first. It uses a natural sort so that "Chapter
> 10" sorts after and not before "Chapter 2".
GNU coreutils ls has a "-v" or "--sort=version" option that does this.
--
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 | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2024-06-20 22:21 +0000 |
| Message-ID | <v52a1f$2lkuv$5@dont-email.me> |
| In reply to | #386289 |
On Thu, 20 Jun 2024 13:44:27 -0700, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote in <87v823wdhw.fsf@nosuchdomain.example.com>: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > [...] >> And I see that using Python's getkey() function to swap "_D" and "_H" >> would be a way to solve this. But it's far from obvious how to set up a >> custom sort. > > And you still think comp.lang.c is the place to talk about it? > > If the links I already posted aren't sufficiently helpful (I expected > they would be), comp.lang.python exists and is reasonably active. > >> Incidentally you might like the default sort in my ls command, now in >> the Baby X FileSystem shell. There's also a separate programs that runs >> under the native shell - of course I developed the command on native >> host filesystems first. It uses a natural sort so that "Chapter 10" >> sorts after and not before "Chapter 2". > > GNU coreutils ls has a "-v" or "--sort=version" option that does this. I just posted a python program to comp.lang.python that uses glibc's strverscmp(3) to sort input parameters. There is also a separate thread in comp.unix.shell where this has come up. -- -v
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-20 22:34 -0700 |
| Message-ID | <86tthmhnat.fsf@linuxsc.com> |
| In reply to | #386274 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On 20/06/2024 16:05, Tim Rentsch wrote: > [.. on qsort compare function ..] >> My reading of the C standard is that the comparison function >> must impose a total ordering on the elements actually present >> in the array, or is undefined behavior if it does not. In >> other words it's okay if the comparison function doesn't >> define a proper order relation, as long as there are no >> inconsistencies between values that actually occur in the >> particular array being sorted. > > Yes, a qsort written in the natural way can getstuck if a > sub0array it considered sorted becmes not sortted on the next > pass. Not get stuck. The array might not be sorted correctly, but the algorithm doesn't get stuck.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-21 11:19 +0200 |
| Message-ID | <v53gie$33k73$1@dont-email.me> |
| In reply to | #386274 |
On 20/06/2024 18:56, Malcolm McLean wrote: > Yes, a qsort written in the natural way can getstuck if a sub0array it > considered sorted becmes not sortted on the next pass. I have no idea what you might think of as the "natural" way to implement qsort. But if it were, as the name implies, a quicksort, then it would not get stuck. At each step, progress is always made - even with a comparison function that gave random values, you'd still have a worst case complexity of O(n²). The only sorting algorithm I can think of that might get stuck with a slightly broken comparison function would be a poor bubblesort implementation that is run over the whole array every round, simply repeating until no changes are made in a round.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-20 13:37 -0700 |
| Message-ID | <874j9nxsdy.fsf@nosuchdomain.example.com> |
| In reply to | #386263 |
Ben Bacarisse <ben@bsb.me.uk> writes:
[...]
> On a C language point, I don't think the standard says anything about
> sorting with non-order functions like the one above. Is an
> implementation of qsort permitted to misbehave (for example by not
> terminating) when the comparison function does not implement a proper
> order relation?
N1570 7.22.5p4 (applies to bsearch and qsort):
"""
When the same objects (consisting of size bytes, irrespective of
their current positions in the array) are passed more than once to
the comparison function, the results shall be consistent with one
another. That is, for qsort they shall define a total ordering on
the array, and for bsearch the same object shall always compare
the same way with the key.
"""
That's a "shall" outside a constraint, so violating it results in
undefined behavior.
N3220 7.24.5 has the same wording.
--
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 | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-06-20 22:39 +0100 |
| Message-ID | <874j9ns382.fsf@bsb.me.uk> |
| In reply to | #386287 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Ben Bacarisse <ben@bsb.me.uk> writes: > [...] >> On a C language point, I don't think the standard says anything about >> sorting with non-order functions like the one above. Is an >> implementation of qsort permitted to misbehave (for example by not >> terminating) when the comparison function does not implement a proper >> order relation? > > N1570 7.22.5p4 (applies to bsearch and qsort): > """ > When the same objects (consisting of size bytes, irrespective of > their current positions in the array) are passed more than once to > the comparison function, the results shall be consistent with one > another. That is, for qsort they shall define a total ordering on > the array, and for bsearch the same object shall always compare > the same way with the key. > """ > > That's a "shall" outside a constraint, so violating it results in > undefined behavior. I think it should be clearer. What the "that is" phrase seems to clarify in no way implies a total order, merely that the repeated comparisons or the same elements are consistent with one another. That the comparison function defines a total order on the elements is, to me, a major extra constraint that should not be written as an apparent clarification to something the does not imply it: repeated calls should be consistent with one another and, in addition, a total order should be imposed on the elements present. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-06-21 00:56 +0300 |
| Message-ID | <20240621005605.00005f90@yahoo.com> |
| In reply to | #386292 |
On Thu, 20 Jun 2024 22:39:57 +0100 Ben Bacarisse <ben@bsb.me.uk> wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > > > Ben Bacarisse <ben@bsb.me.uk> writes: > > [...] > >> On a C language point, I don't think the standard says anything > >> about sorting with non-order functions like the one above. Is an > >> implementation of qsort permitted to misbehave (for example by not > >> terminating) when the comparison function does not implement a > >> proper order relation? > > > > N1570 7.22.5p4 (applies to bsearch and qsort): > > """ > > When the same objects (consisting of size bytes, irrespective of > > their current positions in the array) are passed more than once to > > the comparison function, the results shall be consistent with one > > another. That is, for qsort they shall define a total ordering on > > the array, and for bsearch the same object shall always compare > > the same way with the key. > > """ > > > > That's a "shall" outside a constraint, so violating it results in > > undefined behavior. > > I think it should be clearer. What the "that is" phrase seems to > clarify in no way implies a total order, merely that the repeated > comparisons or the same elements are consistent with one another. > That the comparison function defines a total order on the elements > is, to me, a major extra constraint that should not be written as an > apparent clarification to something the does not imply it: repeated > calls should be consistent with one another and, in addition, a total > order should be imposed on the elements present. > Malcolm's comparison function does not establish total order on arbitrary strings, but it is both possible and likely that it establishes total order on all sets of inputs that he cares about.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-06-21 22:07 +0100 |
| Message-ID | <87iky2qa1w.fsf@bsb.me.uk> |
| In reply to | #386293 |
Michael S <already5chosen@yahoo.com> writes:
> Malcolm's comparison function does not establish total order on
> arbitrary strings, but it is both possible and likely that it
> establishes total order on all sets of inputs that he cares about.
Yes, I think he said as much. The trouble is, the problem was posted as
something of a challenge ("nobody posted any code" or similar) but we
knew neither the possible inputs nor the desired ordering!
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-20 14:57 -0700 |
| Message-ID | <87msnfwa4v.fsf@nosuchdomain.example.com> |
| In reply to | #386292 |
Ben Bacarisse <ben@bsb.me.uk> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Ben Bacarisse <ben@bsb.me.uk> writes:
>> [...]
>>> On a C language point, I don't think the standard says anything about
>>> sorting with non-order functions like the one above. Is an
>>> implementation of qsort permitted to misbehave (for example by not
>>> terminating) when the comparison function does not implement a proper
>>> order relation?
>>
>> N1570 7.22.5p4 (applies to bsearch and qsort):
>> """
>> When the same objects (consisting of size bytes, irrespective of
>> their current positions in the array) are passed more than once to
>> the comparison function, the results shall be consistent with one
>> another. That is, for qsort they shall define a total ordering on
>> the array, and for bsearch the same object shall always compare
>> the same way with the key.
>> """
>>
>> That's a "shall" outside a constraint, so violating it results in
>> undefined behavior.
>
> I think it should be clearer. What the "that is" phrase seems to
> clarify in no way implies a total order, merely that the repeated
> comparisons or the same elements are consistent with one another. That
> the comparison function defines a total order on the elements is, to me,
> a major extra constraint that should not be written as an apparent
> clarification to something the does not imply it: repeated calls should
> be consistent with one another and, in addition, a total order should be
> imposed on the elements present.
I agree. The "That is, " should be dropped.
The most obvious meaning of the first sentence is that compar(A, B) must
yield the same result every time it's called (different positive values
are presumably meant to be "consistent", though that also could be
clearer), and that doesn't imply a total ordering. That requirement is
sufficient for bsearch().
The standard states the requirements correctly, but it's incorrect in
claiming that the second sentence logically follows from the first.
It's possible that the authors intended the first sentence to require a
total ordering. That depends on a strained interpretation of "same
objects", so it would apply to something like compar(A, B) vs. compar(B, C)
vs. compar(C, A), not allowing all three to return a negative result.
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-06-20 20:59 -0400 |
| Message-ID | <v52j9m$2qmmk$1@dont-email.me> |
| In reply to | #386292 |
On 6/20/24 17:39, Ben Bacarisse wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> Ben Bacarisse <ben@bsb.me.uk> writes: >> [...] >>> On a C language point, I don't think the standard says anything about >>> sorting with non-order functions like the one above. Is an >>> implementation of qsort permitted to misbehave (for example by not >>> terminating) when the comparison function does not implement a proper >>> order relation? >> >> N1570 7.22.5p4 (applies to bsearch and qsort): >> """ >> When the same objects (consisting of size bytes, irrespective of >> their current positions in the array) are passed more than once to >> the comparison function, the results shall be consistent with one >> another. That is, for qsort they shall define a total ordering on >> the array, and for bsearch the same object shall always compare >> the same way with the key. >> """ >> >> That's a "shall" outside a constraint, so violating it results in >> undefined behavior. > > I think it should be clearer. What the "that is" phrase seems to > clarify in no way implies a total order, merely that the repeated > comparisons or the same elements are consistent with one another. I don't think they were talking only about multiple comparisons of the same value producing the same result. I think that they were also talking about consistency between the result on different pairs of values. In order to sort a, b, and c, the results of comp(a,b), comp(b,c) and comp(a,c) need to be consistent with each other, or there's no well-defined sort order. "total order" is merely a more specific and precise way of specifying that consistency requirement, but it is a consistency requirement, and therefore the most plausible kind of consistency they could have been referring to with that comment.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-20 18:42 -0700 |
| Message-ID | <87frt7vzpc.fsf@nosuchdomain.example.com> |
| In reply to | #386300 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 6/20/24 17:39, Ben Bacarisse wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>> [...]
>>>> On a C language point, I don't think the standard says anything about
>>>> sorting with non-order functions like the one above. Is an
>>>> implementation of qsort permitted to misbehave (for example by not
>>>> terminating) when the comparison function does not implement a proper
>>>> order relation?
>>>
>>> N1570 7.22.5p4 (applies to bsearch and qsort):
>>> """
>>> When the same objects (consisting of size bytes, irrespective of
>>> their current positions in the array) are passed more than once to
>>> the comparison function, the results shall be consistent with one
>>> another. That is, for qsort they shall define a total ordering on
>>> the array, and for bsearch the same object shall always compare
>>> the same way with the key.
>>> """
>>>
>>> That's a "shall" outside a constraint, so violating it results in
>>> undefined behavior.
>>
>> I think it should be clearer. What the "that is" phrase seems to
>> clarify in no way implies a total order, merely that the repeated
>> comparisons or the same elements are consistent with one another.
>
> I don't think they were talking only about multiple comparisons of the
> same value producing the same result. I think that they were also
> talking about consistency between the result on different pairs of
> values. In order to sort a, b, and c, the results of comp(a,b),
> comp(b,c) and comp(a,c) need to be consistent with each other, or
> there's no well-defined sort order. "total order" is merely a more
> specific and precise way of specifying that consistency requirement, but
> it is a consistency requirement, and therefore the most plausible kind
> of consistency they could have been referring to with that comment.
That's the charitable reading, and certainly what was intended.
The problem is that if the authors had meant to say:
1. For any objects A and B, two or more calls compar(A, B) shall
return equivalent results and compar(B, A) shall return a result
opposite to that returned by compar(A, B).
2. Statement 1 implies that compar() shall implement a total
order.
(where statement 2 is clearly incorrect), they could have used the exact
words in the standard to express that.
There's no doubt that the intent was to require a total order (more
precisely, qsort() has undefined behavior if compar doesn't implement a
total order), but the first sentence implies that only with a strained
reading, and only if we already know what the intent was.
Dropping the "That is" in the second sentence would make it clear that
the total order is a requirement and is not necessarily a consequence of
the first sentence.
I don't suggest that any implementer or programmer will be seriously led
astray by a painfully literal reading the current wording, only that it
can be improved.
It wouldn't hurt to explicitly talk about the relationship between
compar(A, B) and compar(B, A), but that's reasonably implied by the
current consistency requirement.
Oh, and why is the comparison function called "compar" rather than
"compare"? Is it based on ancient limits on identifier lengths?
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-21 21:10 -0700 |
| Message-ID | <86h6dlhb34.fsf@linuxsc.com> |
| In reply to | #386292 |
Ben Bacarisse <ben@bsb.me.uk> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Ben Bacarisse <ben@bsb.me.uk> writes:
>> [...]
>>
>>> On a C language point, I don't think the standard says anything about
>>> sorting with non-order functions like the one above. Is an
>>> implementation of qsort permitted to misbehave (for example by not
>>> terminating) when the comparison function does not implement a proper
>>> order relation?
>>
>> N1570 7.22.5p4 (applies to bsearch and qsort):
>> """
>> When the same objects (consisting of size bytes, irrespective of
>> their current positions in the array) are passed more than once to
>> the comparison function, the results shall be consistent with one
>> another. That is, for qsort they shall define a total ordering on
>> the array, and for bsearch the same object shall always compare
>> the same way with the key.
>> """
>>
>> That's a "shall" outside a constraint, so violating it results in
>> undefined behavior.
>
> I think it should be clearer. What the "that is" phrase seems to
> clarify in no way implies a total order, merely that the repeated
> comparisons or the same elements are consistent with one another. That
> the comparison function defines a total order on the elements is, to me,
> a major extra constraint that should not be written as an apparent
> clarification to something the does not imply it: repeated calls should
> be consistent with one another and, in addition, a total order should be
> imposed on the elements present.
I think you're misreading the first sentence. Suppose we are in
court listening to an ongoing murder trial. Witness one comes in
and testifies that Alice left the house before Bob. Witness two
comes in (after witness one has gone) and testifies that Bob left
the house before Cathy. Witness three comes in (after the first
two have gone) and testifies that Cathy left the house before
Alice. None of the witnesses have contradicted either of the
other witnesses, but the testimonies of the three witnesses are
not consistent with one another. Try a web search
"consistent with" definition
for more explanation. Also, for "one another", if we say the
children in the Jones family get along with one another, we don't
mean that each child gets along with at least one of the others,
but instead mean that every child gets along with every other
child, that is, that they all get along with each other. Whether
or not some other reading (of that problem sentence in the C
standard) is sensible, surely the reading I have suggested is a
plausible one. Do you agree? It seems clear, given how the
second sentence is phrased, that this suggested reading is what
was intended.
I don't mean to defend the quality of writing in this passage.
Certainly it would be nice if the meaning could have been stated
more plainly. But I think it's an overstatement to say that the
first sentence in no way implies a total order.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-06-23 12:19 +0100 |
| Message-ID | <8734p3rjno.fsf@bsb.me.uk> |
| In reply to | #386340 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben@bsb.me.uk> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Ben Bacarisse <ben@bsb.me.uk> writes: >>> [...] >>> >>>> On a C language point, I don't think the standard says anything about >>>> sorting with non-order functions like the one above. Is an >>>> implementation of qsort permitted to misbehave (for example by not >>>> terminating) when the comparison function does not implement a proper >>>> order relation? >>> >>> N1570 7.22.5p4 (applies to bsearch and qsort): >>> """ >>> When the same objects (consisting of size bytes, irrespective of >>> their current positions in the array) are passed more than once to >>> the comparison function, the results shall be consistent with one >>> another. That is, for qsort they shall define a total ordering on >>> the array, and for bsearch the same object shall always compare >>> the same way with the key. >>> """ >>> >>> That's a "shall" outside a constraint, so violating it results in >>> undefined behavior. >> >> I think it should be clearer. What the "that is" phrase seems to >> clarify in no way implies a total order, merely that the repeated >> comparisons or the same elements are consistent with one another. That >> the comparison function defines a total order on the elements is, to me, >> a major extra constraint that should not be written as an apparent >> clarification to something the does not imply it: repeated calls should >> be consistent with one another and, in addition, a total order should be >> imposed on the elements present. > > I think you're misreading the first sentence. Let's hope so. That's why I said it should be clearer, not that it was wrong. > Suppose we are in > court listening to an ongoing murder trial. Witness one comes in > and testifies that Alice left the house before Bob. Witness two > comes in (after witness one has gone) and testifies that Bob left > the house before Cathy. Witness three comes in (after the first > two have gone) and testifies that Cathy left the house before > Alice. None of the witnesses have contradicted either of the > other witnesses, but the testimonies of the three witnesses are > not consistent with one another. My (apparently incorrect) reading of the first sentence is that the consistency is only required between the results of multiple calls between each pair. In other words, if the witnesses are repeatedly asked, again and again, if Alice left before Bob and/or if Bob left before Alice the results would always be consistent (with, of course, the same required of repeatedly asking about the other pairs of people). > Try a web search > > "consistent with" definition > > for more explanation. Seriously? > Also, for "one another", if we say the > children in the Jones family get along with one another, we don't > mean that each child gets along with at least one of the others, > but instead mean that every child gets along with every other > child, that is, that they all get along with each other. The sentence in question has, to my mind, already stated what the "one another" refers to -- the multiple calls between pairs containing the same objects. I get you think that's not the intended meaning, but I get my reading so strongly that I struggle to see the other. > Whether > or not some other reading (of that problem sentence in the C > standard) is sensible, surely the reading I have suggested is a > plausible one. Do you agree? It seems clear, given how the > second sentence is phrased, that this suggested reading is what > was intended. I still can't read it the way you do. Every time I try, I find the consistency is to be taken as applying to the results of the multiple calls between pairs of the same objects. Nothing more. It starts with "When the same objects". It seems so clear that the consistency is all about the multiple calls with these same objects. I keep trying to see your reading of it, but I can't. > I don't mean to defend the quality of writing in this passage. > Certainly it would be nice if the meaning could have been stated > more plainly. But I think it's an overstatement to say that the > first sentence in no way implies a total order. I have a second objection that promoted that remark. If I take the (apparently) intended meaning of the first sentence, I think that "consistent" is too weak to imply even a partial order. In dog club tonight, because of how they get on, I will ensure that Enzo is walking behind George, that George is walking behind Benji, Benji behind Gibson, Gibson behind Pepper and Pepper behind Enzo. In what sense is this "ordering" not consistent? All the calls to the comparison function are consistent with each other. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-06-23 10:30 -0400 |
| Message-ID | <v59bhe$ch8p$1@dont-email.me> |
| In reply to | #386379 |
On 6/23/24 07:19, Ben Bacarisse wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben@bsb.me.uk> writes: ... >>> I think it should be clearer. What the "that is" phrase seems to >>> clarify in no way implies a total order, merely that the repeated >>> comparisons or the same elements are consistent with one another. That >>> the comparison function defines a total order on the elements is, to me, >>> a major extra constraint that should not be written as an apparent >>> clarification to something the does not imply it: repeated calls should >>> be consistent with one another and, in addition, a total order should be >>> imposed on the elements present. >> >> I think you're misreading the first sentence. > > Let's hope so. That's why I said it should be clearer, not that it was > wrong. > >> Suppose we are in >> court listening to an ongoing murder trial. Witness one comes in >> and testifies that Alice left the house before Bob. Witness two >> comes in (after witness one has gone) and testifies that Bob left >> the house before Cathy. Witness three comes in (after the first >> two have gone) and testifies that Cathy left the house before >> Alice. None of the witnesses have contradicted either of the >> other witnesses, but the testimonies of the three witnesses are >> not consistent with one another. > > My (apparently incorrect) reading of the first sentence is that the > consistency is only required between the results of multiple calls > between each pair. In other words, if the witnesses are repeatedly > asked, again and again, if Alice left before Bob and/or if Bob left > before Alice the results would always be consistent (with, of course, > the same required of repeatedly asking about the other pairs of people). It says "When the same objects (consisting of size bytes, irrespective of their current positions in the array) are passed more than once to the comparison function, the results shall be consistent with one another." I can see you reading that as applying only when both arguments point to the same pair of objects as another call to comparison function, but if I do compar(&a,&b), compar(&b,&c), and compar(&c,&a), then each argument of every call to compar() involves the same object as one of the arguments of another call, and it seems to me that those same words therefore require consistency of the results of those comparisons, too. Interpreting those words that way might seem less obvious, but it has the advantage of making the subsequent "That is, ..." correct, rather than an error. I certainly would favor improved wording that made this clearer. In fact, simply explicitly mandating total ordering rather than making a vague comment about consistency would probably be the best approach.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-23 11:04 -0700 |
| Message-ID | <86zfrbfsd6.fsf@linuxsc.com> |
| In reply to | #386390 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: [on the requirements for qsort] > I certainly would favor improved wording that made this clearer. > In fact, simply explicitly mandating total ordering rather than > making a vague comment about consistency would probably be the > best approach. Clearly the C standard intends to impose a weaker requirement than that the comparison function be a total ordering.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-06-23 23:33 +0100 |
| Message-ID | <875xtzp9vl.fsf@bsb.me.uk> |
| In reply to | #386397 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > > [on the requirements for qsort] > >> I certainly would favor improved wording that made this clearer. >> In fact, simply explicitly mandating total ordering rather than >> making a vague comment about consistency would probably be the >> best approach. > > Clearly the C standard intends to impose a weaker requirement > than that the comparison function be a total ordering. The plot thickens. Unless, of course, you are referring to the distinction you drew before between an ordering of all possible objects and only those in the array. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-24 03:28 -0700 |
| Message-ID | <865xtyfxdr.fsf@linuxsc.com> |
| In reply to | #386405 |
Ben Bacarisse <ben@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> >> [on the requirements for qsort] >> >>> I certainly would favor improved wording that made this clearer. >>> In fact, simply explicitly mandating total ordering rather than >>> making a vague comment about consistency would probably be the >>> best approach. >> >> Clearly the C standard intends to impose a weaker requirement >> than that the comparison function be a total ordering. > > The plot thickens. Unless, of course, you are referring to the > distinction you drew before between an ordering of all possible objects > and only those in the array. Consider the following situation. We have an array with seven elements, the integers 1 to 7, in that order. We call qsort on the array, with a natural comparison function that compares the integer values. The qsort function starts with a check, and for any array with eight elements or fewer a simple insertion sort is done. Because 1 is less than 2, these elements stay where they are. Because 2 is less than 3, there is only the one comparison, and 3 stays where it is. And so on... at each point in the sort an element is compared to the one before it, and nothing changes. Six compares are done to sort seven elements. Question: has the program encountered any undefined behavior? (I expect you will say no.) Now consider a second situation. We again have an array with seven elements, the integers 1 to 7, but not necessarily in order. We call the same qsort function. This time though the argument for the comparison function is for a function that just always returns -1. The same sequence of events takes place as did in the first situation: each element after the first is compared to the one before it, and because the previous element is deemed "less than" this element no movement occurs and we proceed to the next element of the array. Six compares are done to "sort" seven elements. Question: has the program encountered any undefined behavior? If there has been undefined behavior, which passages in the C standard explains the difference relative to the first situation? If there has not been undefined behavior, what does that say about what the requirements are for a call to qsort?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-06-25 01:35 +0100 |
| Message-ID | <877cedoo4n.fsf@bsb.me.uk> |
| In reply to | #386449 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben@bsb.me.uk> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >>> >>> [on the requirements for qsort] >>> >>>> I certainly would favor improved wording that made this clearer. >>>> In fact, simply explicitly mandating total ordering rather than >>>> making a vague comment about consistency would probably be the >>>> best approach. >>> >>> Clearly the C standard intends to impose a weaker requirement >>> than that the comparison function be a total ordering. >> >> The plot thickens. Unless, of course, you are referring to the >> distinction you drew before between an ordering of all possible objects >> and only those in the array. > > Consider the following situation. > > We have an array with seven elements, the integers 1 to 7, > in that order. We call qsort on the array, with a natural > comparison function that compares the integer values. > > The qsort function starts with a check, and for any array > with eight elements or fewer a simple insertion sort is > done. Because 1 is less than 2, these elements stay > where they are. Because 2 is less than 3, there is only > the one comparison, and 3 stays where it is. And so on... > at each point in the sort an element is compared to the > one before it, and nothing changes. Six compares are > done to sort seven elements. Question: has the program > encountered any undefined behavior? (I expect you will > say no.) > > Now consider a second situation. > > We again have an array with seven elements, the integers 1 > to 7, but not necessarily in order. We call the same > qsort function. This time though the argument for the > comparison function is for a function that just always > returns -1. The same sequence of events takes place as > did in the first situation: each element after the first > is compared to the one before it, and because the previous > element is deemed "less than" this element no movement > occurs and we proceed to the next element of the array. > Six compares are done to "sort" seven elements. Question: > has the program encountered any undefined behavior? > > If there has been undefined behavior, which passages in > the C standard explains the difference relative to the > first situation? > > If there has not been undefined behavior, what does that > say about what the requirements are for a call to qsort? So you are pointing out that only the comparisons made have to be "consistent with one another"? BTW, your function that returns -1 is just the total extension of my partial "dog order" function. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 of 18 — ← Prev page 1 … 3 4 [5] 6 7 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web