Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #80902 > unrolled thread
| Started by | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| First post | 2021-08-29 20:57 +0200 |
| Last post | 2021-09-01 16:32 -0400 |
| Articles | 20 on this page of 301 — 30 participants |
Back to article view | Back to comp.lang.c++
Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-29 20:57 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-08-30 21:59 -0500
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-08-30 21:53 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-08-30 21:59 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-08-31 09:01 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-08-31 03:00 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-08-31 23:46 -0500
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 08:19 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 15:32 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 19:20 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 19:44 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-09-01 13:17 -0500
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 20:32 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 19:00 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-09-01 15:06 -0500
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 20:14 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 20:37 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-31 10:08 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-08-31 14:54 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-08-31 15:00 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-09-01 12:49 -0500
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Siri Cruise <chine.bleu@yahoo.com> - 2021-08-30 21:23 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-30 23:29 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 12:27 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Richard Damon <Richard@Damon-Family.org> - 2021-08-31 07:37 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 14:14 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-31 07:06 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 17:20 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-08-31 15:36 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 17:44 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-31 09:12 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 18:20 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-08-31 16:40 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 19:04 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Vir Campestris <vir.campestris@invalid.invalid> - 2021-08-31 21:37 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 07:25 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 09:26 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 10:14 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 11:07 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-01 10:31 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 20:27 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 15:22 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? red floyd <no.spam.here@its.invalid> - 2021-09-01 07:52 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 15:21 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? red floyd <no.spam.here@its.invalid> - 2021-09-01 09:41 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-01 18:11 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 18:04 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-01 18:27 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 19:02 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-01 21:36 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-02 06:58 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-02 11:34 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-02 14:51 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-02 23:31 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-03 11:12 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-03 15:35 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-03 16:46 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-03 22:01 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-03 20:45 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-04 01:06 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-04 02:12 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-04 09:12 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Manfred <noname@add.invalid> - 2021-09-04 18:05 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-06 08:43 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-06 08:59 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-06 10:12 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-06 11:27 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-06 12:48 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-04 15:28 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-04 17:44 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Ian Collins <ian-news@hotmail.com> - 2021-09-05 11:24 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Ian Collins <ian-news@hotmail.com> - 2021-09-04 10:14 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-04 09:36 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-04 17:00 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-06 11:03 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-06 09:11 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-06 13:08 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-06 15:26 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Manfred <noname@add.invalid> - 2021-09-07 15:05 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-07 15:07 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-07 19:41 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-08 09:38 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-08 10:29 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-09 10:58 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-09 08:55 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-09 12:15 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-09 09:19 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-09 14:41 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-09 22:19 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-09 16:09 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-09 12:41 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-08 10:24 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-08 20:22 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-09 08:54 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-09 14:47 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-09 16:13 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-09 12:42 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-10 09:37 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 13:27 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-10 05:41 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 15:31 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-10 16:45 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-10 07:21 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-11 11:20 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > scott@slp53.sl.home (Scott Lurndal) - 2021-09-10 14:50 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-10 14:56 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 17:38 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-10 15:47 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-11 18:40 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-12 09:23 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-12 12:57 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-12 16:22 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 12:49 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-12 16:13 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 18:45 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-13 10:55 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-13 14:15 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-13 15:32 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-13 12:07 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-13 22:18 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-12 09:48 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-13 10:52 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-12 23:12 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > Vir Campestris <vir.campestris@invalid.invalid> - 2021-09-13 22:00 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-14 09:24 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > scott@slp53.sl.home (Scott Lurndal) - 2021-09-13 21:42 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-14 10:15 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-14 09:12 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > scott@slp53.sl.home (Scott Lurndal) - 2021-09-14 15:01 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-14 17:07 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Vir Campestris <vir.campestris@invalid.invalid> - 2021-09-14 21:42 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-10 16:13 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 17:45 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-10 12:23 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-10 17:09 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-10 14:17 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-11 09:06 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-09 12:41 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-09 22:17 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-10 09:39 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 13:29 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-12 08:56 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-12 09:18 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-12 09:21 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-12 09:29 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 12:55 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-12 16:14 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-12 23:13 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-13 05:23 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-13 10:56 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > scott@slp53.sl.home (Scott Lurndal) - 2021-09-13 14:55 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Manfred <noname@add.invalid> - 2021-09-12 01:09 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-12 01:29 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 11:46 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-12 04:42 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 13:54 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-12 06:01 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-12 15:22 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 18:53 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-12 11:29 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-13 08:38 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-12 17:38 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > Manfred <noname@add.invalid> - 2021-09-13 03:52 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-12 19:10 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 11:32 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > scott@slp53.sl.home (Scott Lurndal) - 2021-09-09 18:37 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-07 17:56 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-08 10:28 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-08 13:31 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-09 11:06 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-09 01:27 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-09 13:05 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-09 10:29 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-09 22:28 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-09 12:40 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-10 09:51 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-10 00:07 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-10 11:26 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 10:02 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-10 09:10 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-10 11:32 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-12 09:00 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-12 11:29 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 13:47 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-11 11:02 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-11 00:33 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-11 11:42 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Manfred <noname@add.invalid> - 2021-09-15 19:20 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-11 19:15 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-11 20:56 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-12 12:11 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 11:53 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-12 11:17 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-13 12:51 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-13 11:03 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-14 12:05 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-14 10:28 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-15 08:17 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-12 09:10 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-12 21:51 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-09-12 15:55 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Vir Campestris <vir.campestris@invalid.invalid> - 2021-09-12 21:18 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-13 08:48 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > scott@slp53.sl.home (Scott Lurndal) - 2021-09-13 15:09 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-13 05:28 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-13 09:23 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 12:21 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-10 05:29 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-10 12:20 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-06 11:51 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-03 05:13 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-03 11:30 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-03 11:19 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-03 13:33 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-03 15:44 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-03 17:40 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-03 17:58 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-03 22:23 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-04 12:20 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-06 05:42 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-09-03 08:49 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-03 17:42 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-09-05 04:29 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Michael S <already5chosen@yahoo.com> - 2021-09-05 05:11 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-06 05:45 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-09-06 03:38 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-06 12:00 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-06 16:38 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-06 15:52 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-07 04:39 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-07 07:23 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-07 07:31 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Ian Collins <ian-news@hotmail.com> - 2021-09-07 21:47 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-08 10:18 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-08 11:32 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-09-08 05:02 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-08 13:44 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-09-08 07:41 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-08 16:44 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-08 09:04 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-08 20:16 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-08 17:27 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-08 20:23 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-08 22:38 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-09 08:11 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-09-09 09:25 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-09 18:43 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-06 05:37 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-06 11:54 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 13:01 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 23:41 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-01 23:32 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-02 12:31 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-02 11:11 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-02 16:04 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? RantingRover <noemail@4u.com> - 2021-09-02 13:14 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Vir Campestris <vir.campestris@invalid.invalid> - 2021-09-01 21:43 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-01 04:40 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-08-31 15:02 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "see.my....@gmail.com" <see.my.homepage@gmail.com> - 2021-08-31 10:26 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 19:46 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-01 04:42 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 07:26 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-01 07:41 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 08:03 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-01 08:34 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 08:43 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-01 08:55 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 10:05 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Vir Campestris <vir.campestris@invalid.invalid> - 2021-09-01 21:34 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 10:10 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 10:37 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 10:44 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 10:48 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 10:51 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 11:15 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 12:15 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-01 06:49 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 15:50 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-01 07:16 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 16:30 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 10:28 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 09:57 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 10:13 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 10:44 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 11:05 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 11:17 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 12:17 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 12:48 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 12:54 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-01 15:20 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 11:11 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 12:19 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-01 18:14 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 20:34 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 21:55 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-01 16:30 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-02 05:30 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 19:03 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 21:12 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-01 16:32 -0400
Page 7 of 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2021-09-12 09:48 -0700 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <ad1b420b-6b92-454a-a5f7-61b59700e0d4n@googlegroups.com> |
| In reply to | #81219 |
On Sunday, September 12, 2021 at 7:13:27 PM UTC+3, Horsey...@the_stables.com wrote: > On Sun, 12 Sep 2021 12:49:14 +0200 > David Brown <david...@hesbynett.no> wrote: > >On 12/09/2021 11:23, HorseyWorsey@the_stables.com wrote: > >Yes, the main makefile is written manually (or at least, that's what I > Exactly. > >It is /not/ the /compiler's/ job to know this! It is the /build/ system > >that says what programs are run on which files in order to create all > >the files needed. > Exactly. > >> And that is supposed to be simpler than writing a Makefile yourself is it? > >> Riiiiiight. > > > >Who do you think wrote the makefile? A friendly goblin? /I/ wrote the > >makefile. /I/ put rules in the makefile to run "gcc -MD" as and when > >needed in order to generate the dependencies. The point is that no one > >- not me, nor anyone else - needs to keep manually updating the makefile > >to track the simple dependencies that can be calculated automatically. > "Simple". Exactly. > >I don't yet know whether you are wilfully ignorant, or trolling. > I'm rapidly getting the impression you and the others completely missed my > original point despite stating it numerous time. Frankly I can't be bothered > to continue with this. Frankly, from the view of discussion I see on google groups it's quite difficult to figure out what you are arguing foe. Or against. Are you saying that all of us have to teach ourselves cmake even despite the fact that writing makefiles by hand + utilizing .d files generated by compiles served our needs rather well for last 10-20-30 years?
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-13 10:52 +0000 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shnahf$1mom$1@gioia.aioe.org> |
| In reply to | #81223 |
On Sun, 12 Sep 2021 09:48:22 -0700 (PDT) Michael S <already5chosen@yahoo.com> wrote: >On Sunday, September 12, 2021 at 7:13:27 PM UTC+3, Horsey...@the_stables.com >wrote: >> On Sun, 12 Sep 2021 12:49:14 +0200 >> David Brown <david...@hesbynett.no> wrote: >> >On 12/09/2021 11:23, HorseyWorsey@the_stables.com wrote: >> >Yes, the main makefile is written manually (or at least, that's what I >> Exactly. >> >It is /not/ the /compiler's/ job to know this! It is the /build/ system >> >that says what programs are run on which files in order to create all >> >the files needed. >> Exactly. >> >> And that is supposed to be simpler than writing a Makefile yourself is >it? >> >> Riiiiiight. >> > >> >Who do you think wrote the makefile? A friendly goblin? /I/ wrote the >> >makefile. /I/ put rules in the makefile to run "gcc -MD" as and when >> >needed in order to generate the dependencies. The point is that no one >> >- not me, nor anyone else - needs to keep manually updating the makefile >> >to track the simple dependencies that can be calculated automatically. >> "Simple". Exactly. >> >I don't yet know whether you are wilfully ignorant, or trolling. >> I'm rapidly getting the impression you and the others completely missed my >> original point despite stating it numerous time. Frankly I can't be bothered > >> to continue with this. > > >Frankly, from the view of discussion I see on google groups it's quite >difficult to figure out what you are arguing foe. Or against. > >Are you saying that all of us have to teach ourselves cmake even despite the >fact that writing makefiles by hand + utilizing .d files generated by compiles >served our needs rather well for last 10-20-30 years? No.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-09-12 23:12 -0400 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shmfjn$74h$2@dont-email.me> |
| In reply to | #81196 |
On 9/12/21 5:23 AM, HorseyWorsey@the_stables.com wrote: > On Sat, 11 Sep 2021 18:40:58 +0200 > David Brown <david.brown@hesbynett.no> wrote: >> On 10/09/2021 17:47, HorseyWorsey@the_stables.com wrote: ... >> Do you still not understand what is being discussed here? "gcc -MD" is >> /not/ a replacement for a build system. It is a tool to help automate >> your build systems. The output of "gcc -MD" is a dependency file, which >> your makefile (or other build system) imports. > > Yes, I understand perfectly. You create huge dependency files which either > have to be stored in git (or similar) and updated when appropriate, or auto Why in the world would you store them in git? They are compiler-generated files, not source files. Do you normally keep .o files in git? How about executables? You don't need to update them manually; if you set up your build system properly, they get updated automatically when needed. The convention I've seen is that version control systems like git are used only to save the source files from which other files are generated - they aren't used to store generated files. I know of one main exception to that, when using clearcase/clearmake - but the feasibility of doing that depends upon features of clearcase and clearmake that are not, to the best of my knowledge, shared by git and make, respectively. A dependencies file retrieved from git would have to be replaced almost immediately with a freshly generated one, which makes storing it there even less reasonable than storing a .o file. > generated in the makefile and then further used in the makefile which has to > be manually written anyway unless its simple so what exactly is the point? It greatly simplifies writing the makefile - it need only contain an include line referencing the dependency file, rather than containing all of those individual dependencies. >>> Also using >>> the compiler is sod all use if you need to fire off a script to auto generate >> >>> some code first. >> >> No, it is not. It works fine - as long as you understand how your build > > Excuse me? Ok, please do tell me how the compiler knows which script file to > run to generate the header file. This'll be interesting. The build system is what needs to know how to generate the header file. The dependency file created by gcc -MD is intended to be used by the build system, not as a replacement for a build system. All the compiler needs to know is whether any given translation unit that it compiles #includes the header; if so, it generates the appropriate line in a dependency file. >> well as lots of other C and header files). If I change the text file or >> the Python script and type "make", then first a new header and C file >> are created from the text file. Then "gcc -MD" is run on the C file, >> generating a new dependency file, since the dependency file depends on >> the header and the C file. Then this updated dependency file is >> imported by make, and shows that the object file (needed by for the >> link) depends on the updated C file, so the compiler is called on the file. > > And that is supposed to be simpler than writing a Makefile yourself is it? It certainly is. It happens automatically when your build system is properly set up, without requiring user intervention to update the dependencies when they change, and it includes all dependencies, both direct and indirect, which is something so difficult that most people wouldn't even attempt it if forced to insert the dependencies manually.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2021-09-13 22:00 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shoe5m$v0q$2@dont-email.me> |
| In reply to | #81231 |
On 13/09/2021 04:12, James Kuyper wrote: <snip> > Why in the world would you store them in git? They are > compiler-generated files, not source files. Do you normally keep .o > files in git? How about executables? You don't need to update them > manually; if you set up your build system properly, they get updated > automatically when needed. </snip> We absolutely keep executables in a controlled archive. The build system produces a system image; this is in turn made from various files, some of which are executable; we store the image, the executables, the symbol files that go with them, and put a label in the source control system to show where it was build from. The executables and symbols can save a _lot_ of time when looking at dumps. Andy
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-14 09:24 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <iq9trlFh2ruU4@mid.individual.net> |
| In reply to | #81253 |
On 14/09/2021 09:00, Vir Campestris wrote: > On 13/09/2021 04:12, James Kuyper wrote: > <snip> >> Why in the world would you store them in git? They are >> compiler-generated files, not source files. Do you normally keep .o >> files in git? How about executables? You don't need to update them >> manually; if you set up your build system properly, they get updated >> automatically when needed. > </snip> > > We absolutely keep executables in a controlled archive. > > The build system produces a system image; this is in turn made from > various files, some of which are executable; we store the image, the > executables, the symbol files that go with them, and put a label in the > source control system to show where it was build from. > > The executables and symbols can save a _lot_ of time when looking at dumps. But they can be recreated from the source and a given source control hash or tag? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-13 21:42 +0000 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <SAP%I.4875$PE4.2782@fx11.iad> |
| In reply to | #81254 |
Ian Collins <ian-news@hotmail.com> writes: >On 14/09/2021 09:00, Vir Campestris wrote: >> On 13/09/2021 04:12, James Kuyper wrote: >> <snip> >>> Why in the world would you store them in git? They are >>> compiler-generated files, not source files. Do you normally keep .o >>> files in git? How about executables? You don't need to update them >>> manually; if you set up your build system properly, they get updated >>> automatically when needed. >> </snip> >> >> We absolutely keep executables in a controlled archive. >> >> The build system produces a system image; this is in turn made from >> various files, some of which are executable; we store the image, the >> executables, the symbol files that go with them, and put a label in the >> source control system to show where it was build from. >> >> The executables and symbols can save a _lot_ of time when looking at dumps. > >But they can be recreated from the source and a given source control >hash or tag? Maybe. If you have the exact same compiler, assembler and linker. Maybe. And not if the linker uses any form of address space randomization.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-14 10:15 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <iqa0skFh2ruU5@mid.individual.net> |
| In reply to | #81255 |
On 14/09/2021 09:42, Scott Lurndal wrote: > Ian Collins <ian-news@hotmail.com> writes: >> On 14/09/2021 09:00, Vir Campestris wrote: >>> On 13/09/2021 04:12, James Kuyper wrote: >>> <snip> >>>> Why in the world would you store them in git? They are >>>> compiler-generated files, not source files. Do you normally keep .o >>>> files in git? How about executables? You don't need to update them >>>> manually; if you set up your build system properly, they get updated >>>> automatically when needed. >>> </snip> >>> >>> We absolutely keep executables in a controlled archive. >>> >>> The build system produces a system image; this is in turn made from >>> various files, some of which are executable; we store the image, the >>> executables, the symbol files that go with them, and put a label in the >>> source control system to show where it was build from. >>> >>> The executables and symbols can save a _lot_ of time when looking at dumps. >> >> But they can be recreated from the source and a given source control >> hash or tag? > > Maybe. If you have the exact same compiler, assembler and linker. Maybe. We build everything in virtual machines or docker, so the build environment for any build can be recovered. Our CI system generates ~500GB of built artifacts per day, which doesn't include intermediate items such as object files. Not something we'd want to keep around forever! > And not if the linker uses any form of address space randomization. This hasn't bitten us. Our target is (literally!) a closed black box. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-14 09:12 +0200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shpi13$k7s$1@dont-email.me> |
| In reply to | #81255 |
On 13/09/2021 23:42, Scott Lurndal wrote: > Ian Collins <ian-news@hotmail.com> writes: >> On 14/09/2021 09:00, Vir Campestris wrote: >>> On 13/09/2021 04:12, James Kuyper wrote: >>> <snip> >>>> Why in the world would you store them in git? They are >>>> compiler-generated files, not source files. Do you normally keep .o >>>> files in git? How about executables? You don't need to update them >>>> manually; if you set up your build system properly, they get updated >>>> automatically when needed. >>> </snip> >>> >>> We absolutely keep executables in a controlled archive. >>> >>> The build system produces a system image; this is in turn made from >>> various files, some of which are executable; we store the image, the >>> executables, the symbol files that go with them, and put a label in the >>> source control system to show where it was build from. >>> >>> The executables and symbols can save a _lot_ of time when looking at dumps. >> >> But they can be recreated from the source and a given source control >> hash or tag? > > Maybe. If you have the exact same compiler, assembler and linker. Maybe. > > And not if the linker uses any form of address space randomization. > All these things vary by project. For the kinds of things I do, I make a point of archiving the toolchain tool (though not in a git repository). Reproducible builds are important for me. Other kinds of projects have different setups and are perhaps build using a variety of different tools. So while /I/ keep track of released binaries - and when re-opening old projects, I have something to compare so that I can check the re-created build environment - it is not something everyone needs or does. Another advantage I see of binaries in the repositories is it makes life easier for people involved in testing or other work - they can pull out the latest binaries without having to have all the toolchain themselves.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-14 15:01 +0000 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <_O20J.40937$md6.16892@fx36.iad> |
| In reply to | #81260 |
David Brown <david.brown@hesbynett.no> writes: >On 13/09/2021 23:42, Scott Lurndal wrote: >> Ian Collins <ian-news@hotmail.com> writes: >>> On 14/09/2021 09:00, Vir Campestris wrote: >>>> On 13/09/2021 04:12, James Kuyper wrote: >>>> <snip> >>>>> Why in the world would you store them in git? They are >>>>> compiler-generated files, not source files. Do you normally keep .o >>>>> files in git? How about executables? You don't need to update them >>>>> manually; if you set up your build system properly, they get updated >>>>> automatically when needed. >>>> </snip> >>>> >>>> We absolutely keep executables in a controlled archive. >>>> >>>> The build system produces a system image; this is in turn made from >>>> various files, some of which are executable; we store the image, the >>>> executables, the symbol files that go with them, and put a label in the >>>> source control system to show where it was build from. >>>> >>>> The executables and symbols can save a _lot_ of time when looking at dumps. >>> >>> But they can be recreated from the source and a given source control >>> hash or tag? >> >> Maybe. If you have the exact same compiler, assembler and linker. Maybe. >> >> And not if the linker uses any form of address space randomization. >> > >All these things vary by project. For the kinds of things I do, I make >a point of archiving the toolchain tool (though not in a git >repository). Reproducible builds are important for me. Other kinds of >projects have different setups and are perhaps build using a variety of >different tools. In our case, the debuginfo files (DWARF data extracted from the ELF prior to shipping to customers) are saved for each software 'drop' to a customer. Much easier to deal with than finding the particular version of the toolset used to build the product.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-14 17:07 +0200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shqdrq$9u$1@dont-email.me> |
| In reply to | #81264 |
On 14/09/2021 17:01, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 13/09/2021 23:42, Scott Lurndal wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >>>> On 14/09/2021 09:00, Vir Campestris wrote: >>>>> On 13/09/2021 04:12, James Kuyper wrote: >>>>> <snip> >>>>>> Why in the world would you store them in git? They are >>>>>> compiler-generated files, not source files. Do you normally keep .o >>>>>> files in git? How about executables? You don't need to update them >>>>>> manually; if you set up your build system properly, they get updated >>>>>> automatically when needed. >>>>> </snip> >>>>> >>>>> We absolutely keep executables in a controlled archive. >>>>> >>>>> The build system produces a system image; this is in turn made from >>>>> various files, some of which are executable; we store the image, the >>>>> executables, the symbol files that go with them, and put a label in the >>>>> source control system to show where it was build from. >>>>> >>>>> The executables and symbols can save a _lot_ of time when looking at dumps. >>>> >>>> But they can be recreated from the source and a given source control >>>> hash or tag? >>> >>> Maybe. If you have the exact same compiler, assembler and linker. Maybe. >>> >>> And not if the linker uses any form of address space randomization. >>> >> >> All these things vary by project. For the kinds of things I do, I make >> a point of archiving the toolchain tool (though not in a git >> repository). Reproducible builds are important for me. Other kinds of >> projects have different setups and are perhaps build using a variety of >> different tools. > > In our case, the debuginfo files (DWARF data extracted from the ELF > prior to shipping to customers) are saved for each software 'drop' > to a customer. Much easier to deal with than finding the particular > version of the toolset used to build the product. > Debug information is never reproducible - there are always paths, timestamps, etc., that differ. But none of our customers are interested in debug information or even stripped elf files - it's the .bin or .hex images that must match entirely. The toolset version is in the makefiles - when "/opt/gcc-arm-none-eabi-10-2020-q4-major/bin/" is explicit in the makefile, there's never any doubt about the toolchain.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2021-09-14 21:42 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shr1fi$865$4@dont-email.me> |
| In reply to | #81254 |
On 13/09/2021 22:24, Ian Collins wrote: > On 14/09/2021 09:00, Vir Campestris wrote: >> On 13/09/2021 04:12, James Kuyper wrote: >> <snip> >>> Why in the world would you store them in git? They are >>> compiler-generated files, not source files. Do you normally keep .o >>> files in git? How about executables? You don't need to update them >>> manually; if you set up your build system properly, they get updated >>> automatically when needed. >> </snip> >> >> We absolutely keep executables in a controlled archive. >> >> The build system produces a system image; this is in turn made from >> various files, some of which are executable; we store the image, the >> executables, the symbol files that go with them, and put a label in the >> source control system to show where it was build from. >> >> The executables and symbols can save a _lot_ of time when looking at >> dumps. > > But they can be recreated from the source and a given source control > hash or tag? > In theory, yes. In practice I've never had to try. But you can think of the binaries as a cache. Andy
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-10 16:13 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shfsmu$an2$1@dont-email.me> |
| In reply to | #81138 |
On 10/09/2021 12:27, David Brown wrote:
> On 10/09/2021 11:37, HorseyWorsey@the_stables.com wrote:
>> Ok, so foo.c includes globals.h which defines all the functions in moo.c,
>> baa.c and oink.c. How does gcc know about those 3 C files since globals.h
>> gives non indication of their existence?
>
> You mean "globals.h" /declares/ the functions - it does not /define/
> them (unless they are inline functions). (Putting all your declarations
> in a single header is a poor way to structure code, but that's beside
> the point here.)
>
> The compiler compiles code. It (gcc, clang, and some other compilers)
> can be used to tell you which /included/ files are used. So "gcc -MD
> foo.c" can tell you that the compilation depends on "globals.h" as well
> as "foo.c". You are not asking it to compile "moo.c", so it can't tell
> you anything about that.
My C compiler has an experimental feature to do just that.
If it sees A.h and B.h in main.c for example, then it will also look for
A.c and B.c, and compile those too. The process works recursively, so it
will locate all dependent modules, just like a language which has proper
modules.
But the project needs to be tidily structured structured just like such
a language too: one .h file for each .c. file. Most C projects are
structured more chaotically.
(Not finding a .c file matching a header is not an error; the header
might be for an external library for example.)
--------------
C:\c>type main.c
#include "a.h"
#include "b.h"
int main(void) {
a();
b();
}
C:\c>bcc -auto main.c
1 Compiling main.c to main.asm (Pass 1)
* 2 Compiling a.c to a.asm (Pass 2)
* 3 Compiling b.c to b.asm (Pass 2)
Assembling to main.exe
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-10 17:45 +0200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shfuih$nv8$1@dont-email.me> |
| In reply to | #81148 |
On 10/09/2021 17:13, Bart wrote:
> On 10/09/2021 12:27, David Brown wrote:
>> On 10/09/2021 11:37, HorseyWorsey@the_stables.com wrote:
>
>>> Ok, so foo.c includes globals.h which defines all the functions in
>>> moo.c,
>>> baa.c and oink.c. How does gcc know about those 3 C files since
>>> globals.h
>>> gives non indication of their existence?
>>
>> You mean "globals.h" /declares/ the functions - it does not /define/
>> them (unless they are inline functions). (Putting all your declarations
>> in a single header is a poor way to structure code, but that's beside
>> the point here.)
>>
>> The compiler compiles code. It (gcc, clang, and some other compilers)
>> can be used to tell you which /included/ files are used. So "gcc -MD
>> foo.c" can tell you that the compilation depends on "globals.h" as well
>> as "foo.c". You are not asking it to compile "moo.c", so it can't tell
>> you anything about that.
>
> My C compiler has an experimental feature to do just that.
>
> If it sees A.h and B.h in main.c for example, then it will also look for
> A.c and B.c, and compile those too. The process works recursively, so it
> will locate all dependent modules, just like a language which has proper
> modules.
>
> But the project needs to be tidily structured structured just like such
> a language too: one .h file for each .c. file. Most C projects are
> structured more chaotically.
>
I am always a bit reluctant to make guesses about "most C projects".
However, there is no doubt that many projects are structured
differently, and many are structured chaotically (though differently
does not imply chaotically).
It sounds like a feature that could be useful for appropriately
structured and sized projects. Since your C compiler is primarily
targeted at compiling C code generated by your other tools, and these
presumably stick to that structure, it sounds a good idea.
For my own use, it would work for my smaller and simpler projects
(baring all the other reasons why the compiler wouldn't work for me).
For bigger projects, my makefiles cover a lot more, so using dependency
handling and wildcards is not a noticeable cost.
> (Not finding a .c file matching a header is not an error; the header
> might be for an external library for example.)
>
> --------------
>
> C:\c>type main.c
> #include "a.h"
> #include "b.h"
>
> int main(void) {
> a();
> b();
> }
>
> C:\c>bcc -auto main.c
> 1 Compiling main.c to main.asm (Pass 1)
> * 2 Compiling a.c to a.asm (Pass 2)
> * 3 Compiling b.c to b.asm (Pass 2)
> Assembling to main.exe
>
>
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-09-10 12:23 -0400 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shg0pb$f74$1@dont-email.me> |
| In reply to | #81134 |
On 9/10/21 5:37 AM, HorseyWorsey@the_stables.com wrote: > On Thu, 9 Sep 2021 12:42:19 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: ... >> A C compiler is supposed to replace a #include directive with the >> contents of the specified file - if it doesn't know what file that is, >> how can a compiler perform that replacement? If it does know what file >> that is, it can record that dependency for use in later runs, which is >> precisely what gcc -MD does. > > Ok, so foo.c includes globals.h which defines all the functions in moo.c,> baa.c and oink.c. How does gcc know about those 3 C files since globals.h > gives non indication of their existence? When it compiles foo.c to create foo.o, it finds the #include "globals.h" directive, and searches for globals.h in the specified search path. Having found that file, it reads it in, replacing the #include directive, and at the same time takes note of that fact that this means that foo.o depends upon globals.h. At this point, it will know the full path name for globals.h, and will generally use that full path name when recording that dependency. The same thing occurs when it compiles baa.c and oink.c. The next time you run make, it will know that the dependency exists, and will not rebuild foo.o unless there's a change in foo.c or in one of the other files foo.o depends upon. It's therefore always one build out-of-date, but David has explained a neat trick that I was not aware of, for getting around that problem. >> Most compilers I'm familiar with also invoke the linker themselves, and > > And the linking is a seperate step in the build process once all the source > files have been built. Yes, and control returns to the compiler after it invokes the linker, and the compiler could then use the information provided by the linker to update the dependencies file. >> therefore know precisely which files they told the linker to link >> together. They also use information provided by the linker to determine >> which library files the linker ended up linking into the program. > > Ok, so the link stage has subsystem.o which is a combination of moo.o, baa.o > and oink.o. How does it figure out it needs to build moo.c, baa.c and oink.c > then? In what sense is subsystem.o "a combination of moo.o, baa.o, and oink.o"? If it's a library file, on the systems I'm familiar with, naming conventions require it to have either .a or .so extensions; other systems that I'm not familiar with would require it to have a .dll extension. Is it an executable file? If so, on the systems I use most frequently, the naming convention is that it should have either no extension or an extension of .exe. There are other naming conventions in use, but I'm not familiar with any naming convention that uses a .o extension for a file that is, in any sense, the merger of multiple object files. If subsystem.o was created, directly or indirectly, by invoking the compiler, than the compiler could keep track of those connections - it doesn't matter whether the linker knows about such things. Otherwise, you're correct - the compiler can't know. gcc -MD cannot cover all dependency issues, but it can automate a large fraction of them, reducing the number of dependencies you need to state explicitly in the make file itself
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-10 17:09 +0000 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shg3gn$1het$1@gioia.aioe.org> |
| In reply to | #81152 |
On Fri, 10 Sep 2021 12:23:06 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 9/10/21 5:37 AM, HorseyWorsey@the_stables.com wrote: >> On Thu, 9 Sep 2021 12:42:19 -0400 >> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> Ok, so foo.c includes globals.h which defines all the functions in moo.c,> >baa.c and oink.c. How does gcc know about those 3 C files since globals.h >> gives non indication of their existence? > >When it compiles foo.c to create foo.o, it finds the #include >"globals.h" directive, and searches for globals.h in the specified >search path. Having found that file, it reads it in, replacing the >#include directive, and at the same time takes note of that fact that >this means that foo.o depends upon globals.h. At this point, it will >know the full path name for globals.h, and will generally use that full >path name when recording that dependency. The same thing occurs when it >compiles baa.c and oink.c. Catch 22. You'll already need a build system to build those files if they're scattered around and hav multiple dependencies so what problem is this solving? Or are you suggesting do all these steps manually just to create a Makefile that'll probably still need tweeking anyway? >> Ok, so the link stage has subsystem.o which is a combination of moo.o, baa.o >> and oink.o. How does it figure out it needs to build moo.c, baa.c and oink.c >> then? > >In what sense is subsystem.o "a combination of moo.o, baa.o, and >oink.o"? If it's a library file, on the systems I'm familiar with, >naming conventions require it to have either .a or .so extensions; other Yes, .so, typo, point still stands. >you're correct - the compiler can't know. gcc -MD cannot cover all >dependency issues, but it can automate a large fraction of them, >reducing the number of dependencies you need to state explicitly in the >make file itself So fairly useless then.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-09-10 14:17 -0400 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shg7ga$ve8$1@dont-email.me> |
| In reply to | #81153 |
On 9/10/21 1:09 PM, HorseyWorsey@the_stables.com wrote: > On Fri, 10 Sep 2021 12:23:06 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> On 9/10/21 5:37 AM, HorseyWorsey@the_stables.com wrote: >>> On Thu, 9 Sep 2021 12:42:19 -0400 >>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>> Ok, so foo.c includes globals.h which defines all the functions in moo.c,> >> baa.c and oink.c. How does gcc know about those 3 C files since globals.h >>> gives non indication of their existence? >> >> When it compiles foo.c to create foo.o, it finds the #include >> "globals.h" directive, and searches for globals.h in the specified >> search path. Having found that file, it reads it in, replacing the >> #include directive, and at the same time takes note of that fact that >> this means that foo.o depends upon globals.h. At this point, it will >> know the full path name for globals.h, and will generally use that full >> path name when recording that dependency. The same thing occurs when it >> compiles baa.c and oink.c. > > Catch 22. You'll already need a build system to build those files if they're > scattered around and hav multiple dependencies so what problem is this solving? MisterMule's original comment on September 8th was about the difficulty of putting dependencies into a makefile. That implies the use of make, which is the build system that's relevant. gcc -MD is not intended to remove the need for make, it's intended for use with make. The problem that it solves is simplifying the creation of the makefile. The makefile itself needs to identify the dependency file created by gcc -MD. The only other dependencies it needs to identify are those that cannot be identified by the use of that option. That is enourmously easier than inserting all of those dependencies manually, and updating them as needed. >>> Ok, so the link stage has subsystem.o which is a combination of moo.o, baa.o >>> and oink.o. How does it figure out it needs to build moo.c, baa.c and oink.c >>> then? >> >> In what sense is subsystem.o "a combination of moo.o, baa.o, and >> oink.o"? If it's a library file, on the systems I'm familiar with, >> naming conventions require it to have either .a or .so extensions; other > > Yes, .so, typo, point still stands. Then it's the archiver (ar, on the systems I normally use) that puts it together, not the compiler, so you'll have to insert those dependencies yourself. Note that make files have a syntax for tying a dependency to a particular module withing a library, and not just to the entire library file. As I said: >> you're correct - the compiler can't know. gcc -MD cannot cover all >> dependency issues, but it can automate a large fraction of them, >> reducing the number of dependencies you need to state explicitly in the >> make file itself > > So fairly useless then. Among other things, it makes the make file much more readable. In my experience, the typical C++ object file has hundreds of different header files it depends upon, directly or indirectly, and the specific files it depends upon can change depending upon which compiler options you choose or which version of the compiler you're using. Keep it mind that gcc -MD tracks ALL header dependencies, even those that requiring tracing through a dozen or more different levels of #include directives. Not only would the resulting make file be unreadable, it would also need to be updated frequently, which would be a nightmare. Letting gcc -MD handle the updates is not only much easier, it's also much more reliable than performing those updates manually. If you're comparing gcc -MD with a system like CMake that takes over the task of generating makefiles for you, keep in mind that MisterMule asked his question in the context of his claim that creating CMake files is no easier than creating make files. I'm not sufficiently familiar with CMake to feel at all comfortable using it, but if portability between Windows and Linux were an important concern for me, I would certainly consider it - every alternative I'm aware of is even worse. As long as my code stays in the Linux world, make files are much easier, at least for me.
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-11 09:06 +0000 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shhrht$eou$1@gioia.aioe.org> |
| In reply to | #81154 |
On Fri, 10 Sep 2021 14:17:46 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 9/10/21 1:09 PM, HorseyWorsey@the_stables.com wrote: >>> When it compiles foo.c to create foo.o, it finds the #include >>> "globals.h" directive, and searches for globals.h in the specified >>> search path. Having found that file, it reads it in, replacing the >>> #include directive, and at the same time takes note of that fact that >>> this means that foo.o depends upon globals.h. At this point, it will >>> know the full path name for globals.h, and will generally use that full >>> path name when recording that dependency. The same thing occurs when it >>> compiles baa.c and oink.c. >> >> Catch 22. You'll already need a build system to build those files if they're >> scattered around and hav multiple dependencies so what problem is this >solving? > >MisterMule's original comment on September 8th was about the difficulty >of putting dependencies into a makefile. That implies the use of make, >which is the build system that's relevant. gcc -MD is not intended to >remove the need for make, it's intended for use with make. >The problem that it solves is simplifying the creation of the makefile. Well I just tried it with Clang on a small (1000 line) project. Manually written Makefile is 29 lines. Generated .d files end up at 1305 lines and it failed anyway because one of the .h files is auto generated. A complete waste of time as far as I can see. >The makefile itself needs to identify the dependency file created by gcc >-MD. The only other dependencies it needs to identify are those that >cannot be identified by the use of that option. That is enourmously >easier than inserting all of those dependencies manually, and updating >them as needed. Each to their own. >> Yes, .so, typo, point still stands. > >Then it's the archiver (ar, on the systems I normally use) that puts it >together, not the compiler, so you'll have to insert those dependencies No it isn't. The archiver creates .a files, the compiler generates .so files. Since you don't even know this basic fact there's not much point discussing anything else you wrote.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-09-09 12:41 -0400 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shddgm$rk$3@dont-email.me> |
| In reply to | #81110 |
On 9/9/21 4:54 AM, MisterMule@stubborn.uk wrote: > On Wed, 8 Sep 2021 20:22:52 +0300 > Paavo Helde <myfirstname@osa.pri.ee> wrote: >> 08.09.2021 13:24 MisterMule@stubborn.uk kirjutas: >>> >>> You can write a makefile just as simple. However what happens when you >>> want foo.c recompiled when foo.h and bar.h changes but bar.c should only >>> be recompiled when bar.h and moo.h change, moo.c should only be recompiled >> when >>> moo.h changes and main.c should be recompiled when anything changes? >>> >> >> Such dependencies are taken care automatically by the gcc -MD option, > > No unless the compiler is clairvoyant they arn't. That option causes a dependencies file to be created specifying all the dependencies that the compiler notices during compilation. That file can then be used to avoid unnecessary re-builds the next time the same file is compiled. The dependency file is therefore always one build out-of-date; if you created any new dependencies, or removed any old ones, the dependencies file will be incorrect until after the next time you do a build. It's therefore not a perfect solution - but neither is it useless.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-09 22:17 +0200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shdq5o$stl$1@dont-email.me> |
| In reply to | #81124 |
On 09/09/2021 18:41, James Kuyper wrote:
> On 9/9/21 4:54 AM, MisterMule@stubborn.uk wrote:
>> On Wed, 8 Sep 2021 20:22:52 +0300
>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>> 08.09.2021 13:24 MisterMule@stubborn.uk kirjutas:
>>>>
>>>> You can write a makefile just as simple. However what happens when you
>>>> want foo.c recompiled when foo.h and bar.h changes but bar.c should only
>>>> be recompiled when bar.h and moo.h change, moo.c should only be recompiled
>>> when
>>>> moo.h changes and main.c should be recompiled when anything changes?
>>>>
>>>
>>> Such dependencies are taken care automatically by the gcc -MD option,
>>
>> No unless the compiler is clairvoyant they arn't.
>
> That option causes a dependencies file to be created specifying all the
> dependencies that the compiler notices during compilation. That file can
> then be used to avoid unnecessary re-builds the next time the same file
> is compiled. The dependency file is therefore always one build
> out-of-date; if you created any new dependencies, or removed any old
> ones, the dependencies file will be incorrect until after the next time
> you do a build. It's therefore not a perfect solution - but neither is
> it useless.
>
The trick is to have makefile (or whatever build system you use) rules
along with gcc so that the dependency file not only labels the object
file as dependent on the C or C++ file and all the include files it
uses, recursively, but also labels the dependency file itself to be
dependent on the same files. Then if the source file or includes are
changed, the dependency file is re-created, and make is smart enough to
then reload that dependency file to get the new dependencies for
building the object file.
The makefile rules involved are close to APL in readability, but once
you have figured out what you need, you can re-use it for any other
project. And it solves the problem you have here.
So, for example, if you have these files:
a.h
---
#include "b.h"
b.h
---
#define TEST 1
c.c
---
#include "a.h"
#include <stdio.h>
int main(void) {
printf("Test is %d\n", TEST);
}
Then "gcc -MD c.c" makes a file
c.d
---
c.o: c.c /usr/include/stdc-predef.h a.h b.h /usr/include/stdio.h \
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h \
/usr/include/features.h /usr/include/x86_64-linux-gnu/sys/cdefs.h \
/usr/include/x86_64-linux-gnu/bits/wordsize.h \
...
Using "gcc -MMD c.c" is more helpful, usually, because it skips the
system includes:
c.d
---
c.o: c.c a.h b.h
But the real trick is "gcc -MMD -MT 'c.d c.o' c.c" :
c.d
---
c.d c.o: c.c a.h b.h
Now "make" knows that the dependency file is also dependent on the C
file and headers.
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-10 09:39 +0000 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shf94o$1qjt$1@gioia.aioe.org> |
| In reply to | #81128 |
On Thu, 9 Sep 2021 22:17:59 +0200
David Brown <david.brown@hesbynett.no> wrote:
>On 09/09/2021 18:41, James Kuyper wrote:
>So, for example, if you have these files:
>
>a.h
>---
>#include "b.h"
>
>b.h
>---
>#define TEST 1
>
>c.c
>---
>#include "a.h"
>#include <stdio.h>
>
>int main(void) {
> printf("Test is %d\n", TEST);
>}
>
>
>Then "gcc -MD c.c" makes a file
>
>c.d
>---
>c.o: c.c /usr/include/stdc-predef.h a.h b.h /usr/include/stdio.h \
> /usr/include/x86_64-linux-gnu/bits/libc-header-start.h \
> /usr/include/features.h /usr/include/x86_64-linux-gnu/sys/cdefs.h \
> /usr/include/x86_64-linux-gnu/bits/wordsize.h \
> ...
>
>
>Using "gcc -MMD c.c" is more helpful, usually, because it skips the
>system includes:
>
>c.d
>---
>c.o: c.c a.h b.h
>
>
>But the real trick is "gcc -MMD -MT 'c.d c.o' c.c" :
>
>c.d
>---
>c.d c.o: c.c a.h b.h
Very nice. Now you have a single globals.h type file (VERY common in large
projects). How does gcc figure out which C files it needs to build from that?
>
>
>Now "make" knows that the dependency file is also dependent on the C
>file and headers.
[toc] | [prev] | [next] | [standalone]
Page 7 of 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web