Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #399792 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-06-08 17:49 +0200 |
| Last post | 2026-06-14 14:44 +0200 |
| Articles | 14 on this page of 194 — 17 participants |
Back to article view | Back to comp.lang.c
this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-08 17:49 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-08 18:16 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-08 18:24 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:28 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 08:56 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 10:26 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 09:10 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 11:34 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-09 12:25 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 12:31 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 13:43 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 13:53 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:02 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-10 08:55 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:00 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-10 09:06 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 00:34 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-10 12:37 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 11:40 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:01 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-22 13:42 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-22 22:38 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-23 14:40 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-24 02:04 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-24 04:42 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Paul <nospam@needed.invalid> - 2026-06-09 06:02 -0400
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 12:18 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 23:45 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 13:55 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 23:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 21:52 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 21:55 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 22:05 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 06:03 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 00:24 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:07 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 16:47 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 02:49 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 19:52 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 03:57 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-20 15:49 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-21 16:30 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 14:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-22 12:23 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-10 14:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 13:54 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 23:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 21:42 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 06:21 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 00:14 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 00:31 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:15 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 21:08 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:10 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 23:01 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 06:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 13:27 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 01:35 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-13 14:26 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-13 14:32 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 00:45 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-14 13:55 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 04:36 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-16 13:08 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-16 13:11 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 03:11 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-17 12:13 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 23:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-17 20:26 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 07:30 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-18 04:36 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-18 04:38 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 23:03 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 13:42 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 22:40 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 16:40 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 02:50 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 19:53 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 03:59 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-21 16:31 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-22 00:59 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-22 14:06 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-22 22:40 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-23 14:41 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-24 02:05 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-24 04:36 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 12:19 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-24 21:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-25 12:44 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 12:02 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:16 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-17 18:41 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 07:30 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-18 03:49 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 23:06 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-19 01:20 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-19 08:56 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 10:42 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 10:18 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 15:29 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 16:18 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 18:07 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-19 18:51 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 21:04 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 19:55 +0000
[OT] Google AI - behavioral analysis (was: [something else]) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-20 01:52 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 03:03 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-19 18:50 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-19 13:46 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 15:49 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-19 17:25 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-21 01:42 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-21 12:18 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-21 23:15 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) antispam@fricas.org (Waldek Hebisch) - 2026-06-22 04:33 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-22 10:01 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 14:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-23 07:25 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-23 15:35 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-23 18:07 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-23 17:12 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-23 21:07 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-23 23:00 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-24 08:32 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-24 21:54 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-24 21:09 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 10:48 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 10:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-24 15:02 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-25 11:29 +0000
NIC interrupt rates (was UART discussion; previously was Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-25 15:31 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-25 19:15 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-25 18:29 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-25 20:52 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-26 14:58 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-26 11:46 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-27 01:57 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-25 22:53 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-27 01:52 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-27 19:46 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-01 13:16 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-07-03 17:00 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-27 20:49 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-01 13:17 +0000
UARTs (was Re: this guy talks about fopen (and im thinking about fopen for network)) scott@slp53.sl.home (Scott Lurndal) - 2026-06-27 18:50 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-23 17:39 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-23 21:11 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 11:04 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-24 15:27 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-25 11:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-25 21:30 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-27 02:22 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-28 18:59 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-07 23:19 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-07-08 14:52 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-07-08 20:56 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-24 15:51 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-23 14:44 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-23 22:30 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-23 22:48 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 12:18 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-24 22:00 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-24 20:09 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-25 00:25 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-25 12:00 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-25 15:37 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) pa@see.signature.invalid (Pierre Asselin) - 2026-06-24 21:21 +0000
Time from official time-services (was Re: ...some arbitrary subject...) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 00:15 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 16:31 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 17:50 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-19 18:54 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 19:58 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 21:15 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 22:09 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 03:00 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-19 10:33 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 19:04 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-19 18:55 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 21:07 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-20 13:53 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-20 19:25 -0400
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 22:49 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-19 18:06 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 06:59 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-19 14:47 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 22:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-20 14:02 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-19 02:21 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 09:59 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:26 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-06-09 21:21 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 12:28 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-11 07:24 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-14 14:44 +0200
Page 10 of 10 — ← Prev page 1 … 8 9 [10]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-06-20 19:25 -0400 |
| Message-ID | <11177gs$ds94$1@dont-email.me> |
| In reply to | #400131 |
Bart <bc@freeuk.com> writes: >On 19/06/2026 18:33, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >> [...] >>> How would you distinguish between two floppy drives on a Unix-like >>> file system? >>> >>> If writing a common shell script for other people to use on their own >>> machines, would you be able to use the same designations? >> >> I'd ask in a forum that discusses Unix-like systems, not one that >> discusses the C programming language. > >Here's the thing: this is thread that has been wildly off-topic for >nearly 100 posts, even aside from the other off-topic threads. > >Yet you pick on MY post and tell only ME to move the discussion elsewhere. You say that as if being advised to discuss this question in a place where you're more likely to get good answers is some kind of punishment. Is getting a good answer to your question so undesirable? If you prefer bad answers, there's even better newsgroups I could suggest than this one to achieve that result.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-19 22:49 +0000 |
| Message-ID | <1114h1c$3l4ud$4@dont-email.me> |
| In reply to | #400120 |
On Fri, 19 Jun 2026 10:42:32 +0100, Bart wrote: > How would you distinguish between two floppy drives on a Unix-like > file system? Remember that Unix-like systems don’t access volumes via device names, but by mount points.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-06-19 18:06 -0500 |
| Message-ID | <1114i1o$3lhoj$1@dont-email.me> |
| In reply to | #400117 |
On 6/19/2026 1:56 AM, David Brown wrote: > On 19/06/2026 08:20, BGB wrote: >> On 6/18/2026 6:06 PM, Lawrence D’Oliveiro wrote: >>> On Thu, 18 Jun 2026 03:49:55 -0500, BGB wrote: >>> >>>> Just that it is also not a huge leap from: >>>> tcp://whatever >>>> udp://whatever >>>> http://whatever >>>> ftp://whatever >>>> ... >>>> To: >>>> c:/whatever... >>> >>> Yes it is. >>> >>> In the former, that part before the colon is a protocol. In the >>> latter, it is now down to just indicating a filesystem drive. And not >>> even in a unique fashion, like with a volume UUID or something, but >>> with an arbitarily-assigned “drive letter” which cannot be guaranteed >>> to be unique or persistent. >>> >> >> Well, on older Windows. >> >> On newer systems, the OS remembers and will assign the same drives to >> the same letter on each boot. >> > > I am not sure what you call "newer", but IIRC Windows has done that > since Windows 3.1. The only letters you could assign yourself were for > network drives, and they were persistent if you choose "persistent=yes". > > Later versions of Windows (maybe NT4 or W2K? I can't remember the > details) let you choose the letter to use for other drives, such as > additional harddrives, CD-ROMs and later still, USB drives. Those > choices were persistent. > > Automatically chosen drive letters were, of course, inconsistent. And > when you have a lot of drives and network shares, they run out. > I meant where you could pick the drive letter and the OS would remember. But, yeah, the DOS-based Windows variants (3.x/95/98/Me), would just sort of enumerate drives and pick letters sequentially. A/B: First/Second floppy drive; C: First HDD ... Typically, HDDs would be assigned letters first, followed by CD-ROMs, which could make a problem for any CD-ROM based software that was hard-coded to assume that the CD-ROM drive was in "D:", ... Generally the NT based Windows (now all of then) instead using statically assigned drive letters, though the letters are remembered by the OS vs drive, so plugging the same physical drive into different systems, or booting a different version of the OS (or reinstalling the OS) may move the drive letters around. >> >> But, yeah, probably wouldn't do it the Windows way. Either they could >> be specified as mounts (in mtab or such), or possibly treated as >> aliases, say: >> c:/ aliases to /mnt/c > > Drive letters make sense when users wanted to distinguish between their > 3.5" floppy "A:" and their 5.25" floppy "B:". They were still usable > when you had a hard drive with one partition. Once it was realistic to > have two drives in the one PC, and more than one partition on a disk, > they were outdated and too restrictive for comfort. > > They were a product of their time, but offer nothing going forward. > Copying the concept in any way for a new system is a daft idea. > Likely only real reason to do this would be either for software or user familiarity. Like, say, users are more used to seeing "C:\" vs, say, "/usr", "/home/username". Well, then again, many might just expect to see "My Documents" and not know/care where it is stored in the filesystem, eg: "C:\Users\username\My Documents" And, might not notice or care much if suddenly it became, say: /home/username/Documents >> >> >> Though, granted, not much particular reason to do this... >> >> >> >> >>> Remember, we already have >>> >>> file://whatever >>> >>> for denoting files on the local filesystem. That allows the “whatever” >>> part to span the entire filesystem, not just one volume/drive. >> >> Maybe, but you wouldn't need "file://" for "fopen()" or similar, since >> it is sort of an implied default in this case. >> >> >> Then again, going into the weeds on this: >> Would, say: >> cd ftp://foo.org/pub/ >> ls >> Even really make sense?... >> > > That could be nice, at least for things that support a file and > directory model. It all depends on how you want to treat user > convenience, security, reliability, etc. > Maybe. It sort of exists in the VFS layer, but more for functional things. Doesn't currently work in the shell which assumes a single-rooted Unix-style tree at present. >> Or, would it be better to ask people to at least mount it into the VFS >> or similar?... > > You are likely to need a user name and password here somewhere. > Yeah, this would likely work against the ability to 'cd' into an FTP server. It would likely still make more sense as a mount point or something. >> >> >> >> Well, or other mysteries, like, say: >> Should usermode applications be allowed to export COM-like interfaces >> that could then be mounted into the VFS?... >> >> Say, for example, an application exports an IFileSystem or IMount >> interface to the VFS, and then one can issue a "mount" on it. Would >> need some way for the VFS do deal gracefully if the application >> becomes unresponsive or crashes though (preferably without nuking the >> whole OS in the process). > > Like "fuse" on Linux (and similar things on other systems) ? Usermode > is the way to go for anything that is not speed critical. > Yeah, although IIRC 'fuse' works over sockets or similar. Things like sockets or message passing have higher overhead and latency, but also have more well-defined behavior (and less risk) than inter-process method calls. Then again, if I could set up a task that would wait for something to come over a socket and then dispatch the request, sending the response over a socket, this would be more decoupled... But, then again, for kernel level stuff, one either expects the request can be completed or it can't. This breaks with the message passing (we can't know success/failure/etc until after a response gets back). But, if one makes an object call to a usermode Object handler from within the kernel's syscall handler, a new problem arises: The System-Call handler is effectively "out of commission" until it's response gets back. So, it could end up in a state where you are in usermode but unable to make any system calls, which is, not ideal... Seems like some more thought would be needed for the engineering on this one... May likely need a more asynchronous mechanism, with some way for the VFS to be like "we don't know yet...", and then somehow put the caller on hold until a response gets back from the userland FS driver (though likely initiating a context switch to the FS driver so that it can handle the request, but not in a way that would block the FS's driver's ability to make system calls). Well, maybe the system-call handler could have a mechanism to signal to the SYSCALL interrupt, "I have more work to do, fire off a virtual syscall as soon as control gets back there...". >> >> Vs, say, assuming programs that export interfaces (as services) to be >> at least semi trsusted / stable... >>
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-19 06:59 +0000 |
| Message-ID | <1112pcl$34vdd$1@dont-email.me> |
| In reply to | #400116 |
On Fri, 19 Jun 2026 01:20:14 -0500, BGB wrote: > On newer [Windows], the OS remembers and will assign the same drives > to the same letter on each boot. You know, it’s a wonder to think, for an OS that was supposedly designed for 16-bit machines, how many legacy features it inherits from the 8-bit era. > Maybe, but you wouldn't need "file://" for "fopen()" or similar, > since it is sort of an implied default in this case. For an OS-level call, yes. But there are lots of higher-level toolkits (particularly GUI-associated ones) that hook in a virtual-I/O layer that allows accessing remote URLs as easily as opening local files. > May seem like a waste to burn a thread on each object listener, but > no real better option at present. What, no event loop?
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-06-19 14:47 -0500 |
| Message-ID | <11146co$3ig09$1@dont-email.me> |
| In reply to | #400118 |
On 6/19/2026 1:59 AM, Lawrence D’Oliveiro wrote: > On Fri, 19 Jun 2026 01:20:14 -0500, BGB wrote: > >> On newer [Windows], the OS remembers and will assign the same drives >> to the same letter on each boot. > > You know, it’s a wonder to think, for an OS that was supposedly > designed for 16-bit machines, how many legacy features it inherits > from the 8-bit era. > Maybe. MS-DOS copied CP/M. Win 3.x and 9x built on top of DOS. WinNT copied the same general structure of the DOS-based Windows. ... As for TestKern, it is in a weird space of being sorta Unix-like but also sorta more resembling Cygwin in some ways. >> Maybe, but you wouldn't need "file://" for "fopen()" or similar, >> since it is sort of an implied default in this case. > > For an OS-level call, yes. But there are lots of higher-level toolkits > (particularly GUI-associated ones) that hook in a virtual-I/O layer > that allows accessing remote URLs as easily as opening local files. > I guess one can distinguish here what belongs in the VFS and shell, vs what belongs in a file-browser or web browser. As of yet, no file browser or web-browser, still basically at the level of a very rudimentary GUI that has a shell window that can be used for other programs. When not running the GUI, it is just a shell. >> May seem like a waste to burn a thread on each object listener, but >> no real better option at present. > > What, no event loop? A lot of normal programs use polling loops, but from the way object-method dispatch works, it would not use a polling/loop or event loop. In this case, the method calls are not actually themselves "messages" that are passed along, but more that the thread goes into a special state where it effectively expects the OS scheduler to wake it at the exact moment a method call arrives, with this method call effectively taking over the whole thread (which then serves no purpose other than handling incoming message calls). When the method returns, it is a trip right back into the OS scheduler, which typically restores the task that initiated the method call. Or, in effect, less like traditional message/event handling, and more like direct method calls bounced over the OS's SYSCALL/SCHED mechanism. Actually, the normal system calls in this case work in a similar way, where one can view bare system calls as essentially method calls to a special NULL object. Say, from RV or similar: X10: Object Handle X11: Method Number (depends on Object) X12: Argument List Pointer X13: Return Value Pointer X14/X15/X16: MBZ here X17: -1 (0+ would map to Linux style SYSCALLs) Then one uses a special instruction, 'ECALL' which invokes the mechanism. This invokes a handler in a lower operating mode (lets call it "Machine Mode"). For most calls, this handler can't deal with it directly, but what it can do is pass the call where it needs to go. If handle is NULL (0), it pulls up the normal SYSCALL handler task, and initiates a context switch. As soon as the Syscall Thread wakes, it grabs the arguments (which the SYSCALL handler shoved into the appropriate registers) and "lets it rip". For other objects, the SYSCALL handler can instead choose the task associated with the object handle in question (which basically can work like an index into an array of tasks and objects). It then does the register-shoving magic, and performs the context switch (mostly some arcane magic where it reloads all the registers from the new context, rather than the ones saved off when initiating the SYSCALL). For an object method handler (assuming RV here), it would do something like (on waking): Use method number from X11 to fetch method pointer from VTable for current object; Save off X13 for later; Copy arguments from Argument list into the argument registers (X10..X17), with some more into the current stack; Call the method; Restore saved X13; Copy X10/X11 from called method; Load -2 into X17; ECALL (Returns to caller) At this point, object handler should be back in the same state it was before the call, and if woken again, will go through the same ritual. Granted, the mechanism could potentially be tweaked to allow multiple object instances to be handled by the same thread (rather than needing to spend a thread per handler object). In this case, multiple objects could export from the same root handler thread. Note that in this OS, memory is subdivided into Local and Global: Local memory is only accessible within the current process; Global memory may be accessed by other processes; ... Any structures or memory passed over this call interface effectively needs to be Global, or else stuff is liable to explode. The memory map is maybe a little wonky, but sorta like (48 bit): 0000_xxxxxxxx .. 3FFF_xxxxxxxx: System / Global 4000_xxxxxxxx .. 7FFF_xxxxxxxx: Local 8000_xxxxxxxx .. FFFF_xxxxxxxx: System / Hardware (Special) ...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-19 22:47 +0000 |
| Message-ID | <1114gtl$3l4ud$3@dont-email.me> |
| In reply to | #400136 |
On Fri, 19 Jun 2026 14:47:31 -0500, BGB wrote: > On 6/19/2026 1:59 AM, Lawrence D’Oliveiro wrote: >> >> On Fri, 19 Jun 2026 01:20:14 -0500, BGB wrote: >> >>> Maybe, but you wouldn't need "file://" for "fopen()" or similar, >>> since it is sort of an implied default in this case. >> >> For an OS-level call, yes. But there are lots of higher-level toolkits >> (particularly GUI-associated ones) that hook in a virtual-I/O layer >> that allows accessing remote URLs as easily as opening local files. >> > I guess one can distinguish here what belongs in the VFS and shell, vs > what belongs in a file-browser or web browser. I should mention that Linux has a filesystem plugin API called FUSE, which allows filesystem implementations to be done in userland. Not everything has to be a kernel module. Example: secure remote access to filesystems on other machines via SSH <https://github.com/libfuse/sshfs>. > As of yet, no file browser or web-browser, still basically at the level > of a very rudimentary GUI that has a shell window that can be used for > other programs. Actually, lots of them do. Just one example I came across recently: <https://telehack.com/>. Also this <https://xen-orchestra.com/> Web-based GUI front-end to XCP-ng <https://xcp-ng.org/> lets you open console windows to your VMs, directly in the browser. >> What, no event loop? > > A lot of normal programs use polling loops, but from the way > object-method dispatch works, it would not use a polling/loop or > event loop. The two are not mutually exclusive <https://docs.python.org/3/library/asyncio-eventloop.html>.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-20 14:02 +0200 |
| Message-ID | <1115vg6$1h73$2@dont-email.me> |
| In reply to | #400146 |
On 20/06/2026 00:47, Lawrence D’Oliveiro wrote: > On Fri, 19 Jun 2026 14:47:31 -0500, BGB wrote: > >> On 6/19/2026 1:59 AM, Lawrence D’Oliveiro wrote: >>> >>> On Fri, 19 Jun 2026 01:20:14 -0500, BGB wrote: >>> >>>> Maybe, but you wouldn't need "file://" for "fopen()" or similar, >>>> since it is sort of an implied default in this case. >>> >>> For an OS-level call, yes. But there are lots of higher-level toolkits >>> (particularly GUI-associated ones) that hook in a virtual-I/O layer >>> that allows accessing remote URLs as easily as opening local files. >>> >> I guess one can distinguish here what belongs in the VFS and shell, vs >> what belongs in a file-browser or web browser. > > I should mention that Linux has a filesystem plugin API called FUSE, > which allows filesystem implementations to be done in userland. Not > everything has to be a kernel module. > Exactly. Using FUSE gives a bit more overhead and latency compared to a kernel filesystem, but is much more convenient to develop (being userspace), easier to make secure (being userspace), can be written in any language you like (being userspace), does not need to be updated for different kernels (being userspace), can be packaged and distributed independently from the kernel (being userspace) and does not introduce security or reliability risks for people who don't use it (being userspace). It is the right choice for every filesystem that does not need maximal efficiency or to work as the root filesystem. You can even use WinFUSE to make your FUSE filesystem work on Windows. > Example: secure remote access to filesystems on other machines via SSH > <https://github.com/libfuse/sshfs>. sshfs is a thing of beauty, and I use it continuously.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-19 02:21 -0700 |
| Message-ID | <11131lv$3763k$1@kst.eternal-september.org> |
| In reply to | #400116 |
BGB <cr88192@gmail.com> writes:
[...]
> Then again, going into the weeds on this:
> Would, say:
> cd ftp://foo.org/pub/
> ls
> Even really make sense?...
It wouldn't work that way, because "ftp:" is a valid name for a
directory on a Unix-like system, and "//" is equivalent to "/".
$ cd ftp://foo.org/pub/
$ ls
this-is-not-an-ftp-server
$
Trying to be at least vaguely topical, on systems with a more
restrictive file name syntax it might be possible for fopen() to
distinguish by name between a local file and a URL, but not on a
Unix-like system without more information.
> Or, would it be better to ask people to at least mount it into the VFS
> or similar?...
It's certainly possible to mount an ftp server as a filesystem on
most Unix-like systems, probably with some add-on software
(like curlftpfs, which I haven't tried).
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-19 09:59 +0000 |
| Message-ID | <11133tu$2q0$1@reader1.panix.com> |
| In reply to | #400119 |
[Followup-To: comp.os.plan9]
In article <11131lv$3763k$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>BGB <cr88192@gmail.com> writes:
>[...]
>> Then again, going into the weeds on this:
>> Would, say:
>> cd ftp://foo.org/pub/
>> ls
>> Even really make sense?...
>
>It wouldn't work that way, because "ftp:" is a valid name for a
>directory on a Unix-like system, and "//" is equivalent to "/".
>
>$ cd ftp://foo.org/pub/
>$ ls
>this-is-not-an-ftp-server
>$
>
>Trying to be at least vaguely topical, on systems with a more
>restrictive file name syntax it might be possible for fopen() to
>distinguish by name between a local file and a URL, but not on a
>Unix-like system without more information.
I'll mention Plan 9 again; this is another example where trying
to shoehorn too much metadata into a filename breaks down.
Instead, one "mounts" a remote service as a filesystem somewhere
in one's namespace, and interacts with it normally.
>> Or, would it be better to ask people to at least mount it into the VFS
>> or similar?...
>
>It's certainly possible to mount an ftp server as a filesystem on
>most Unix-like systems, probably with some add-on software
>(like curlftpfs, which I haven't tried).
>
>[...]
On a p9 system, one would do:
cpu% ftpfs -a ftp@ -m /n/openbsd ftp.usa.openbsd.org
220 anoncvs4.usa.openbsd.org FTP server ready.
331 Guest login ok, send your email address as password.
230- Welcome to ftp4.usa.OpenBSD.org in New York City, New York, USA.
230- For other mirror sites visit http://www.openbsd.org/ftp.html
[...]
230-
230 Guest login ok, access restrictions apply.
215 UNIX Type: L8
257 "/" is current directory.
cpu% cd /n/openbsd/pub/OpenBSD/7.9/riscv64
cpu% cat BUILDINFO
Build date: 1778100455 - Wed May 6 20:47:35 UTC 2026
cpu% cd
cpu% unmount /n/openbsd
cpu%
Topicality: this was all written in a dialect of C, called Plan
9 C.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-09 00:26 +0000 |
| Message-ID | <1107mj0$3k6ea$2@dont-email.me> |
| In reply to | #399792 |
On Mon, 8 Jun 2026 17:49:03 +0200, fir wrote: > i dint watched it whole but it comes to my mind that those socket > communication indeed should be probably made using > fopen/fread/fwrite/fgetc/fputc On POSIX systems, the actual connection setup is not done by opening normal files, but once setup, the result is an fd that can be used with many regular fd calls. In particular, for a stream connection, you can get by with normal read/write calls for most purposes. And poll(2)/epoll(2) work just fine, of course. Plan9 tried to do all network I/O this way -- pretend it’s all just file I/O. I don’t think it works all that well.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-06-09 21:21 +0000 |
| Message-ID | <20260609141644.458@kylheku.com> |
| In reply to | #399792 |
On 2026-06-08, fir <profesor.fir@gmail.com> wrote: > https://www.youtube.com/watch?v=XAzUoizwnXM > > i dint watched it whole but it comes to my mind that those socket > communication indeed should be probably made using > fopen/fread/fwrite/fgetc/fputc That's how it is in the Plan 9 operating system. It takes the "everything is a file" paradigm that Unix started on. Unix diverged from that paradigm in implementing new things like networking. > > i was doing only basics of socket programming anver liked it and > remember almost nothing - it is becouse i dont liek stupid things > and those sockets looks stupid > > i guess using this fopen it would be much better.. "Using fopen" is better is basically "using strings is better" in disguise. When you use fopen to open a network client or server connection, all the connection parameters have to be encoded into a character string, instead of binary structures. That makes some things easy, such as binding to networking from a new programming language (no "FFI" required, just buffered file I/O and string munging). The strings are inefficient, though; they have to be formatted and parsed. They lack type safety. You can put wrong values into a binary address structure, but in a string you can cause a syntax error. And worse, injection security holes and whatnot. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-10 12:28 +0000 |
| Message-ID | <110bl9e$nt1$1@reader1.panix.com> |
| In reply to | #399829 |
[Followup-to: comp.os.plan9]
In article <20260609141644.458@kylheku.com>,
Kaz Kylheku <046-301-5902@kylheku.com> wrote:
>On 2026-06-08, fir <profesor.fir@gmail.com> wrote:
>> https://www.youtube.com/watch?v=XAzUoizwnXM
>>
>> i dint watched it whole but it comes to my mind that those socket
>> communication indeed should be probably made using
>> fopen/fread/fwrite/fgetc/fputc
>
>That's how it is in the Plan 9 operating system. It takes the
>"everything is a file" paradigm that Unix started on. Unix diverged
>from that paradigm in implementing new things like networking.
That is actually how Unix networking was done initially, cf RFC
681 or the MIT CHAOS implementation; the mechanism for the
latter was to use `namei` in the kernel to open a "network
device" that implemented NCP ("/dev/net") and then exploit a
hack where extra data in the pathname could be passed to the
device's `open` entry point in the `cdevsw`.
The problem was that this wasn't very flexible and opened up all
kinds of problems with respect to how the namespace is managed,
what kind of protocol you wanted: what does it mean if you alias
a name via `link`? Etc.
Plan 9 fixes this by having a different file-based interface
between a program and the network stack in the kernel. The
observation is that sockets are accessed via something that
looks an awful lot like a file descriptor (which is itself just
a small integer; internally this is an index into a table), but
they exist in a wholly different namespace that is disconnected
from the file namespace.
The Plan 9 authors observed that there's no reason that that
must be the case, and so while on Unix the model was "everything
is a file" (not true, of course), on Plan 9, it is, "everything
is a file system": that is, devices expose a small hierarchy of
files, which together expose the device's interface. Of course,
"device" is generic here and includes pseudo-devices; one may
think of the network stack as a device, but so is the window
system, your email inbox, and so on. Note that we speak of
these as "files" but they don't actually exist on a storage
device, and there is no taxonomy of block and character devices
as there is on Unix. Rather, files are just named resources
that are mounted into the file name hierarchy as seen by some
process: on Plan 9, file namespaces (as seen by `ls` and so on)
are per-process (group), and `mount` is unprivileged and always
available to a program. Thus, "files" may refer to something
on a storage device somewhere, or they may refer to a device, or
they may refer to an IPC endpoint created by a user program.
So for networking, the kernel models protocols as pseudo-devices
that it calls "protocol devices". These are mounted into the
process namespace, canonically on `/net`, so that we have
`/net/tcp` and so on. If I want to create a new TCP connection,
I can open, `/net/tcp/clone`; this creates a new connection
object in the kernel, which causes a new, numbered directory to
spring into existence under `/net/tcp/$n$`. That has `ctl` and
`data` files under it; I can connect to a remote machine by
`echo`ing data into the `ctl` file; reading and writing the
`data` files receives and send data on the connection. If I
`close` the data file (and nothing else is holding a reference
to the connection) then the connection is closed, and the
connection object in the kernel reclaimed, and the directory
removed. There's a library routine to do this dance for you,
called `dial`; it takes a string argument, something like:
`dial("tcp!some.host.name!service");` and returns a file
descriptor or error, but an astute reader will see that it is
possible to create a shell script that creates TCP connections
with no changes to the shell.
Another interesting aspect of the design: Plan 9 uses a simple
protocol called "9P" to share file systems over a network; to
use some remote machine's resources, I can import them (over 9P)
into the namespace of my local system and just
open/read/write/close them.
This composes in interesting ways: Given some remote machine, I
can import its network stack into my own namespace, and make (or
receive) connections from (and to), but all running on a
different computer. Similarly, `/proc` is a filesystem that I
can import; so I can debug or trace a program running on a
remote system, but run the debugger locally; all without an
elaborate "remote debugging" protocol.
More information is available in the original papers, that are
well worth a tread:
http://9p.io/sys/doc/9.html
http://9p.io/sys/doc/names.html
http://9p.io/sys/doc/net/net.html
http://9p.io/sys/doc/auth.html
(The auth one is particularly interesting.)
>> i was doing only basics of socket programming anver liked it and
>> remember almost nothing - it is becouse i dont liek stupid things
>> and those sockets looks stupid
>>
>> i guess using this fopen it would be much better..
>
>"Using fopen" is better is basically "using strings is better"
>in disguise. When you use fopen to open a network client or server
>connection, all the connection parameters have to be encoded into
>a character string, instead of binary structures.
>
>That makes some things easy, such as binding to networking from a new
>programming language (no "FFI" required, just buffered file I/O and
>string munging).
>
>The strings are inefficient, though; they have to be formatted
>and parsed. They lack type safety. You can put wrong values
>into a binary address structure, but in a string you can cause
>a syntax error. And worse, injection security holes and whatnot.
See above. Trying to pack everything into a single file name
passed to `fopen` (or `open`) isn't a good abstraction, but
there is little materially different between creating binary
data structures like `sockaddr_in` or `sockaddr_in6`, or
composing a network address in a string that is passed to a
library routine. In most cases, we use things like symbolic
host names and textual port numbers that have to be parsed and
resolved anyway. In all cases, the input data needs to be
validated by both the stack and the programmer who creates the
data structures.
The more interesting thing is how the system models the
protocols and the interface it provides.
None of this has to do with C, except that Plan 9 was written in
a dialect of C (the early work predated the ANSI standard, they
made extensions to the language, and in a few places it is
incompatible: the type promotion rules for arithmetic, for
instance).
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-06-11 07:24 +0200 |
| Message-ID | <110dgpc$17tcb$2@raubtier-asyl.eternal-september.org> |
| In reply to | #399792 |
Am 08.06.2026 um 17:49 schrieb fir: > i was doing only basics of socket programming anver liked it and > remember almost nothing - it is becouse i dont liek stupid things > and those sockets looks stupid Use Boost.ASIO. ;-)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-06-14 14:44 +0200 |
| Message-ID | <110m7ml$3kdi1$1@raubtier-asyl.eternal-september.org> |
| In reply to | #399792 |
Am 08.06.2026 um 17:49 schrieb fir: > https://www.youtube.com/watch?v=XAzUoizwnXM > > i dint watched it whole but it comes to my mind that those socket > communication indeed should be probably made using fopen/fread/fwrite/ > fgetc/fputc > i was doing only basics of socket programming anver liked it and > remember almost nothing - it is becouse i dont liek stupid things > and those sockets looks stupid > i guess using this fopen it would be much better.. > whot would you need i assume you need to fopen connection to distant > machine..not sure if it should be one the same for read write or two > one for read and one for write..then i think the network card should > have buffer whete there is stacked incoming data, same for outcoming > data,a nd thats all as to basics probably..no hanging controll no > additional threads..just like working with files > whough additional soft could be written too, based on thai but it should > be sane thing something based like with working with files (knowing > those files are ram files and are contents of incoming and outcoming buffer > thise sockets todajy i dont remember but in my vague mameory it feels > like shit > feel free to comment on this topic if you want The official name for fopen() for network is Boost.ASIO.
[toc] | [prev] | [standalone]
Page 10 of 10 — ← Prev page 1 … 8 9 [10]
Back to top | Article view | comp.lang.c
csiph-web