Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.alt.folklore.computer > #44345 > unrolled thread
| Started by | Joerg Walther <joerg.walther@magenta.de> |
|---|---|
| First post | 2024-04-06 09:37 +0200 |
| Last post | 2024-05-15 15:32 +0200 |
| Articles | 20 on this page of 262 — 28 participants |
Back to article view | Back to de.alt.folklore.computer
Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-06 09:37 +0200
Re: Triumph of the Nerds Michael Pachta <mipani@gmx.de> - 2024-04-06 10:06 +0200
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-06 11:37 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-04-06 11:14 +0200
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-06 11:39 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-04-08 12:27 +0200
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-08 13:33 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-17 17:33 +0000
Re: Triumph of the Nerds Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-04-18 08:46 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-04-18 19:41 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-04-19 18:44 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-04-20 22:34 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-21 17:18 +0200
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-04-24 07:41 +0200
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-04-24 08:49 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-04-24 11:38 +0200
Re: Triumph of the Nerds Michael Kraemer <m.kraemer@gsi.de> - 2024-04-24 16:28 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-04-24 18:55 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-24 20:53 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-04-30 13:33 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:11 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:15 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-02 18:49 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-02 21:14 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-02 21:16 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-03 07:46 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-03 20:21 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-03 22:03 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-04 07:14 +0000
Re: Triumph of the Nerds Michael Kraemer <m.kraemer@gsi.de> - 2024-05-04 09:37 +0200
C (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-04 11:23 +0200
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-04 13:17 +0200
Re: C Michael Kraemer <m.kraemer@gsi.de> - 2024-05-04 14:47 +0200
Re: C Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:43 +0200
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 09:41 +0200
Re: C "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 02:08 +0200
Re: C Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:41 +0200
Re: C Ralf Damaschke <rwspam@gmx.de> - 2024-05-05 16:02 +0000
Re: C Ralf Damaschke <rwspam@gmx.de> - 2024-05-05 23:47 +0000
Re: C "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 19:55 +0200
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 09:50 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-04 11:26 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-04 10:01 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-04 12:19 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:47 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-04 13:20 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-04 09:09 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-04 11:23 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-05 10:16 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:18 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-06 18:41 +0200
Pascal (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-06 19:55 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 06:40 +0200
Re: Pascal "F. W." <me@home.invalid> - 2024-05-07 07:48 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 08:26 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 13:04 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 14:57 +0200
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 13:11 +0000
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 13:55 +0000
Re: Pascal "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 21:33 +0200
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 07:42 +0000
Re: Pascal Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 12:09 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 12:37 +0200
Re: Pascal Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 12:42 +0200
Re: Pascal Andreas Bockelmann <xotzil@gmx.de> - 2024-05-12 11:36 +0200
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-12 13:42 +0000
Re: Pascal Andreas Bockelmann <xotzil@gmx.de> - 2024-05-12 19:19 +0200
Re: Pascal Andreas Karrer <ak-4a@gmx.ch> - 2024-05-12 21:39 +0000
Re: Pascal "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 16:09 +0200
Re: Pascal Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 17:49 +0200
Re: Pascal Stefan Reuther <stefan.news@arcor.de> - 2024-05-12 20:56 +0200
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-12 19:46 +0000
Re: Pascal Peter Müller <invalid@invalid.invalid> - 2024-05-12 22:00 +0200
Re: Pascal Stefan Reuther <stefan.news@arcor.de> - 2024-05-07 18:16 +0200
Re: Pascal "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 20:20 +0200
Re: Pascal Stefan Reuther <stefan.news@arcor.de> - 2024-05-12 21:13 +0200
Re: Pascal Stefan Reuther <stefan.news@arcor.de> - 2024-05-13 10:39 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-07 09:20 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-07 18:03 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-08 04:13 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-08 12:01 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-05-13 01:54 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-13 10:51 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-13 13:45 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-13 14:04 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-13 17:23 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-05 11:22 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 15:57 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-05 18:30 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 21:54 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 13:04 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-06 11:45 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 20:53 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 08:42 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 21:56 +0000
Accidental Complexity von Programmiersprachen (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 21:06 +0200
Re: Accidental Complexity von Programmiersprachen (was: Triumph of the Nerds) Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 07:31 +0000
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 10:12 +0200
Re: Accidental Complexity von Programmiersprachen Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 13:03 +0000
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 16:03 +0200
Re: Accidental Complexity von Programmiersprachen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 16:57 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 17:36 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 18:52 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-10 03:49 +0200
Re: Accidental Complexity von Programmiersprachen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 19:22 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-10 04:07 +0200
Re: Accidental Complexity von Programmiersprachen Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 17:00 +0000
Re: Accidental Complexity von Programmiersprachen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 20:25 +0200
Re: Accidental Complexity von Programmiersprachen Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 20:55 +0000
Re: Accidental Complexity von Programmiersprachen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 23:53 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-10 04:26 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 20:53 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-08 20:09 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 12:50 +0200
Yoda expressions (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-06 19:39 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 14:16 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-06 19:04 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:28 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-05 18:33 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 13:09 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 21:01 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 20:01 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-08 20:15 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 12:18 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-09 16:36 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:37 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 19:51 +0200
Re: Triumph of the Nerds "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-05-06 07:41 +0000
C (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-06 19:13 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 09:58 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 10:34 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 14:00 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 19:57 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-06 12:06 +0000
C (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-06 19:29 +0200
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 06:49 +0200
Re: C Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 06:30 +0000
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 09:42 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-06 18:55 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 21:03 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 06:32 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 09:44 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 08:26 +0000
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-07 18:13 +0200
Re: Triumph of the Nerds Thomas Klix <wotokl@web.de> - 2024-05-07 21:50 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 21:49 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 22:16 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 22:10 +0000
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-08 08:40 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-08 14:19 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-08 15:14 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-08 18:16 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-08 17:30 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 12:20 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 12:19 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 17:52 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-09 16:43 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 16:48 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-09 16:40 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 14:26 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-09 16:38 +0000
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-12 21:09 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-02 19:46 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-02 18:44 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-03 22:09 +0200
Re: Triumph of the Nerds Christian Corti <use@reply.to> - 2024-05-06 12:58 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-06 15:07 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 21:06 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-04-30 17:40 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-01 07:17 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-01 09:10 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:40 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-01 12:18 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 20:44 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-02 07:31 +0200
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-05-02 05:54 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-03 09:25 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-03 08:35 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-03 11:20 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-03 22:13 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-03 21:14 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-06 07:48 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-03 22:12 +0200
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-06 07:49 +0200
Re: Triumph of the Nerds Markus Elsken <markus.elsken@ewetel.net> - 2024-05-06 23:53 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 06:34 +0000
Re: Triumph of the Nerds Markus Elsken <markus.elsken@ewetel.net> - 2024-05-07 22:48 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-08 06:35 +0000
Re: Triumph of the Nerds Markus Elsken <markus.elsken@ewetel.net> - 2024-05-09 15:37 +0200
Re: Triumph of the Nerds Andreas Eder <a_eder_muc@web.de> - 2024-05-09 22:53 +0200
Re: Triumph of the Nerds Markus Elsken <markus.elsken@ewetel.net> - 2024-05-10 01:05 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-07 16:09 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-02 19:31 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-02 19:50 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:07 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-24 09:08 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-04-24 11:40 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-24 17:31 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-24 20:57 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-25 10:04 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-25 08:59 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-04-25 11:52 +0000
Re: Triumph of the Nerds Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2024-04-25 14:47 +0000
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-25 18:59 +0200
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-26 15:38 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 07:13 +0200
Re: Triumph of the Nerds Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2024-04-26 13:04 +0000
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-05-15 19:45 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-27 10:42 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-04-27 13:18 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:25 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-04-30 14:40 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-02 19:01 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-05-02 20:18 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-03 22:46 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-05-04 02:02 +0000
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-04-28 01:40 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-29 06:26 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-29 16:11 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-30 11:32 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-30 11:13 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:33 +0000
Re: Triumph of the Nerds Thomas Klix <wotokl@web.de> - 2024-04-30 16:30 +0200
Re: Triumph of the Nerds Thomas Klix <wotokl@web.de> - 2024-04-30 16:46 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-02 19:16 +0000
Re: Triumph of the Nerds Christian Corti <use@reply.to> - 2024-05-06 13:07 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 16:03 +0200
Re: Triumph of the Nerds Christian Corti <use@reply.to> - 2024-05-06 18:10 +0200
Re: Triumph of the Nerds Thomas Klix <wotokl@web.de> - 2024-05-06 21:53 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 21:08 +0000
Re: Triumph of the Nerds Guido Grohmann <guido.grohmann@gmx.de> - 2024-05-07 06:59 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 08:28 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-07 16:10 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 22:15 +0000
Re: Triumph of the Nerds Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-05-08 08:42 +0200
Re: Triumph of the Nerds Guido Grohmann <guido.grohmann@gmx.de> - 2024-05-07 16:51 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-07 17:42 +0200
Re: Triumph of the Nerds Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-04-30 15:10 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-04-30 19:08 +0200
Re: Triumph of the Nerds Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-05-01 08:15 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:49 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:46 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:34 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-30 18:34 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:50 +0000
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-24 16:59 +0200
Re: Triumph of the Nerds "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-04-28 19:35 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-04-28 20:24 +0000
Re: Triumph of the Nerds "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-04-28 23:26 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:43 +0000
Re: Triumph of the Nerds "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-05-02 20:07 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-02 20:48 +0200
Re: Triumph of the Nerds "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-05-03 23:15 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-04 10:00 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-04 11:33 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-05-15 15:14 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-04-29 13:21 +0200
Re: Triumph of the Nerds Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-04-30 07:33 +0200
Re: Triumph of the Nerds Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-04-30 17:55 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:54 +0000
Re: Triumph of the Nerds Andreas Eder <a_eder_muc@web.de> - 2024-04-30 22:57 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-05-15 15:32 +0200
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-06 09:50 +0200 |
| Subject | Re: C |
| Message-ID | <l9rgdoF7i5bU1@mid.individual.net> |
| In reply to | #44508 |
Am 05.05.24 um 19:55 schrieb Peter J. Holzer: > Das nützt aber nichts, wenn pointer in ein Array zeigt (was im Kontext > "strcpy() & Co" der Fall war), Denn da will man nicht die Größe eines > Elements wissen, sondern die des gesamten Arrays. Wenn die Zahl der Elemente bekannt ist kann einiges berechnet werden. Das ist besonders interessant, wenn man mit dynamischen arrays arbeitet, deren Länge den Bedarf angepasst wird. Zur Verwaltung gibt es 3 Variablen>: struct xy_ *xy_p; int alloc_xy, used_xy; <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-04 11:26 +0200 |
| Message-ID | <l9md9fFeg3dU9@mid.individual.net> |
| In reply to | #44477 |
Thomas Koenig, 2024-05-04 09:14: > Arno Welzel <usenet@arnowelzel.de> schrieb: >> Stefan Ram, 2024-05-02 21:11: >> >>> Sebastian Barthel <naitsabes@freenet.de> wrote or quoted: >>>> Ich stimme ja voll zu, daß es eigenartig ist, daß da immer noch ein >>>> Layer draufgepackt wird und man so immer mehr "Zeug" anhäuft. >>> >>> Ein Beispiel wäre die Speicherverwaltung. >>> >>> C hat eine Speicherverwaltung, bei welcher der Programmierer viel >>> arbeiten muß und viel falsch machen kann. >> >> Genau genommen hat C *keine* Speicherverwaltung. Genau das ist ja das >> Problem. > > Stimmt so nach der C-Norm nicht... > >> malloc() und free() sind keine Sprachkonstrukte von C sondern nur >> Aufrufe an das Betriebssystem, für die Prozess eine Speicherblock mit >> einer bestimmten Größe zu reservieren. Die Größe des Blockes zu >> beachten, wenn man z.B. Daten dort hin schreiben lässt, obliegt allein >> dem Programmierer. > > Das ist so nicht korrekt. Die Funktionen malloc() und Freunde > sind in der C-Norm definiert. Ihr Verhalten ist genauso durch die > Norm festgelegt wie das von anderen Sprachkonstrukten (solange sie > "external linkage" haben). Ok, sie sind definiert. Ändert aber nichts daran, dass ein Pointer, der von malloc() geliefert wird, eben nur ein Pointer ist und aus Sicht von C nirgends gespeichert wird, wie große der Block eigentlich ist, der damit allokiert wurde. [...] >> C selbst ist völlig egal, ob der Programmierer in einen 10 KB großen >> Block versucht, 20 KB Daten aus einer Datei abzulegen. > > Das ist "undefined behavior", damit ist es (vereinfacht :-) verboten, > insofern ist es nicht egal. Doch, ist es. Der Compiler frisst das anstandslos und zur Laufzeit wird das auch nicht verhindert. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-04 10:01 +0000 |
| Message-ID | <v1512j$158cb$1@dont-email.me> |
| In reply to | #44483 |
Arno Welzel <usenet@arnowelzel.de> schrieb: > Thomas Koenig, 2024-05-04 09:14: > >> Arno Welzel <usenet@arnowelzel.de> schrieb: >>> C selbst ist völlig egal, ob der Programmierer in einen 10 KB großen >>> Block versucht, 20 KB Daten aus einer Datei abzulegen. >> >> Das ist "undefined behavior", damit ist es (vereinfacht :-) verboten, >> insofern ist es nicht egal. > > Doch, ist es. Der Compiler frisst das anstandslos und zur Laufzeit wird > das auch nicht verhindert. Sanitizer können das verhindern. Aber natürlich ist eine Sprache, die Arrays und Strings als Datentypen hat und auch mitverfolgt, wie groß die sind, deutlich weniger fehleranfällig, da sind wir uns einig.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-04 12:19 +0200 |
| Message-ID | <slrnv3c2tj.12d8d.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44483 |
On 2024-05-04 09:26, Arno Welzel <usenet@arnowelzel.de> wrote:
> Thomas Koenig, 2024-05-04 09:14:
>> Arno Welzel <usenet@arnowelzel.de> schrieb:
>>> malloc() und free() sind keine Sprachkonstrukte von C sondern nur
>>> Aufrufe an das Betriebssystem, für die Prozess eine Speicherblock mit
>>> einer bestimmten Größe zu reservieren. Die Größe des Blockes zu
>>> beachten, wenn man z.B. Daten dort hin schreiben lässt, obliegt allein
>>> dem Programmierer.
>>
>> Das ist so nicht korrekt. Die Funktionen malloc() und Freunde
>> sind in der C-Norm definiert. Ihr Verhalten ist genauso durch die
>> Norm festgelegt wie das von anderen Sprachkonstrukten (solange sie
>> "external linkage" haben).
>
> Ok, sie sind definiert. Ändert aber nichts daran, dass ein Pointer, der
> von malloc() geliefert wird, eben nur ein Pointer ist und aus Sicht von
> C nirgends gespeichert wird, wie große der Block eigentlich ist, der
> damit allokiert wurde.
Das stimmt nicht. Praktisch jede C-Implementation speichert diese
Information, sonst würde free() ja nicht funktionieren (Woher wüsste
das, wieviel Speicher es freigeben soll?)
Was die Sprache C allerdings nicht vorsieht, ist eine Möglichkeit, diese
Information für andere Zwecke als die Speicherverwaltung selbst zu
verwenden, z.B. für eine Bereichsüberprüfung. Da ist der Programmierer
selbst dafür verantwortlich, dafür zu sorgen, dass er nur auf
existierende Objekte zugreift, und wenn er es nicht tut, ist das
"undefined behavior" (d.h. der C-Standard trifft keine Aussage und die
Implementation kann machen was sie will).
Eine Implementation von C, die Bereichsüberprüfungen zur Laufzeit
durchführt, wäre möglich, und es gab solche auch. Sie wäre aber mit den
existierenden ABIs nicht kompatibel - man müsste also nicht nur das
Programm, sondern auch alle Librarys neu kompilieren oder eine
(proprietäre) Möglichkeit vorsehen, für jede Deklaration das ABI zu
definieren. Außerdem wäre sie langsamer, möglicherweise signifikant
langsamer.
hp
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-05 16:47 +0200 |
| Message-ID | <l9pkgvFsmkrU14@mid.individual.net> |
| In reply to | #44486 |
Peter J. Holzer, 2024-05-04 12:19: [...] > Was die Sprache C allerdings nicht vorsieht, ist eine Möglichkeit, diese > Information für andere Zwecke als die Speicherverwaltung selbst zu > verwenden, z.B. für eine Bereichsüberprüfung. Da ist der Programmierer > selbst dafür verantwortlich, dafür zu sorgen, dass er nur auf > existierende Objekte zugreift, und wenn er es nicht tut, ist das > "undefined behavior" (d.h. der C-Standard trifft keine Aussage und die > Implementation kann machen was sie will). Eben! Genau das meine ich ja damit. Aus Sicht des Codes, den der Entwickler schreibt, ist ein Pointer immer nur die Angabe einer Speicheradresse ohne weitere Informationen über die Größe des Speicherbereichs, der damit adressiert wird. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-04 13:20 +0200 |
| Message-ID | <l9mjvgFfjm4U2@mid.individual.net> |
| In reply to | #44483 |
Am 04.05.24 um 11:26 schrieb Arno Welzel: > Ok, sie sind definiert. Ändert aber nichts daran, dass ein Pointer, der > von malloc() geliefert wird, eben nur ein Pointer ist und aus Sicht von > C nirgends gespeichert wird, wie große der Block eigentlich ist, der > damit allokiert wurde. Man hat früher u.a. mit array Grenzen Überschreitung sein Programm abgeändert.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2024-05-04 09:09 +0200 |
| Message-ID | <v14u0g.4hk.1@stefan.msgid.phost.de> |
| In reply to | #44469 |
Am 03.05.2024 um 22:03 schrieb Arno Welzel:
> Stefan Ram, 2024-05-02 21:11:
>> Sebastian Barthel <naitsabes@freenet.de> wrote or quoted:
>>> Ich stimme ja voll zu, daß es eigenartig ist, daß da immer noch ein
>>> Layer draufgepackt wird und man so immer mehr "Zeug" anhäuft.
>>
>> Ein Beispiel wäre die Speicherverwaltung.
>>
>> C hat eine Speicherverwaltung, bei welcher der Programmierer viel
>> arbeiten muß und viel falsch machen kann.
>
> Genau genommen hat C *keine* Speicherverwaltung. Genau das ist ja das
> Problem.
[...]
>> Nun wurde ja neulich eine Warnung aus der Regierung der Vereinigten
>> Staaten vor solchen Sprachen wie C bekannt. Sie seien fehlerträchtig
>> und daher riskant.
>
> Ja, zurecht.
Auf irgendeiner Ebene in dem Stapel braucht es eine Sprache wie C. Zum
Beispiel, um darin einen Python-Interpreter zu schreiben.
>> Python hat eine Speicherverwaltung, die auf der von C aufbaut, aber
>> vieles automatisiert. Sie ist für Programmierer einfacher und weniger
>> fehlerträchtig. Also eine Art von "Schicht".
>
> Zumindest *weiß* Python wie groß Speicherblöcke sind und kennt auch
> Garbage Collection. Das ist um Größenordnungen zuverlässiger als C.
Ja, Python weiß das, weil jemand ein C-Programm geschrieben hat, dass
diese Informationen mitführt und überprüft. Deswegen ist "verbietet C"
weder möglich noch sinnvoll.
>> Zwei Fehler, die ich sehe:
>>
>> 1.) (Besonders früher) C und C++ wurden für Anfängerkurse eingesetzt,
>> wodurch der falsche Eindruck entstand, daß es einfach beherrschbare
>> Sprachen seien.
>
> An welchen "Anfängerkurse" denkst Du hier? BASIC wurde bereits 1964
> entwickelt und wesentlich häufiger gerade im Bereich von Schule und
> Ausbildung für "Anfänger" genutzt. Wenn es etwas anspruchsvoller sein
> sollte, dann Pascal, was auch schon 1972 explizit als Lehrsprache
> entwickelt wurde.
In meinem Informatikstudium wurde auf Protest der angehenden Dipl.Infe
hin der Anfängerkurs von Modula-2 ("das kann man doch nirgends mehr
gebrauchen") auf C umgestellt. Ich hab dem Professor noch rechtzeitig
mitteilen können, dass 'realloc(p, n)' nicht das Äquivalent zu
'DEALLOCTE(p, n)' ist. Der wäre lieber bei Modula-2 geblieben.
>> Ich halte C und C++ für großartige und unverzichtbare Sprachen (man
>> muß sehen, inwiefern Rust oder Go ein Ersatz sein können), aber für
>> sie muß man richtig ausgebildet und ausgewählt worden sein!
>
> C ist ein etwas besserer Makroassembler (Makros hat C ja auch von
> Assemblern übernommen) und C++ baut im Kern auf C auf und erbt damit
> auch alle "Schweinereien" von C. Einzig durch Code-Analyse von Compilern
> hofft man, die größten Löcher schon vor dem Einsatz des Programms finden
> zu können. Aber die ganzen Schichten mit Templates und STL sind nichts
> anderes als eine Verschönerung der Syntax ohne echten Sicherheitsgewinn
> der Sprasche.
Der Sicherheitsgewinn entsteht durch konsequente Verwendung der neuen
Abstraktionen.
Das kann man natürlich machen, indem man eine weitere Programmiersprache
draufsetzt (wir könnten sie "Python" nennen), die nur die sicheren
Konstrukte zu benutzen erlaubt. Oder eben durch Code-Analyse in
Compilern oder anderen Tools.
Gerade C++ erlaubt mit std::shared_ptr und std::span das Lösen einer
ganzen Menge von Problemen, die man sich mit nackten Pointern in C
eintritt. Ich nutze das Äquivalent davon seit Jahrzehnten in meinem Code
und kann mich an keine Buffer-Overruns darin mehr erinnern. Man baut
dafür komplexere Probleme, z.B. Thread-Deadlocks :)
>> Dann wird C++ damit beworben, daß gleichwertige Software in C++ in
>> der Regel weniger Energie verbraucht als in höheren Sprachen
>> (weniger Schichten). Ja, das ist ein starkes Argument für C++ bei
>> immer mehr exergiehungrigen Rechenzentren. Aber man muß C++ eben auch
>> können.
>
> Viele der einst als "langsam" und "ineffizent" betrachtete Sprachen
> arbeiten mittlerweile mit Compilern, und wenn es auch nur
> Just-in-time-Compiler sind. Das holt *sehr* viel raus. Node.js oder
> Kotlin sind durchaus ernstzunehmende Umgebungen.
Auch wenn ich dem letzten Satz zustimme, ist das aber kein Gewinn
bezüglich Sicherheit oder Komplexität.
JIT heißt, dass ich zu jeder Zeit irgendein hochkomplexes Stück (C-)Code
laufen habe, das meinen (z.B.) JavaScript-Code bewertet und
transformiert. Ich kann also keine Vorhersagen mehr treffen, welchen
Maschinencode der Prozessor ausführen wird, wie der im Speicher
angeordnet ist usw.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-04 11:23 +0200 |
| Message-ID | <l9md5eFeg3dU8@mid.individual.net> |
| In reply to | #44478 |
Stefan Reuther, 2024-05-04 09:09: > Am 03.05.2024 um 22:03 schrieb Arno Welzel: >> Stefan Ram, 2024-05-02 21:11: [...] >>> Nun wurde ja neulich eine Warnung aus der Regierung der Vereinigten >>> Staaten vor solchen Sprachen wie C bekannt. Sie seien fehlerträchtig >>> und daher riskant. >> >> Ja, zurecht. > > Auf irgendeiner Ebene in dem Stapel braucht es eine Sprache wie C. Zum > Beispiel, um darin einen Python-Interpreter zu schreiben. Den kann man auch in anderen Sprachen schreiben. C ist nicht die einzige Sprache, mit der man compilierte Binaries erstellen kann. [...] >> Zumindest *weiß* Python wie groß Speicherblöcke sind und kennt auch >> Garbage Collection. Das ist um Größenordnungen zuverlässiger als C. > > Ja, Python weiß das, weil jemand ein C-Programm geschrieben hat, dass > diese Informationen mitführt und überprüft. Deswegen ist "verbietet C" > weder möglich noch sinnvoll. Siehe oben - es gibt nicht nur C. [...] >> C ist ein etwas besserer Makroassembler (Makros hat C ja auch von >> Assemblern übernommen) und C++ baut im Kern auf C auf und erbt damit >> auch alle "Schweinereien" von C. Einzig durch Code-Analyse von Compilern >> hofft man, die größten Löcher schon vor dem Einsatz des Programms finden >> zu können. Aber die ganzen Schichten mit Templates und STL sind nichts >> anderes als eine Verschönerung der Syntax ohne echten Sicherheitsgewinn >> der Sprasche. > > Der Sicherheitsgewinn entsteht durch konsequente Verwendung der neuen > Abstraktionen. Die sind aber freiwillig. Also werden auch Programme geschrieben, die schlicht unsicher sind, weil jemand sich nicht konsequent an Abstraktionen gehalten hat. [...] >> Viele der einst als "langsam" und "ineffizent" betrachtete Sprachen >> arbeiten mittlerweile mit Compilern, und wenn es auch nur >> Just-in-time-Compiler sind. Das holt *sehr* viel raus. Node.js oder >> Kotlin sind durchaus ernstzunehmende Umgebungen. > > Auch wenn ich dem letzten Satz zustimme, ist das aber kein Gewinn > bezüglich Sicherheit oder Komplexität. > > JIT heißt, dass ich zu jeder Zeit irgendein hochkomplexes Stück (C-)Code > laufen habe, das meinen (z.B.) JavaScript-Code bewertet und > transformiert. Ich kann also keine Vorhersagen mehr treffen, welchen > Maschinencode der Prozessor ausführen wird, wie der im Speicher > angeordnet ist usw. Wieso glaubst Du so beharrlich daran, dass Binaries ausschliesslich in in C geschrieben sind? C/C++ mag noch einen großen Anteil haben, aber es gibt mittlerweile eine Reihe von Alternativen. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2024-05-05 10:16 +0200 |
| Message-ID | <v17mad.2og.1@stefan.msgid.phost.de> |
| In reply to | #44482 |
Am 04.05.2024 um 11:23 schrieb Arno Welzel:
> Stefan Reuther, 2024-05-04 09:09:
>> Am 03.05.2024 um 22:03 schrieb Arno Welzel:
>>> Stefan Ram, 2024-05-02 21:11:
> [...]
>>>> Nun wurde ja neulich eine Warnung aus der Regierung der Vereinigten
>>>> Staaten vor solchen Sprachen wie C bekannt. Sie seien fehlerträchtig
>>>> und daher riskant.
>>>
>>> Ja, zurecht.
>>
>> Auf irgendeiner Ebene in dem Stapel braucht es eine Sprache wie C. Zum
>> Beispiel, um darin einen Python-Interpreter zu schreiben.
>
> Den kann man auch in anderen Sprachen schreiben. C ist nicht die einzige
> Sprache, mit der man compilierte Binaries erstellen kann.
Deswegen sagte ich "eine Sprache wie C", nicht "C".
Aber du kannst ja gerne mal eine nennen, die du im Sinne hattest.
Ich erinnere mich da zum Beispiel an einen "beweisbar sicheren
DNS-Server" in SPARK Ada. Ja, wenn man das Ding statisch auf 64 RRs pro
Typ und 64 Typen limitiert, braucht man keine Speicerverwaltung mehr,
und dann ist das sicher. Aber dann funktioniert es nicht, wenn man 65
RRs braucht, und verschwendet Speicher, wenn man nur einen hat.
>> Der Sicherheitsgewinn entsteht durch konsequente Verwendung der neuen
>> Abstraktionen.
>
> Die sind aber freiwillig. Also werden auch Programme geschrieben, die
> schlicht unsicher sind, weil jemand sich nicht konsequent an
> Abstraktionen gehalten hat.
Richtig. Aber auch in Python ist die Verwendung korrekter Abstraktionen
freiwillig. Ja, das *eine* Problem, die Freispeicherverwaltung, ist
gelöst. Path-Traversal oder SQL-Injection muss man schön selbst verhindern.
>> JIT heißt, dass ich zu jeder Zeit irgendein hochkomplexes Stück (C-)Code
>> laufen habe, das meinen (z.B.) JavaScript-Code bewertet und
>> transformiert. Ich kann also keine Vorhersagen mehr treffen, welchen
>> Maschinencode der Prozessor ausführen wird, wie der im Speicher
>> angeordnet ist usw.
>
> Wieso glaubst Du so beharrlich daran, dass Binaries ausschliesslich in
> in C geschrieben sind? C/C++ mag noch einen großen Anteil haben, aber es
> gibt mittlerweile eine Reihe von Alternativen.
Wie gesagt, nenne mal eine.
Gerade sowas wie einen JIT zu bauen braucht eine Sprache wie C. Man
erstellt erst den Maschinencode als Daten, castet dann einen
Daten-Pointer in einen Funktions-Pointer, und ruft den auf.
Typischerweise nimmt man C, weil das halt der Industriestandard ist. Man
kann das auch in anderer Syntax schreiben, aber z.B. ein entsprechend
aufgebohrtes Pascal ist in dem Sinne auch nur C mit anderer Syntax.
type tfunc = function:integer;
pfunc = ^tfunc;
var a : longint;
p : pfunc;
begin
a := $c31234b8;
p := pfunc(@a);
writeln(p^);
end.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-05 16:18 +0200 |
| Message-ID | <l9piqjFsmkrU9@mid.individual.net> |
| In reply to | #44494 |
Stefan Reuther, 2024-05-05 10:16: > Am 04.05.2024 um 11:23 schrieb Arno Welzel: >> Stefan Reuther, 2024-05-04 09:09: >>> Am 03.05.2024 um 22:03 schrieb Arno Welzel: >>>> Stefan Ram, 2024-05-02 21:11: >> [...] >>>>> Nun wurde ja neulich eine Warnung aus der Regierung der Vereinigten >>>>> Staaten vor solchen Sprachen wie C bekannt. Sie seien fehlerträchtig >>>>> und daher riskant. >>>> >>>> Ja, zurecht. >>> >>> Auf irgendeiner Ebene in dem Stapel braucht es eine Sprache wie C. Zum >>> Beispiel, um darin einen Python-Interpreter zu schreiben. >> >> Den kann man auch in anderen Sprachen schreiben. C ist nicht die einzige >> Sprache, mit der man compilierte Binaries erstellen kann. > > Deswegen sagte ich "eine Sprache wie C", nicht "C". > > Aber du kannst ja gerne mal eine nennen, die du im Sinne hattest. Rust ist schon ein guter Kandidat, wenn es um Sicherheit geht. Aber wenn es generell um Binaries geht, die nicht erst durch eine Laufzeitumgebung ausgeführt werden müssen: diverse BASIC-Varianten, Pascal, Eiffel, Go, Haskell, Lisp... > Ich erinnere mich da zum Beispiel an einen "beweisbar sicheren > DNS-Server" in SPARK Ada. Ja, wenn man das Ding statisch auf 64 RRs pro > Typ und 64 Typen limitiert, braucht man keine Speicerverwaltung mehr, > und dann ist das sicher. Aber dann funktioniert es nicht, wenn man 65 > RRs braucht, und verschwendet Speicher, wenn man nur einen hat. Ja, sowas meine ich aber nicht, sondern die Vermeidung von Pointern ohne Information darüber, wie groß der Adressbereich ist, der über den Pointer angesprochen werden darf und eine zuverlässige Verhinderung von Buffer Overflow. Das alleine verhindert sich eine sehr große Zahl Sicherheitsproblemen. [...] >> Die sind aber freiwillig. Also werden auch Programme geschrieben, die >> schlicht unsicher sind, weil jemand sich nicht konsequent an >> Abstraktionen gehalten hat. > > Richtig. Aber auch in Python ist die Verwendung korrekter Abstraktionen > freiwillig. Ja, das *eine* Problem, die Freispeicherverwaltung, ist > gelöst. Path-Traversal oder SQL-Injection muss man schön selbst verhindern. Eben - und Themen wie Path-Traversal und SQL-Injection haben auch nichts mehr mit der Sprache selbst zu tun, sondern mit der Arbeitsweise von Dateisystemen oder Datenbanken. >> Wieso glaubst Du so beharrlich daran, dass Binaries ausschliesslich in >> in C geschrieben sind? C/C++ mag noch einen großen Anteil haben, aber es >> gibt mittlerweile eine Reihe von Alternativen. > > Wie gesagt, nenne mal eine. Siehe oben. Aus einem Quelltext ein Binary in Maschinensprache zu zu erzeugen war lange Zeit der Normalzustand, als Computer noch nicht so schnell waren, dass der Zeitverlust durch eine Runtime für Bytecode vernachlässigbar war. > Gerade sowas wie einen JIT zu bauen braucht eine Sprache wie C. Man > erstellt erst den Maschinencode als Daten, castet dann einen > Daten-Pointer in einen Funktions-Pointer, und ruft den auf. Ja, eine Sprache *wie* C, das muss aber nicht C selbst sein und auch nicht prinzipbedingt eine Sprache, die Buffer Overflows oder Zugriff auf undültige Pointer aufgrund ihres Designs nicht verhindern kann, weil die nötigen Prüfungen zu lange dauern würden. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2024-05-06 18:41 +0200 |
| Message-ID | <v1b88p.5g4.1@stefan.msgid.phost.de> |
| In reply to | #44498 |
Am 05.05.2024 um 16:18 schrieb Arno Welzel: > Stefan Reuther, 2024-05-05 10:16: >>>> Auf irgendeiner Ebene in dem Stapel braucht es eine Sprache wie C. Zum >>>> Beispiel, um darin einen Python-Interpreter zu schreiben. >>> >>> Den kann man auch in anderen Sprachen schreiben. C ist nicht die einzige >>> Sprache, mit der man compilierte Binaries erstellen kann. >> >> Deswegen sagte ich "eine Sprache wie C", nicht "C". >> >> Aber du kannst ja gerne mal eine nennen, die du im Sinne hattest. > > Rust ist schon ein guter Kandidat, wenn es um Sicherheit geht. Braucht halt immer noch 'unsafe', um interessante Dinge wie eine Speicherverwaltung zu implementieren. Es ist natürlich zweifelsohne ein Fortschritt, die potenziell unsicheren Teile zu markieren. > Aber wenn es generell um Binaries geht, die nicht erst durch eine > Laufzeitumgebung ausgeführt werden müssen: diverse BASIC-Varianten, > Pascal, Eiffel, Go, Haskell, Lisp... Pascal ist nicht besser als C. Da kann man genauso mit Casts und Zeigern rumferkeln. Haskell und Lisp brauchen eine in C oder vergleichbar geschriebene Runtime, wenigstens für den Garbage Collector. >> Ich erinnere mich da zum Beispiel an einen "beweisbar sicheren >> DNS-Server" in SPARK Ada. Ja, wenn man das Ding statisch auf 64 RRs pro >> Typ und 64 Typen limitiert, braucht man keine Speicerverwaltung mehr, >> und dann ist das sicher. Aber dann funktioniert es nicht, wenn man 65 >> RRs braucht, und verschwendet Speicher, wenn man nur einen hat. > > Ja, sowas meine ich aber nicht, sondern die Vermeidung von Pointern ohne > Information darüber, wie groß der Adressbereich ist, der über den > Pointer angesprochen werden darf und eine zuverlässige Verhinderung von > Buffer Overflow. Das alleine verhindert sich eine sehr große Zahl > Sicherheitsproblemen. Wie gesagt, *das* Problem kann man auch mit Dingen wie std::span lösen. Ich mach das seit Jahrzehnten. Nur dauert es halt leider ewig, bis auch alle passenden APIs entsprechend gewrapped sind: Datei-I/O, Netzwerk, TLS, Grafik, etc. Aber das ist nur eins von vielen Problemen. Das Problem "use-after-free" löst auch ein Pointer mit Größeninformation nicht. >>> Wieso glaubst Du so beharrlich daran, dass Binaries ausschliesslich in >>> in C geschrieben sind? C/C++ mag noch einen großen Anteil haben, aber es >>> gibt mittlerweile eine Reihe von Alternativen. >> >> Wie gesagt, nenne mal eine. > > Siehe oben. Aus einem Quelltext ein Binary in Maschinensprache zu zu > erzeugen war lange Zeit der Normalzustand, als Computer noch nicht so > schnell waren, dass der Zeitverlust durch eine Runtime für Bytecode > vernachlässigbar war. Also die typischen 8-Bitter haben ihr BASIC interpretiert, weil das einfacher war als zu compilieren. Und auch die Sprache B, Vorgänger von C, gedacht für Systemprogrammierung auf PDP-7, hat nicht nativ compiliert, sondern nur threaded code von einer Runtime ausführen lassen. Gut, jene Runtimes waren aus Kausalitätsgründen zumindest nicht in C geschrieben.... Stefan
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-06 19:55 +0200 |
| Subject | Pascal (was: Triumph of the Nerds) |
| Message-ID | <slrnv3i6dc.1b9so.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44538 |
On 2024-05-06 16:41, Stefan Reuther <stefan.news@arcor.de> wrote:
> Pascal ist nicht besser als C. Da kann man genauso mit Casts und Zeigern
> rumferkeln.
In Standard-Pascal? Oder in diversen verbreiteten Dialekten wie
Turbo-Pascal?
hp
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-07 06:40 +0200 |
| Subject | Re: Pascal |
| Message-ID | <l9tplpFi3utU1@mid.individual.net> |
| In reply to | #44542 |
Am 06.05.24 um 19:55 schrieb Peter J. Holzer: > On 2024-05-06 16:41, Stefan Reuther <stefan.news@arcor.de> wrote: >> Pascal ist nicht besser als C. Da kann man genauso mit Casts und Zeigern >> rumferkeln. > > In Standard-Pascal? Oder in diversen verbreiteten Dialekten wie > Turbo-Pascal? In Pascal ST ginge es nach meiner Erinnerung nicht (direkt). Da musste ich mit Assembler erheblich tricksen. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | "F. W." <me@home.invalid> |
|---|---|
| Date | 2024-05-07 07:48 +0200 |
| Subject | Re: Pascal |
| Message-ID | <v1cfbe$47m0$1@solani.org> |
| In reply to | #44542 |
Am 06.05.2024 um 19:55 schrieb Peter J. Holzer: > On 2024-05-06 16:41, Stefan Reuther <stefan.news@arcor.de> wrote: >> Pascal ist nicht besser als C. Da kann man genauso mit Casts und >> Zeigern rumferkeln. > > In Standard-Pascal? Oder in diversen verbreiteten Dialekten wie > Turbo-Pascal? > > hp EINSPRUCH ;-) Pascal hat drei immense Vorteile gegenüber C (und ich habe professionell in beiden Sprachen große Projekte gebaut): 1. Pascal kann CASE OF mit Strings - C nicht 2. Pascal kann klar Call by Ref und Call by Val - C nicht 3. Pascal hat eine harte Typenverwaltung - in C kann man auch mit Strings rechnen oder Ziffern statt Zahlen verwalten. C bietet interessante Techniken. In den großen Projekte haben wir sie verflucht. C für Anwendungen zu nutzen ist einer der großen Irrtümer der Informatik. Und mit C++ wurde ja letzten Endes auch versucht, die Schwächen zu entschärfen. Zu Lasten der Übersichtlichkeit. FW
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-07 08:26 +0200 |
| Subject | Re: Pascal |
| Message-ID | <l9tvs7Fj03pU1@mid.individual.net> |
| In reply to | #44555 |
Am 07.05.24 um 07:48 schrieb F. W.: > Pascal hat drei immense Vorteile gegenüber C (und ich habe professionell > in beiden Sprachen große Projekte gebaut): Vorteile? > > 1. Pascal kann CASE OF mit Strings - C nicht statt case if und else if wie in Python. > 2. Pascal kann klar Call by Ref und Call by Val - C nicht In C kann man pointer auf Variable übergeben. > 3. Pascal hat eine harte Typenverwaltung - in C kann man auch mit > Strings rechnen oder Ziffern statt Zahlen verwalten. In Pascal tut man sich schwer, wenn man bei ACII durch Umsetzung eines Bits zwischen Groß- und Kleinbuchstaben wechselt. Und die ganze Speicherverwaltung wird einfacher wenn bei char Zahlen und Buchstaben gleich sind. Lediglich beim debuggen wird es unhandlich, da bei char nicht bekannt ist, ob Zahl oder Buchstabe. > C bietet interessante Techniken. > In den großen Projekte haben wir sie verflucht. Ich habe es gemocht. Ich fand Pascal eher hinderlich. > C für Anwendungen zu nutzen ist einer der großen Irrtümer der > Informatik. Ohne C kein Unix und Linux? > Und mit C++ wurde ja letzten Endes auch versucht, die > Schwächen zu entschärfen. Zu Lasten der Übersichtlichkeit. Ich finde C++ eher unübersichtlich. Zumindest bei kleinen Programmen. Bei größeren Projekten mag C++ besser sein. Z.B. Wenn ich pointer Verwendung überschaue, warum noch weak pointer? Bei Pascal vermisse ich void und freie pointer. > FW > -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-07 13:04 +0200 |
| Subject | Re: Pascal |
| Message-ID | <l9ug6lFlb88U1@mid.individual.net> |
| In reply to | #44556 |
Am 07.05.24 um 12:25 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>>> 2. Pascal kann klar Call by Ref und Call by Val - C nicht
>> In C kann man pointer auf Variable übergeben.
>
> In C++2 ("Cpp2") von Herb Sutter sieht eine Funktion, die eine
> übergebene Variable inkrementieren kann, wohl so aus:
>
> inc: (inout v: int) = v++;
Neue? Schreibweise von
void inc(int &v){ v++;}
Nach meinen Uralt Erinnerung aus ca 1995.
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-07 14:57 +0200 |
| Subject | Re: Pascal |
| Message-ID | <l9ump9Fm9s4U1@mid.individual.net> |
| In reply to | #44568 |
Am 07.05.24 um 13:16 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>> Am 07.05.24 um 12:25 schrieb Stefan Ram:
>>> inc: (inout v: int) = v++;
>> void inc(int &v){ v++;}
>
> Ja. Der Vorteil ist, daß man in C++2 sagt, was man will (zum
> Beispiel "Parameter für Ein- und Ausgabe") und C++2 dann
> selber entscheidet, welche Art von Parameter (zum Beispiel
> Referenz, Zeiger, Konstante, etc.) dafür am besten ist.
Erinnert mich an COMPUTE in COBOL.
Mich nervt schon das const bei Parameter in C,
was es früher nicht gab.
Ich möchte das programmieren,
was für mich einfach und durchschaubar ist,
und derartige Entscheidungen compiler oder KI überlassen.
Mind. ein Fortran compiler expandiert z.B. kleine Schleifen
mit konstanten kleinen Grenzen.
z.B. aus
for i=1,3
x[i]=y[i]
x[1]=y[1]
x[2]=y[2]
x[3]=y[3]
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-07 13:11 +0000 |
| Subject | Re: Pascal |
| Message-ID | <v1d9a6$38vj4$1@dont-email.me> |
| In reply to | #44570 |
Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb:
> Mind. ein Fortran compiler expandiert z.B. kleine Schleifen
> mit konstanten kleinen Grenzen.
>
> z.B. aus
> for i=1,3
> x[i]=y[i]
>
> x[1]=y[1]
> x[2]=y[2]
> x[3]=y[3]
Du hast
do i=1,3
x(i) = y(i)
end do
bzw
x(1:3) = y(1:3)
falsch geschrieben :-)
Unrolling von kleinen Schleifen wird aber auch für C gemacht,
einfach mal solchen Code mit "-O3 -S" übersetzen oder gleich auf
godbolt.org anschauen.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-07 13:55 +0000 |
| Subject | Re: Pascal |
| Message-ID | <v1dbrt$39lic$1@dont-email.me> |
| In reply to | #44570 |
Stefan Ram <ram@zedat.fu-berlin.de> schrieb:
>|In Cpp2 sind die meisten Objekte standardmäßig konstant.
>|Insbesondere:
>|
>|Parameter sind standardmäßig const.
Andere Programmiersprachen haben da andere Konzepte.
Fortran z.B. hat INTENT und VALUE. Man schreibt da solche Sachen wie
subroutine foo(a, b, c, d)
real, intent(in) :: a
real, value :: b
real, intent(out) :: c
real, intent(inout) :: d
a ist dann eine Variable, die in foo nicht geändert werden darf,
sonst gibt's eine Fehlermeldung.
b ist dann "per value" übergeben; wenn b in foo geändert wird, dann
wird der Wert der Variable, mit der b assoziiert wird, nicht geändert.
c ist uninitialisiert beim Aufruf. Ein Compiler darf dann z.B. bei
c = 42.
call foo(a,b,c,d,e)
die Wertzuweisung an c rausoptimieren. An C darf dann z.B. keine
Konstante übergeben werden.
d hat (evtl.) vorher einen Wert, und der darf dann in foo geändert
werden. Auch da darf man keine Konstanten übergeben.
Und was C mit "restrict" macht, mehr schlecht als recht, macht
Fortran per default sowieso.
[...]
>|Ich bin skeptisch, was den Wert von const als Standard für
>|lokale Variablen angeht... vielleicht komme ich nicht genug raus,
>|aber die meisten lokalen Variablen sind, nun ja, Variablen.
Constants aren't, variables won't.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-08 21:33 +0200 |
| Subject | Re: Pascal |
| Message-ID | <slrnv3nks9.1fdo8.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44555 |
On 2024-05-07 05:48, F. W. <me@home.invalid> wrote:
> Am 06.05.2024 um 19:55 schrieb Peter J. Holzer:
>> On 2024-05-06 16:41, Stefan Reuther <stefan.news@arcor.de> wrote:
>>> Pascal ist nicht besser als C. Da kann man genauso mit Casts und
>>> Zeigern rumferkeln.
>>
>> In Standard-Pascal? Oder in diversen verbreiteten Dialekten wie
>> Turbo-Pascal?
>>
>> hp
>
> EINSPRUCH ;-)
>
> Pascal hat drei immense Vorteile gegenüber C (und ich habe professionell
> in beiden Sprachen große Projekte gebaut):
>
> 1. Pascal kann CASE OF mit Strings - C nicht
Syntactic sugar.
Ein größerer Vorteil wäre die Existenz eines "first class" String-Typs,
falls das ein Standard-Pascal-Feature ist.
> 2. Pascal kann klar Call by Ref und Call by Val - C nicht
Weiß nicht, ob das ein Vorteil ist.
> 3. Pascal hat eine harte Typenverwaltung - in C kann man auch mit
> Strings rechnen
Nein.
> oder Ziffern statt Zahlen verwalten.
Was auch immer das heißen mag. Ich hoffe, dass eine Programmiersprache
Ziffern verwalten kann. Mir wäre noch keine untergekommen, die das nicht
könnte ;-). Falls Du meinst, dass char ein Integer-Typ ist und nichts
eigenes: Das hat Vor- und Nachteile. Mehr stört mich aber, dass "char"
heutzutage selten geeignet ist, einen "Character" zu speichern.
hp
[toc] | [prev] | [next] | [standalone]
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web