read(fd, buf, SSIZE_MAX + 1) (was: Kommata)

[Helmut Waitzmann]

Helmut Schellong <r...@schellong.biz>:
>On 04/04/2019 17:47, Stefan Reuther wrote:
>> Am 04.04.2019 um 14:26 schrieb Helmut Schellong:
>>> On 04/04/2019 13:39, Claus Reibenstein wrote:
>>>>> On 04/03/2019 16:34, Rainer Weikusat wrote:
>>>>>
>>>>>> while ((rc = read(fd, buf, len)), rc == -1 && errno == EAGAIN) {
>>>>>
>>>>> [...] ich formuliere stets
>>>>> 'rc < 0', weil jeder Wert <0 eine Fehlersituation ist.
>>>>
>>>> Wobei es laut Doku nur genau diesen einen negativen Wert gibt bei
>>>> read(). Von daher ist das wurscht.
>>>
>>> Das weiß ich, dennoch ist jeder Wert <0 ein Wert, mit dem man
>>> außer ihn als Fehler anzusehen, nichts anfangen kann.
>>
>> Der Größenparameter ist ein size_t. Es ist vielleicht nicht sonderlich
>> relevant, auf einem 32-Bit-System 3 Gigabyte am Stück zu lesen, aber auf
>> einem 16-Bitter 40 kByte find ich jetzt nicht ungewöhnlich. Dann wäre
>> der Erfolgswert -24576.
>>
>> Nicht, dass sich MS-DOS darum scheren würde, aber POSIX (SUS) lässt
>> diesen Fall implementation-defined.
>
>http://osr507doc.xinuos.com/en/man/html.S/read.S.html
>
>|Return values
>|On success, read and readv return a non-negative integer
>|indicating the number of bytes actually read.
>|On failure, read and readv return -1
>|and set errno to identify the error.
>
>'Success' erfordert unbedingt Werte >= 0.

POSIX The Open Group Base Specifications Issue 7, 2018 edition
IEEE Std 1003.1™-2017 (Revision of IEEE Std 1003.1-2008):

<http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html#tag_16_474_02>:

SYNOPSIS

#include <unistd.h>

[…]
ssize_t read(int fildes, void *buf, size_t nbyte);


<http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html#tag_16_474_03>:

DESCRIPTION

The read() function shall attempt to read nbyte bytes from
the file associated with the open file descriptor, fildes,
into the buffer pointed to by buf.

[…]

If the value of nbyte is greater than {SSIZE_MAX}, the
result is implementation-defined.

<http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html#tag_16_474_04>:

RETURN VALUE

Upon successful completion, these functions shall return a
non-negative integer indicating the number of bytes actually
read. Otherwise, the functions shall return -1 and set errno
to indicate the error.

=> Über Funktionswerte <-1 wird im POSIX‐Standard keine Aussage
gemacht, außer der, dass für den Fall, dass mehr als SSIZE_MAX
Bytes gelesen werden sollen, die Implementierung festlegen muss,
was dann geschehen soll. Der C‐Standard macht überhaupt keine
Aussage, weil die Funktion »read()« nicht darin enthalten ist.

>Das war auch schon so, als beide Typen 'int' waren.
>Daß die Typen heute ssize_t und size_t sind, ändert nichts daran.
>
>Wenn heute ein Wert 'len' übergeben wird, der größer ist als
>der positive Wertbereich von ssize_t, werden eben weniger Bytes
>in 'buf' kopiert als per 'len' angegeben, oder es wird
>der Fehler EOVERFLOW oder ein anderer gegeben.
>Mit ersterem muß sowieso gerechnet werden.

Das geben weder der POSIX‐ noch der C‐Standard her.

Fazit: Wer will, dass sein Programm auf jedem POSIX‐System
funktioniert, muss sich darauf beschränken, nicht mehr als
SSIZE_MAX Bytes lesen zu wollen. Hält er sich an die
Beschränkung, können Funktionswerte <-1 (bisher) nicht vorkommen.
Tut er es nicht, erklärt er sich mit dem einverstanden, was seine
Implementierung festgelegt hat.

Will man also wasserdicht programmieren, sind Funktionswerte >=0
als Anzahl gelesener Bytes, der Funktionswert =-1 als im Standard
definierter Fehlerfall mit im Standard definierten
Fehlerbehandlungsmöglichkeiten und Funktionswerte < -1 als
verbotene Werte zu behandeln. »Verboten« heißt: Das Programm
kann überhaupt keine Annahmen mehr über den Zustand des
File‐Descriptors machen. Es bleibt ihm nicht viel anderes übrig,
als (nach Belieben) dem Anwender eine Fehlermeldung über einen den
Standard sprengenden Fehler zu geben und danach diesen
File‐Descriptor nicht mehr anzufassen (allenfalls noch, ihn zu
schließen).

Siehe auch
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html#tag_16_474_08_01>.

Wenn ich das richtig verstanden habe, ist die Funktion »read()« im
C‐Standard nicht definiert, jedoch im POSIX‐Standard. Deshalb
schlage ich ein

Crosspost & Followup-To: de.comp.os.unix.programming

vor. Notfalls bitte passend abändern.

[Michael Bäuerle]

Helmut Waitzmann wrote:
>
> [...]

> <http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html#tag_16_474_04>:
>
> RETURN VALUE
>
> Upon successful completion, these functions shall return a
> non-negative integer indicating the number of bytes actually
> read. Otherwise, the functions shall return -1 and set errno
> to indicate the error.
>
> => Über Funktionswerte <-1 wird im POSIX‐Standard keine Aussage
> gemacht, außer der, dass für den Fall, dass mehr als SSIZE_MAX
> Bytes gelesen werden sollen, die Implementierung festlegen muss,
> was dann geschehen soll.

> [...]

> Fazit: Wer will, dass sein Programm auf jedem POSIX‐System
> funktioniert, muss sich darauf beschränken, nicht mehr als
> SSIZE_MAX Bytes lesen zu wollen. Hält er sich an die
> Beschränkung, können Funktionswerte <-1 (bisher) nicht vorkommen.
> Tut er es nicht, erklärt er sich mit dem einverstanden, was seine
> Implementierung festgelegt hat.

Da read() auch EINTR liefern darf, sollte das Programm es sowieso
mehrmals aufrufen können. Für die Schleife muss man dann nur noch
die Länge <=SSIZE_MAX pro Aufruf einbauen.

[Helmut Schellong]

Es ist vollkommen unklar, was 'result' umfaßt.
'return value' kann u.a. damit gemeint sein, muß aber nicht.
Es muß auch kein Wert gemeint sein, sondern eine andere
Operationsweise, etc.

In der Rationale steht noch folgendes:

|This volume of POSIX.1-2017 also limits the range further
|by requiring that the byte count be limited so
|that a signed return value remains meaningful.
|Since the return type is also a (signed) abstract type, the
|byte count can be defined by the implementation
|to be larger than an int can hold.

> <http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html#tag_16_474_04>:
>
> RETURN VALUE
>
> Upon successful completion, these functions shall return a
> non-negative integer indicating the number of bytes actually
> read. Otherwise, the functions shall return -1 and set errno
> to indicate the error.
>
> => Über Funktionswerte <-1 wird im POSIX‐Standard keine Aussage
> gemacht, außer der, dass für den Fall, dass mehr als SSIZE_MAX
> Bytes gelesen werden sollen, die Implementierung festlegen muss,
> was dann geschehen soll. Der C‐Standard macht überhaupt keine
> Aussage, weil die Funktion »read()« nicht darin enthalten ist.

POSIX legt nicht fest, daß nbyte>SSIZE_MAX eine Wirkung
auf den return-value haben soll.

>> Das war auch schon so, als beide Typen 'int' waren.
>> Daß die Typen heute ssize_t und size_t sind, ändert nichts daran.
>>
>> Wenn heute ein Wert 'len' übergeben wird, der größer ist als
>> der positive Wertbereich von ssize_t, werden eben weniger Bytes
>> in 'buf' kopiert als per 'len' angegeben, oder es wird
>> der Fehler EOVERFLOW oder ein anderer gegeben.
>> Mit ersterem muß sowieso gerechnet werden.
>
> Das geben weder der POSIX‐ noch der C‐Standard her.

Ich habe 'z.B.' oder ähnlich vergessen.
Aber weniger Bytes als per nbyte angegeben kann passieren.

> Fazit: Wer will, dass sein Programm auf jedem POSIX‐System
> funktioniert, muss sich darauf beschränken, nicht mehr als
> SSIZE_MAX Bytes lesen zu wollen. Hält er sich an die
> Beschränkung, können Funktionswerte <-1 (bisher) nicht vorkommen.
> Tut er es nicht, erklärt er sich mit dem einverstanden, was seine
> Implementierung festgelegt hat.
>
> Will man also wasserdicht programmieren, sind Funktionswerte >=0
> als Anzahl gelesener Bytes, der Funktionswert =-1 als im Standard
> definierter Fehlerfall mit im Standard definierten
> Fehlerbehandlungsmöglichkeiten und Funktionswerte < -1 als
> verbotene Werte zu behandeln. »Verboten« heißt: Das Programm
> kann überhaupt keine Annahmen mehr über den Zustand des
> File‐Descriptors machen. Es bleibt ihm nicht viel anderes übrig,
> als (nach Belieben) dem Anwender eine Fehlermeldung über einen den
> Standard sprengenden Fehler zu geben und danach diesen
> File‐Descriptor nicht mehr anzufassen (allenfalls noch, ihn zu
> schließen).

Ja, deshalb programmiere ich seit ca. 1987 so oder ähnl.:

for (max=2048; (nr= read(fd, buf, max), nr>0); N+=nr) {
//...
}
if (!nr) /*...*/;
else ERROR();

Seit langem verwende ich Wrapper-Funktionen wie z.B. readE().
Darin ist dann die ganze Fehlerbehandlung.
Standard-Maßnahme ist Abbruch des Programms.

> Siehe auch
> <http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html#tag_16_474_08_01>.
>
> Wenn ich das richtig verstanden habe, ist die Funktion »read()« im
> C‐Standard nicht definiert, jedoch im POSIX‐Standard.

fread() gibt es dafür, mit FILE*, wie üblich.


--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm

[Helmut Waitzmann]

Helmut Schellong <r...@schellong.biz>:

Ein Hinweis, was »result« umfasst, könnten folgende Sätze aus dem
oben genannten Abschnitt »DESCRIPTION« sein:

Before any action described below is taken, and if nbyte is
zero, the read() function may detect and return errors as
described below. In the absence of errors, or if error
detection is not performed, the read() function shall return
zero and have no other results.

»shall return zero and have no other results« legt nahe, dass
»shall return zero« ein Teil dessen ist, was »results« umfasst,
denn anderenfalls wäre das Wort »other« fehl am Platz.

»no other results« legt nahe, dass »results« nicht nur den
Funktionswert sondern die ganze Wirkung, die der Funktionsaufruf
hat, umfasst.

Das im Hinterkopf behaltend, nochmal zitiert:

>> If the value of nbyte is greater than {SSIZE_MAX}, the
>> result is implementation-defined.

=> Wenn man read mit einem Größenparameter > SSIZE_MAX aufruft,
ist alles – Funktionswert und Wirkung – implementation‐defined.

<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap01.html#tag_01_05_02>
erklärt »implementation‐defined«:

implementation-defined

Describes a value or behavior that is not defined by
POSIX.1-2017 but is selected by an implementor. The value or
behavior may vary among implementations that conform to
POSIX.1-2017. An application should not rely on the existence
of the value or behavior. An application that relies on such a
value or behavior cannot be assured to be portable across
conforming implementations.

The implementor shall document such a value or behavior so that
it can be used correctly by an application.

=> Wer will, dass sein Programm unter allen POSIX‐konformen
Umgebungen das gleiche Verhalten hat, muss den Größenparameter auf
Werte zwischen 0 und SSIZE_MAX beschränken.

Wer größere Werte nutzen will, dem garantiert der POSIX‐Standard,
dass er in der Dokumentation der Implementierung, die er nutzt,
nachlesen kann, was »read()« dann tut.

Die Implementierung ist völlig frei darin, festzulegen, was sie
dann tut. Angefangen von Stefans Beispiel einer Implementierung
auf einer 16‐Bit‐Maschine, bei der SSIZE_MAX = 32768 und
SIZE_MAX = 65536 ist und jeder negative Funktionswert < -1 nicht
als Fehleranzeiger sondern als Funktionswert + 65536 zu verstehen
ist, über eine Implementierung, die keine Daten liest und -1 als
Funktionswert liefert (also einen Fehler anzeigt), bis zu einer
Implementierung, die den aufrufenden Prozess mit einem KILL‐Signal
erschlägt, ist alles möglich. Es muss nur dokumentiert sein.

(In der »read«‐Handbuchseite meines Rechners heißt es:

SYNOPSIS
#include <unistd.h>

ssize_t read(int fd, void *buf, size_t count);

[…]

If count is greater than SSIZE_MAX, the result is
unspecified.

Auf gut Deutsch: »Wir wollen oder können nicht sagen, was dann
geschieht«.)

>
>In der Rationale steht noch folgendes:
>
>|This volume of POSIX.1-2017 also limits the range further
>|by requiring that the byte count be limited so
>|that a signed return value remains meaningful.
>|Since the return type is also a (signed) abstract type, the
>|byte count can be defined by the implementation
>|to be larger than an int can hold.

Da kommt mir noch eine Idee:

<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html#tag_13_65_03>:

DESCRIPTION

The <sys/types.h> header shall define at least the following
types:

[…]

size_t
Used for sizes of objects.
ssize_t
Used for a count of bytes or an error indication.

Dass »an error indication« tatsächlich der Wert -1 sein muss,
steht da nicht. Könnte es nicht auch ein Wert sein, der beim
Vergleich mit -1 den Wahrheitswert »wahr« liefert, wie im
folgenden?

Wenn ssize_t ein unsigned Integer‐Typ wäre, würde der
C‐Compiler im Code‐Schnipsel

ssize_t rc=read(…);

if (rc == (ssize_t) -1)
// Fehlerfall hier behandeln

den Fehlertest »rc == (ssize_t) -1« in

»rc == SSIZE_MAX«

umsetzen.

Wenn ssize_t dabei mindestens die Größe des Integer‐Typs unsigned
int hätte, könnte man den Typecast »(ssize_t)« sparen:

ssize_t rc=read(…);

if (rc == -1)
// Fehlerfall hier behandeln

Das ist quellcode‐kompatibel zu dem Fall, dass ssize_t ein signed
Typ ist.

Es funktioniert nur, wenn die Maschine negative Zahlen im
Zweierkomplement darstellt: Bei Einerkomplementdarstellung gibt
es keine negative Zahl, die beim Umwandeln per Type‐Cast die
positive Zahl SSIZE_MAX + 1 ergibt.

Scheitern würde allerdings

»if (rc < 0)«, weil »rc« keine Werte < 0 annehmen könnte.

Ist irgendwo festgelegt, dass »ssize_t« ein signed Integer‐Typ
sein muss? Falls nicht, spräche das sehr dafür, den Fehlertest am
Funktionswert der Funktion »read()« nicht auf < 0 sondern auf
== -1 zu machen.

>
>> <http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html#tag_16_474_04>:
>>
>> RETURN VALUE
>>
>> Upon successful completion, these functions shall return a
>> non-negative integer indicating the number of bytes actually
>> read. Otherwise, the functions shall return -1 and set errno
>> to indicate the error.
>>
>> => Über Funktionswerte <-1 wird im POSIX‐Standard keine Aussage
>> gemacht, außer der, dass für den Fall, dass mehr als SSIZE_MAX
>> Bytes gelesen werden sollen, die Implementierung festlegen muss,
>> was dann geschehen soll. Der C‐Standard macht überhaupt keine
>> Aussage, weil die Funktion »read()« nicht darin enthalten ist.
>
>POSIX legt nicht fest, daß nbyte>SSIZE_MAX eine Wirkung
>auf den return-value haben soll.

POSIX legt fest, dass nbyte > SSIZE_MAX die Wirkung hat, die von
der Implementierung definiert ist. Diese Wirkung kann (s. o.)
auch den Funktionswert umfassen.

=> Die Implementierung ist völlig frei darin, was sie im Fall
nbyte > SSIZE_MAX macht – den Funktionswert eingeschlossen. Sie
muss es allerdings festlegen.

[Helmut Schellong]

On 04/08/2019 09:05, Helmut Waitzmann wrote:
> Helmut Schellong <r...@schellong.biz>:
>> On 04/05/2019 17:44, Helmut Waitzmann wrote:

[... ...]

> Die Implementierung ist völlig frei darin, festzulegen, was sie
> dann tut. Angefangen von Stefans Beispiel einer Implementierung
> auf einer 16‐Bit‐Maschine, bei der SSIZE_MAX = 32768 und
> SIZE_MAX = 65536 ist und jeder negative Funktionswert < -1 nicht
> als Fehleranzeiger sondern als Funktionswert + 65536 zu verstehen
> ist, über eine Implementierung, die keine Daten liest und -1 als
> Funktionswert liefert (also einen Fehler anzeigt), bis zu einer
> Implementierung, die den aufrufenden Prozess mit einem KILL‐Signal
> erschlägt, ist alles möglich. Es muss nur dokumentiert sein.
>
> (In der »read«‐Handbuchseite meines Rechners heißt es:
>
> SYNOPSIS
> #include <unistd.h>
>
> ssize_t read(int fd, void *buf, size_t count);
>
> […]
>
> If count is greater than SSIZE_MAX, the result is
> unspecified.
>
> Auf gut Deutsch: »Wir wollen oder können nicht sagen, was dann
> geschieht«.)

Bei mir steht:
[EINVAL] The value nbytes is greater than INT_MAX.

So (oder ähnlich) kenne ich das schon immer.
Also: vernünftige, logische Werte.

Ich rate Stefan Reuther, mal zu prüfen, ob _wirklich_
40000 Bytes eingefüllt werden!
Ich vermute, das impl.def. Verhalten bei der 16bit-Implementation
ist nicht dokumentiert.

>> In der Rationale steht noch folgendes:
>>
>> |This volume of POSIX.1-2017 also limits the range further
>> |by requiring that the byte count be limited so
>> |that a signed return value remains meaningful.
>> |Since the return type is also a (signed) abstract type, the
>> |byte count can be defined by the implementation
>> |to be larger than an int can hold.
>
> Da kommt mir noch eine Idee:

[...]

> Ist irgendwo festgelegt, dass »ssize_t« ein signed Integer‐Typ
> sein muss? Falls nicht, spräche das sehr dafür, den Fehlertest am
> Funktionswert der Funktion »read()« nicht auf < 0 sondern auf
> == -1 zu machen.

/usr/include/x86/_limits.h:76:#define __SSIZE_MAX __LONG_MAX
/* max value for a ssize_t */
/usr/include/x86/_types.h:111:typedef __int64_t __ssize_t;
/* byte count or error */
/usr/include/x86/_types.h:120:typedef __int32_t __ssize_t;

/usr/include/limits.h:45:#define _POSIX_SSIZE_MAX 32767
/usr/include/x86/_limits.h:76:#define __SSIZE_MAX __LONG_MAX
/* max value for a ssize_t */
/usr/include/x86/_limits.h:86:#define __SSIZE_MAX __INT_MAX
/usr/include/sys/limits.h:72:#define SSIZE_MAX __SSIZE_MAX
/* max value for an ssize_t */

Ich sehe ssize_t seit Jahrzehnten ausnahmslos als signed:
ssize_t ist sprachlich signed size_t

[...]

>> POSIX legt nicht fest, daß nbyte>SSIZE_MAX eine Wirkung
>> auf den return-value haben soll.
>
> POSIX legt fest, dass nbyte > SSIZE_MAX die Wirkung hat, die von
> der Implementierung definiert ist. Diese Wirkung kann (s. o.)
> auch den Funktionswert umfassen.
>
> => Die Implementierung ist völlig frei darin, was sie im Fall
> nbyte > SSIZE_MAX macht – den Funktionswert eingeschlossen. Sie
> muss es allerdings festlegen.

Ich sehe das alles auch so, auch weiter oben.

Für mich steht allerdings fest, daß ssize_t unbedingt signed ist.
ssize_t ist der signed-Bruder von size_t.

[Michael Bäuerle]

Helmut Waitzmann wrote:
>
> [...]

> Ist irgendwo festgelegt, dass »ssize_t« ein signed Integer‐Typ
> sein muss?

Ja, siehe hier:
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html#tag_13_65_03>
|
| • blksize_t, pid_t, and ssize_t shall be signed integer types.
^^^^^^^ ^^^^^^

[Stefan Reuther]

Am 08.04.2019 um 13:03 schrieb Helmut Schellong:
> On 04/08/2019 09:05, Helmut Waitzmann wrote:
>> If count is greater than SSIZE_MAX, the result is
>> unspecified.
>>
>> Auf gut Deutsch: »Wir wollen oder können nicht sagen, was dann
>> geschieht«.)
>
> Bei mir steht:
> [EINVAL] The value nbytes is greater than INT_MAX.
>
> So (oder ähnlich) kenne ich das schon immer.
> Also: vernünftige, logische Werte.
>
> Ich rate Stefan Reuther, mal zu prüfen, ob _wirklich_
> 40000 Bytes eingefüllt werden!

Selbstverständlich werden sie das. Das ist auch zu erwarten, denn das
dazugehörige Syscall-Interface kennt nur unsigned-Werte in Prozessor-
Registern, und meldet die Fehler out-of-band (Carry-Flag).

> Ich vermute, das impl.def. Verhalten bei der 16bit-Implementation
> ist nicht dokumentiert.

Korrekt. Wobei die Implementation halt 30 Jahre alt ist und versucht,
das nachzubauen, was es damals unter *ix gab und noch nicht wirklich
POSIX hieß.

"Upon successful completion, int (sic!) returns an integer indicating
the number of bytes placed in the buffer; if the file was opened in text
mode, read does not count carriage returns or Ctrl-Z characters in the
number of bytes read. On error, it returns -1 and sets errno."


Stefan

[Rainer Weikusat]

read kann nur dann EINTR zurueckliefern, falls waehrend einem
blockierenden read ein Signal von einer benutzerdefinierten
Signalfunktion verarbeitet wurde, die zurueckkehrte.

[Bonita Montero]

>>        If the value of nbyte is greater than {SSIZE_MAX},
>>        the result is implementation-defined.

Das Problem ergibt sich doch sowieso nicht. Auf Systemen mit linearen
Adressraum ist size_t so groß wie ein Pointer. SSIZE_MAX wäre der halbe
Adressraum. Wann schreibt man schon mal einen Block mit der Größe des
halben Adressraums?

[Helmut Schellong]

Die Performance ist am besten mit 10000-20000 Byte Blockgröße.
Ein Aufruf read(fd, buf, 2000000000); wäre idiotisch.
Selbst das liegt noch unterhalb von INT_MAX.

[Bonita Montero]

>> Das Problem ergibt sich doch sowieso nicht. Auf Systemen mit linearen
>> Adressraum ist size_t so groß wie ein Pointer. SSIZE_MAX wäre der halbe
>> Adressraum. Wann schreibt man schon mal einen Block mit der Größe des
>> halben Adressraums?

> Die Performance ist am besten mit 10000-20000 Byte Blockgröße.

Was ist denn das für ein Unsinn? Es gibt einen gewissen fixen Overhead
der Teilweise im Kernel-Aufruf begründet ist. Es wird sicher so sein,
dass ab einer gewissen Blockgröße der nicht mehr ins Gewicht fällt so
dass es z.B. beim Schreiben von zig GB egal ist, ob man eine Blockgröße
von 100k oder einem 10MB hat. Daher muss man z.B. bei sevbuf() nicht
allzu große Buffer-Größen angeben.
Aber ein Optimum gibt es da nicht in dem Sinne, dass man da einen mitt-
leren Wert hat wo rechts *und* links davon die Performance schlechter
wird.

> Ein Aufruf  read(fd, buf, 2000000000);  wäre idiotisch.

Nicht unbedingt Es sind Fälle denkbar wo man das File komplett
im Speicher haben und nicht nur von vorne nach hinten lesen will.

[Helmut Schellong]

On 04/09/2019 17:49, Bonita Montero wrote:
>>> Das Problem ergibt sich doch sowieso nicht. Auf Systemen mit linearen
>>> Adressraum ist size_t so groß wie ein Pointer. SSIZE_MAX wäre der halbe
>>> Adressraum. Wann schreibt man schon mal einen Block mit der Größe des
>>> halben Adressraums?
>
>> Die Performance ist am besten mit 10000-20000 Byte Blockgröße.
>
> Was ist denn das für ein Unsinn? Es gibt einen gewissen fixen Overhead
> der Teilweise im Kernel-Aufruf begründet ist. Es wird sicher so sein,
> dass ab einer gewissen Blockgröße der nicht mehr ins Gewicht fällt so
> dass es z.B. beim Schreiben von zig GB egal ist, ob man eine Blockgröße
> von 100k oder einem 10MB hat. Daher muss man z.B. bei sevbuf() nicht
> allzu große Buffer-Größen angeben.
> Aber ein Optimum gibt es da nicht in dem Sinne, dass man da einen mitt-
> leren Wert hat wo rechts *und* links davon die Performance schlechter
> wird.

Das ist kein Unsinn, sondern eine getestete Tatsache.
Es gibt in der Tat einen für Performance optimalen Bereich.
In der realen Praxis, wo die Pufferdaten auch gelesen werden.

setvbuf() braucht man nicht, wenn read() einen Puffer füllt.
U.a. deshalb sind read()/write() grundsätzlich schneller
als die C-Standard-Funktionen.

Wenn der Puffer sehr klein ist, muß eine Schleife mit dem
read()-Aufruf entsprechend öfter durchlaufen werden:
Je kleiner der Puffer, desto langsamer die Arbeit mit read().

Je größer der Puffer, desto weniger optimal wird der Prozessor
benutzt. Das Cache-System eines Prozessors arbeitet in einem
bestimmten Puffer-Größenbereich optimal.

>> Ein Aufruf  read(fd, buf, 2000000000);  wäre idiotisch.
>
> Nicht unbedingt Es sind Fälle denkbar wo man das File komplett
> im Speicher haben und nicht nur von vorne nach hinten lesen will.

In 99,99% aller Fälle sind Puffergrößen im GB-Bereich idiotisch,
wie ich es schrieb.
Dem Prozeß muß immerhin diese Speichermenge zugeordnet werden.
Und die kann kaum im Stack Platz finden, was optimal wäre.

Es kann dann auch oft vorkommen, daß das System eine erforderliche
Speichermenge dem Prozeß nicht zur Verfügung stellen kann.
Eine weitere Problematisierung entsteht, wenn mehrere solche
Prozesse parallel laufen sollen.
Beispielsweise, wenn vier Verzeichnisse gleichzeitig bearbeitet
werden sollen - man hat ja schließlich 8 Kerne (bis 28).

Es wird dann auch vorkommen, daß viel mehr als 2 GB Puffer
gebraucht werden.
Ab einer gewissen Grenze müssen andere Konzepte verfolgt werden,
wenn die Forderung ist, daß eine Datei unbedingt komplett in den
Arbeitsspeicher passen muß.
Und diese anderen Konzepte sind dann wesentlich weniger performant.

[Bonita Montero]

> Das ist kein Unsinn, sondern eine getestete Tatsache.
> Es gibt in der Tat einen für Performance optimalen Bereich.

Blödsinn. Es gibt einen Bereich *ab* dem es keine wesentliche
Performance-Steigerung gibt.

> setvbuf() braucht man nicht, wenn read() einen Puffer füllt.
> U.a. deshalb sind read()/write() grundsätzlich schneller
> als die C-Standard-Funktionen.

Du hast mich nicht verstanden. setvbuf() setzt ja eben die
Buffer-Größe für das dem fread() zugrundeliegende read().

> Je größer der Puffer, desto weniger optimal wird der Prozessor
> benutzt. Das Cache-System eines Prozessors arbeitet in einem
> bestimmten Puffer-Größenbereich optimal.

Wenn man nicht gerade "Speicher-Benchmarks" auf solchen Puffern
schreibt, sondern die Daten noch interpretiert, dann wird das
nicht so ins Gewicht fallen.

> In 99,99% aller Fälle sind Puffergrößen im GB-Bereich idiotisch,
> wie ich es schrieb.

Es ist aber eben oft ziemlich unhandlich, in einer Schleife im Puffer
zu pointern und wenn der an das Ende stößst einen Block nachzulesen.
Einfach den ganzen Krempel en-bloc einlesen und einfach nur den
Pointer fortschiebnen ist wesentlich komfortabler.
Ein weiteres Problem ist, dass wenn ich nicht gerade chars lese,
sondern Datentypen die mehrere Wörter haben ich nicht weiß ob
Wortgrenzen über den Puffer-Rand hinausgehen.

> Es kann dann auch oft vorkommen, daß das System eine erforderliche
> Speichermenge dem Prozeß nicht zur Verfügung stellen kann.

Ist meistens nicht realistisch.

> Ab einer gewissen Grenze müssen andere Konzepte verfolgt werden,
> wenn die Forderung ist, daß eine Datei unbedingt komplett in den
> Arbeitsspeicher passen muß.
> Und diese anderen Konzepte sind dann wesentlich weniger performant.

Memory-mapping ist z.B. nicht inperformant. Die Größe der Blöcke
die vom Kernel kommen entsprechen einer Page und da die OSe alle
die sequentiellen Zugriffe erkennen führen die auch ein entspre-
chendes Read-Ahead durch. Und nutzt man noch zusätzlich madvise(),
dann werden alte Pages auch früzeitig aus dem RAM geworfen, dass
die gemappten Pages nichts wichtiges aus dem Speicher werfen.

[Helmut Schellong]

On 04/09/2019 20:29, Bonita Montero wrote:
>> Das ist kein Unsinn, sondern eine getestete Tatsache.
>> Es gibt in der Tat einen für Performance optimalen Bereich.
>
> Blödsinn. Es gibt einen Bereich *ab* dem es keine wesentliche
> Performance-Steigerung gibt.

Nein.
Es gibt einen Größenbereich für den Puffer, in dem
die Performance am höchsten ist.
Das ist einfach so und es wurde durch Messung bestätigt.

>> setvbuf() braucht man nicht, wenn read() einen Puffer füllt.
>> U.a. deshalb sind read()/write() grundsätzlich schneller
>> als die C-Standard-Funktionen.
>
> Du hast mich nicht verstanden. setvbuf() setzt ja eben die
> Buffer-Größe für das dem fread() zugrundeliegende read().

Wird so sein.
Aber dieser Thread heißt: "read(.....)".

>> Je größer der Puffer, desto weniger optimal wird der Prozessor
>> benutzt. Das Cache-System eines Prozessors arbeitet in einem
>> bestimmten Puffer-Größenbereich optimal.
>
> Wenn man nicht gerade "Speicher-Benchmarks" auf solchen Puffern
> schreibt, sondern die Daten noch interpretiert, dann wird das
> nicht so ins Gewicht fallen.

Die Performance geht zurück.
Bei 30 KB war sie geringer als bei 15 KB.
Es war keine Rede davon, um wieviel geringer.

>> In 99,99% aller Fälle sind Puffergrößen im GB-Bereich idiotisch,
>> wie ich es schrieb.
>
> Es ist aber eben oft ziemlich unhandlich, in einer Schleife im Puffer
> zu pointern und wenn der an das Ende stößst einen Block nachzulesen.
> Einfach den ganzen Krempel en-bloc einlesen und einfach nur den
> Pointer fortschiebnen ist wesentlich komfortabler.
> Ein weiteres Problem ist, dass wenn ich nicht gerade chars lese,
> sondern Datentypen die mehrere Wörter haben ich nicht weiß ob
> Wortgrenzen über den Puffer-Rand hinausgehen.

Verstehe ich; es ist etwas einfacher zu programmieren, wenn
alles auf einen Schlag eingelesen wird.
Ein besserer Algorithmus liegt aber vor, wenn das nicht getan wird,
sondern man sich mehr Mühe gibt.

>> Es kann dann auch oft vorkommen, daß das System eine erforderliche
>> Speichermenge dem Prozeß nicht zur Verfügung stellen kann.
>
> Ist meistens nicht realistisch.

Kommt drauf an, wieviel RAM man in seinem PC hat.
Ich habe nur 4 GB - es wird Zeit, daß ich mir einen neuen PC baue.
Denn ich erhalte von diversen Video-Programmen unter Windows
oft Fehlermeldungen wegen zu wenig RAM.

Ich habe schon festgestellt, daß diese Video-Programme die Videos
komplett ins RAM speichern wollen - was jedoch nicht geht.
Dadurch versagen diese Programme und sind nicht nutzbar.

>> Ab einer gewissen Grenze müssen andere Konzepte verfolgt werden,
>> wenn die Forderung ist, daß eine Datei unbedingt komplett in den
>> Arbeitsspeicher passen muß.
>> Und diese anderen Konzepte sind dann wesentlich weniger performant.
>
> Memory-mapping ist z.B. nicht inperformant. Die Größe der Blöcke
> die vom Kernel kommen entsprechen einer Page und da die OSe alle
> die sequentiellen Zugriffe erkennen führen die auch ein entspre-
> chendes Read-Ahead durch. Und nutzt man noch zusätzlich madvise(),
> dann werden alte Pages auch früzeitig aus dem RAM geworfen, dass
> die gemappten Pages nichts wichtiges aus dem Speicher werfen.

Um solche Konzepte geht es aber nicht.
Es geht darum, _beliebig_ große Dateien bearbeiten zu können.
Die erforderlichen Konzepte sind wesentlich komplexer
und daher stark unterschiedlich.

Ein PC kann heute maximal 128 GB RAM haben, nicht aber 10 TB.

[Bonita Montero]

>> Je größer der Puffer, desto weniger optimal wird der Prozessor
>> benutzt. Das Cache-System eines Prozessors arbeitet in einem
>> bestimmten Puffer-Größenbereich optimal.

> Wenn man nicht gerade "Speicher-Benchmarks" auf solchen Puffern
> schreibt, sondern die Daten noch interpretiert, dann wird das
> nicht so ins Gewicht fallen.

Und nochwas: hier ist eigentlich immer die Gewschwindigkeit der
Festplatte oder SSD maßgeblich. Da ist das bisschen Unterschied
an CPU-Last völlig egal.

[Bonita Montero]

>> Blödsinn. Es gibt einen Bereich *ab* dem es keine wesentliche
>> Performance-Steigerung gibt.

> Nein.
> Es gibt einen Größenbereich für den Puffer, in dem
> die Performance am höchsten ist.

Wo schrob ich das? Die Performance nähert sich eben mit größerer
Puffergröße asymptotisch einem Maximum; irgendwo gibt es also eine
Größe wo es keinen wesentlichen Unterschied in der CPU-last gibt.

>>> setvbuf() braucht man nicht, wenn read() einen Puffer füllt.
>>> U.a. deshalb sind read()/write() grundsätzlich schneller
>>> als die C-Standard-Funktionen.

>> Du hast mich nicht verstanden. setvbuf() setzt ja eben die
>> Buffer-Größe für das dem fread() zugrundeliegende read().

> Wird so sein.
> Aber dieser Thread heißt: "read(.....)".

Ja und? fread() setzt darauf auf.

>> Wenn man nicht gerade "Speicher-Benchmarks" auf solchen Puffern
>> schreibt, sondern die Daten noch interpretiert, dann wird das
>> nicht so ins Gewicht fallen.

> Die Performance geht zurück.

Eigentlich nicht, denn hier ist die Performance der Platte, SSD oder
des Netzwerk-Interfaces maßgeblich. Der Unterschied an CPU-Zeit ist
da zu vernachlässigen bzw. ändert auch nichts am Durchsatz.

>> Es ist aber eben oft ziemlich unhandlich, in einer Schleife im Puffer
>> zu pointern und wenn der an das Ende stößst einen Block nachzulesen.
>> Einfach den ganzen Krempel en-bloc einlesen und einfach nur den
>> Pointer fortschiebnen ist wesentlich komfortabler.
>> Ein weiteres Problem ist, dass wenn ich nicht gerade chars lese,
>> sondern Datentypen die mehrere Wörter haben ich nicht weiß ob
>> Wortgrenzen über den Puffer-Rand hinausgehen.

> Verstehe ich; es ist etwas einfacher zu programmieren, wenn
> alles auf einen Schlag eingelesen wird.
> Ein besserer Algorithmus liegt aber vor, wenn das nicht getan
> wird, sondern man sich mehr Mühe gibt.

Wie oben beschrieben drehst Du nur ein bisschen an der CPU-Last, aber
nicht am Durchsatz.

>> Memory-mapping ist z.B. nicht inperformant. Die Größe der Blöcke
>> die vom Kernel kommen entsprechen einer Page und da die OSe alle
>> die sequentiellen Zugriffe erkennen führen die auch ein entspre-
>> chendes Read-Ahead durch. Und nutzt man noch zusätzlich madvise(),
>> dann werden alte Pages auch früzeitig aus dem RAM geworfen, dass
>> die gemappten Pages nichts wichtiges aus dem Speicher werfen.

> Um solche Konzepte geht es aber nicht.
> Es geht darum, _beliebig_ große Dateien bearbeiten zu können.

Beliebig große Dateien hast Du fast nur bei Datenbanken, und da
wird völlig anders gearbeitet, also mit random-access-I/O, eigenem
Caching und asynchronem I/O.

[Helmut Schellong]

Ein Betriebssystem ist sehr komplex.

CPU: 2.7% user, 0.0% nice, 0.2% system, 0.0% interrupt, 97.1% idle
Mem: 813M Active, 1032M Inact, 888M Laundry, 643M Wired, 394M Buf, 541M Free
Swap: 5120M Total, 300M Used, 4819M Free, 5% Inuse

Einfache Überlegungen führen da nicht zu korrekten Antworten.

[Bonita Montero]

>> Und nochwas: hier ist eigentlich immer die Gewschwindigkeit der
>> Festplatte oder SSD maßgeblich. Da ist das bisschen Unterschied
>> an CPU-Last völlig egal.

> Ein Betriebssystem ist sehr komplex.

An der Stelle gibt's nichts komplexes. Der Unterschied ist
hier ein bisschen CPU-Last und fast gar nicht der Durchsatz.

[Helmut Schellong]

On 04/09/2019 21:14, Bonita Montero wrote:
[...]

>> Um solche Konzepte geht es aber nicht.
>> Es geht darum, _beliebig_ große Dateien bearbeiten zu können.
>
> Beliebig große Dateien hast Du fast nur bei Datenbanken, und da
> wird völlig anders gearbeitet, also mit random-access-I/O, eigenem
> Caching und asynchronem I/O.

Beispiel:
Ich habe ein Kommando, das sucht Byte-Folgen innerhalb von Dateien.
Ich verwende einen Puffer[10*1024] und die maximale Länge der
gesuchten Byte-Folge beträgt 4*1024.

Das ist sehr einfacher hochperformanter Code, der beliebig
große Dateien durchsuchen kann - wirklich so groß, wie das
Dateisystem es zuläßt!

[Bonita Montero]

>> Beliebig große Dateien hast Du fast nur bei Datenbanken, und da
>> wird völlig anders gearbeitet, also mit random-access-I/O, eigenem
>> Caching und asynchronem I/O.

> Beispiel:
> Ich habe ein Kommando, das sucht Byte-Folgen innerhalb von Dateien.
> Ich verwende einen Puffer[10*1024] und die maximale Länge der
> gesuchten Byte-Folge beträgt 4*1024.
> Das ist sehr einfacher hochperformanter Code, der beliebig
> große Dateien durchsuchen kann - wirklich so groß, wie das
> Dateisystem es zuläßt!

Trotzdem ist die ganze Sache durch die SSD / Platte begrenzt.

[Bonita Montero]

> Das ist sehr einfacher hochperformanter Code, der beliebig
> große Dateien durchsuchen kann - wirklich so groß, wie das
> Dateisystem es zuläßt!

In einen 64-Bit-Adressraum lässt sich das bequem mmap()en.
Der Durchsatz ist dank Read-Ahead so gut wie der selbe.
Und der Code ist schneller geschrieben und wartbarer.
Das bissen CPU-Last mehr - interessiert keinen.

[Helmut Schellong]

Ich habe festgestellt, daß Betriebssyteme bei großen
Festplattenzugriffen am Stück oft für 1 bis 3 s
unbedienbar sind.
Das ist verwunderlich - haben Betriebssysteme doch
Scheduler und Prozessoren mehrere Kerne.

Es ist nach meiner Erfahrung günstig, wenn alle Arbeiten
gemischt in optimal großen Häppchen abgearbeitet werden.

[Bonita Montero]

>> In einen 64-Bit-Adressraum lässt sich das bequem mmap()en.
>> Der Durchsatz ist dank Read-Ahead so gut wie der selbe.
>> Und der Code ist schneller geschrieben und wartbarer.
>> Das bissen CPU-Last mehr - interessiert keinen.

> Ich habe festgestellt, daß Betriebssyteme bei großen
> Festplattenzugriffen am Stück oft für 1 bis 3 s
> unbedienbar sind.

Das hängt davon ab, ob durch das Einlesen oder Einmappen der Datei
anderes aus dem Speicher verdrängt wird. Mappt man aber, dann kann
man mit madvise() nach dem Bearbeiten der Daten Bereiche die man
nicht mehr bracht so markieren, dass die für andere Pages die hi-
neinkommen bevorzugt aus dem RAM geworfen werden.
Ansonsten: wenn man durch das Lesen längerer Dateien keine Swapping
-Problmatik hat, dann kann man sich das aus sparen und das von dir
genannte Problem tritt nicht audf.

[Bonita Montero]

> Ich habe festgestellt, daß Betriebssyteme bei großen
> Festplattenzugriffen am Stück oft für 1 bis 3 s
> unbedienbar sind.

Achso, nochwas: das kann dir auch beim stückweisen Einlesen passieren.
Und zwar dadurch, dass Pages des OS-Caches zunehmend andere Pages ver-
drängen. Also Pages die ohnehin discardable sind weil die nicht zum
Working-Set irgendeines Prozesses oder des Kernels gehören.

[Helmut Schellong]

Ich muß feststellen, daß ich die Aufgaben eines Betriebssystems
im Mikrokontroller-Bereich besser implementierte als dies
in jedem von mir genutztem Betriebssystem der Fall ist.

Das Verhalten einer Steuerungs- und Monitoring-Software
für Industrieanlagen (z.B. 300000 €) war so, als ob
alle Operationen gleichzeitig bearbeitet wurden.

Dabei werkelte lediglich ein einziger Mikrokontroller
16 Bit, 16 MHz Takt, 6 KB RAM.
Zu einer Zeit wurde also immer nur eine Operation bearbeitet.

Das Gerät hatte ~20000 Konfigurations-Parameter und steuerte
und überwachte bis zu 130 CanBus-Geräte, die jeweils bis
zu 8 Meßwerte sandten.
Etwa 30 Meßwerte hatte die Unit selbst per ADC gemessen.
Es gab Display und Tasten und etwa 70 Bedienungsmenüs.
Über eine Remote-Windows-Software konnte alternativ und
parallel alles gesteuert und konfiguriert werden, über
zwei Schnittstellen gleichzeitig.

[Bonita Montero]

> Ich muß feststellen, daß ich die Aufgaben eines Betriebssystems
> im Mikrokontroller-Bereich besser implementierte als dies
> in jedem von mir genutztem Betriebssystem der Fall ist.

> ...

> Dabei werkelte lediglich ein einziger Mikrokontroller
> 16 Bit, 16 MHz Takt, 6 KB RAM.
> Zu einer Zeit wurde also immer nur eine Operation bearbeitet.

Das kann man doch nicht vergleichen. Die Anforderungen sind da
völlig andere und auf einem Mikrokcontroller mit 6kB RAM kriegst
Du nichts was sich Betriebssystem nennen kann.

[Helmut Schellong]

Die Funktionen kann man vergleichen.
Ich habe auf dem Mikrokontroller quasi ein Betriebssystem
entwickelt und implementiert.
Es gibt z.B. mehrere Scheduler.
Eine Art Dateisystem gibt es sogar, in einem externen EPROM.

[Rainer Weikusat]

Helmut Schellong <r...@schellong.biz> writes:
> On 04/10/2019 15:41, Bonita Montero wrote:
>>> Ich muß feststellen, daß ich die Aufgaben eines Betriebssystems
>>> im Mikrokontroller-Bereich besser implementierte als dies
>>> in jedem von mir genutztem Betriebssystem der Fall ist.
>>> ...
>>> Dabei werkelte lediglich ein einziger Mikrokontroller
>>> 16 Bit, 16 MHz Takt, 6 KB RAM.
>>> Zu einer Zeit wurde also immer nur eine Operation bearbeitet.
>>
>> Das kann man doch nicht vergleichen. Die Anforderungen sind da
>> völlig andere und auf einem Mikrokcontroller mit 6kB RAM kriegst
>> Du nichts was sich Betriebssystem nennen kann.
>
> Die Funktionen kann man vergleichen.
> Ich habe auf dem Mikrokontroller quasi ein Betriebssystem
> entwickelt und implementiert.
> Es gibt z.B. mehrere Scheduler.
> Eine Art Dateisystem gibt es sogar, in einem externen EPROM.

https://en.wikipedia.org/wiki/PDP-7

So ungefaehr dieselbe Groessenordnung. Aber Leute, die Angst davor
haben, dass sich ihr 2.x Ghz Laptop mit Shellscripts einen Bruch hebt,
koennen sich wohl gar nicht vorstellen, dass man sowas ueberhaupt
programmieren kann.

[Bonita Montero]

> https://en.wikipedia.org/wiki/PDP-7
> So ungefaehr dieselbe Groessenordnung. Aber Leute, die Angst davor
> haben, dass sich ihr 2.x Ghz Laptop mit Shellscripts einen Bruch hebt,
> koennen sich wohl gar nicht vorstellen, dass man sowas ueberhaupt
> programmieren kann.

Ich bin froh, dass wir so ein primitives Technik-Niveau überwunden
haben.

[Claus Reibenstein]

Bonita Montero schrieb am 09.04.2019 um 20:29:

>> setvbuf() braucht man nicht, wenn read() einen Puffer füllt.
>> U.a. deshalb sind read()/write() grundsätzlich schneller
>> als die C-Standard-Funktionen.

Schrieb wer? Bitte lass die Namen der Zitierten stehen.

> Du hast mich nicht verstanden. setvbuf() setzt ja eben die
> Buffer-Größe für das dem fread() zugrundeliegende read().

setvbuf() ist ISO-C und setzt die Puffergröße für einen Stream. read()
ist POSIX und verwendet keinen Stream.

Gruß
Claus

[Bonita Montero]

>> Du hast mich nicht verstanden. setvbuf() setzt ja eben die
>> Buffer-Größe für das dem fread() zugrundeliegende read().

> setvbuf() ist ISO-C und setzt die Puffergröße für einen Stream.
> read() ist POSIX und verwendet keinen Stream.

Das tut nichts zu meinen Aussagen.
Der svbuf()-Aufruf setzt eben auf einem Unix-System den Buffer
der letzlich mit read() befüllt wird.

[Bonita Montero]

> setvbuf() ist ISO-C und setzt die Puffergröße für einen Stream.
> read() ist POSIX und verwendet keinen Stream.

Ein Strom ist es wenn entweder ein File-Poitner fortschreitet oder
ich wie bei einem Stream-Socket einen kontinuierlichen Datenstrom
lese; und beides ist bei read() der Fall.

[Helmut Schellong]

Primitiv ist das falsche Wort.
Die Quantitäten sind heute beträchtlich größer,
die Qualitäten vergleichsweise kaum.

[Bonita Montero]

>> Ich bin froh, dass wir so ein primitives Technik-Niveau
>> überwunden haben.

> Primitiv ist das falsche Wort.
> Die Quantitäten sind heute beträchtlich größer,
> die Qualitäten vergleichsweise kaum.

Sehe ich anders. Heute hat man die Kapazitäz um Systeme mit Abstrak-
schichten aufeinander aufzubauen und viel mehr Funktionalität noch
programmiertechnisch handhabbar zu machen.

[Rainer Weikusat]

Helmut Schellong <r...@schellong.biz> writes:
> On 04/10/2019 18:30, Bonita Montero wrote:
>>> https://en.wikipedia.org/wiki/PDP-7
>>> So ungefaehr dieselbe Groessenordnung. Aber Leute, die Angst davor
>>> haben, dass sich ihr 2.x Ghz Laptop mit Shellscripts einen Bruch hebt,
>>> koennen sich wohl gar nicht vorstellen, dass man sowas ueberhaupt
>>> programmieren kann.
>>
>> Ich bin froh, dass wir so ein primitives Technik-Niveau überwunden
>> haben.
>
> Primitiv ist das falsche Wort.
> Die Quantitäten sind heute beträchtlich größer,
> die Qualitäten vergleichsweise kaum.

Er, sie oder es meint damit "Ich kann die Bourne-shell syntax auch nicht
[haha] aber sie ist echt furchtbar!" ("Was das Bauer nit kennt" ...).

[Rainer Weikusat]

Nachtrag: Zumindestens nehme ich das mal an. Es koennte sich auch auf
PDP-7-Rechner bezogen haben.

[Helmut Schellong]

Ich zeige mal ein Schema:

============================================================================
/* Schema Mikrokontroller-Scheduling - Helmut Schellong 11.4.2019 */

interrupt void Irpt_maschine(void) // alle 4 ms
{
static BYTE mcase;
Mleds();
// ...
switch(mcase) { // je 0,5 .. 3 ms
case 0: Mc000(); /*...*/; break;
case 1: Mc001(); /*...*/; break;
// ...
case 248: Mc248(); /*...*/; break;
case 249: Mc249(); /*...*/; break;
}
if (++mcase>=250) mcase=0;
// 250 * 4 ms == 1 s
return;
}

Durch vorstehenden Interrupt-Handler wird die gesamte
nichtinteraktive Steuerung der Industrie-Anlage vorgenommen.

Eine CanBus-Message mit Antwort wird in weniger als 4 ms abgewickelt.
Im Switch250 'stecken' auch maximal 130 Can-Geräte.
Deren Resultate werden in den höheren Cases verarbeitet.

Jede Funktion wird 1-mal pro Sekunde aufgerufen.
Das ermöglicht in jeder Funktion einfache Sekunden-Timer.


void main(void)
{
//...
while (1) {
if (MAINCNT) {
static UNS4 mc, tmc;
if (++mc, MU.ul64ms-tmc>=16*4) MU.maincnt=mc, mc=0, tmc=MU.ul64ms;
}
if (MU.req) Requests();
Main_cmd(0);
Main_menu('k');
WatchDog_RESET;
}
}

Die main-Schleife wird im Default-Zustand 20000-mal
pro Sekunde durchlaufen.
Mindestens mehrere tausend mal.

Der 16bit-Mikrokontroller hat einen 32bit-Akku
und vier 32bit-Register.

MU.ul64ms ist als 32bit-Variable ein globaler Universal-Timer.
Dessen Inhalt kippt nach mehr als 8 Jahren auf Null.
Das kommt in der Praxis nie vor.

MU.req hat ebenfalls 32 Bit, und kann daher
maximal 32 asynchrone Aufträge aufnehmen.

Das Display (Main_menu) wird im Abstand von 0,5 s aktualisiert.
Schneller wäre Unfug.


interrupt void Irpt_1ms(void) // jede ms
{
static BYTE t10ms;
if (!(++MU.u1ms&63)) ++MU.ul64ms;
if (MU.Delay_timer) --MU.Delay_timer; // Delay(ms);
if (++t10ms>=10) t10ms=0, KeyWatch();
return;
}

Die Tasten sind entprellt und haben ein automatisches
vierstufiges Tast-Repeat durch länger drücken.

Der Mikrokontroller 16 Bit, 16 MHz, 50 mA Stromaufnahme,
100 Pins, Preis < 10 €, bewältigt eine Industrieanlage,
die 300000 € kosten und eine Fabrikhalle füllen kann.
Sofern ein guter Programmierer dahintersteht.

Es wird hier nur ein winziges Schema gezeigt.
Die Quelle hat 75000 Zeilen und 2,7 MB!
============================================================================

Ich habe mal irgendwo gelesen, daß Boeing für das Ausfahren
des Fahrwerks ~20 Millionen Byte Quellcode braucht.
Ich hatte schon öfter den Eindruck, daß in vielen Bereichen
des Wahnsinns fette Beute umher geht...

[Juergen Ilse]

Hallo,

Den Buffer fuer fread(). Dass fread() zur Implementierung read() verwendet,
aendert *nichts* an der Tatsache, dass es keinen direkten Zusammenhang
zwischen read() und setvbuf() gibt.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

In de.comp.os.unix.programming Bonita Montero <Bonita....@gmail.com> wrote:

Ein stream und ein handle sind in C grundsaetzlich erst einmal unterschied-
liche Dinge: ein Stream wird durch einen Pointer auf eine Datenstruktur
vom Typ FILE (definiert in <stdio.h>) definiert, ein Handle (oder auch
"Filedescriptor") ist ein int, der eine (auf system-Ebene) geoeffnete
Datei representiert. read() und write sind System-Funktionen, die auf
handles (filedescriptors) arbeiten, fread() und fwrite() sind library-
funktionen, die mit handles nichts anfangen koennen sondern mit der
FILE Datenstruktur arbeiten. setvbuf() arbeiten mit FILE pointern, nicht
mit handles. Auf der Ebene auf der mit handles gearbeitet wird, aendert
die funktion setvbuf ueblicherweise *ueberhaupt* *nichts*, denn sie ist
eine Ebene hoeher angesiedelt ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Bonita Montero]

> Den Buffer fuer fread(). Dass fread() zur Implementierung read() verwendet,
> aendert *nichts* an der Tatsache, dass es keinen direkten Zusammenhang
> zwischen read() und setvbuf() gibt.

Es gibt wie gesagt den von mir geschilderten übergeordnetn Zusammenhang
der Standard-Bibliothek.

[Bonita Montero]

Du interpretierst die auch die Dinge wie Du willst.
Du solltest aber mal den Artikel "Datenstrom" in der WP lesebn.

[Juergen Ilse]

Hallo,

In de.comp.os.unix.programming Bonita Montero <Bonita....@gmail.com> wrote:

> Du interpretierst die auch die Dinge wie Du willst.
> Du solltest aber mal den Artikel "Datenstrom" in der WP lesebn.

Im Zusammenhang mit der Programmiersprache C sollte man unter "Stream" auch
das verstehen, was ein Stream laut Sprach Standard fuer die Sprache C ist
(nein, das ist nicht zwingend das selbe, was du zu dem Stichwort irgendwo
in der Wikipedia abseits der Sprache C zu fi9nden glaubst). Der Begriff ist
im Kontext der Programmiersprache C klar durch den Sprachstandard festgelegt.
Wenn in C von einem "stream" die Rede ist, dann ist auch exakt das gemeint
und nicht irgendwelches allgemeine Zeugs aus der Wikipedia. Dafuer gibt es
diesen Standard fuer die Progr4ammiersprache C.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Bonita Montero]

Stream = Datenstrom.

[Claus Reibenstein]

setvbuf() ist ISO-C, read() nicht. setvbuf() hat nichts mit dem Buffer
zu tun, den read() benutzt. Es gibt keinen "übergeordneten Zusammenhang"
(was immer "übergeordnet" in diesem Zusammenhang bedeuten soll). Es ist
nicht mal sicher, dass fread() überhaupt read() benutzt.

Du konstruierst da etwas, was gar nicht existiert.

Gruß
Claus

[Bonita Montero]

>>> Den Buffer fuer fread(). Dass fread() zur Implementierung read() verwendet,
>>> aendert *nichts* an der Tatsache, dass es keinen direkten Zusammenhang
>>> zwischen read() und setvbuf() gibt.

>> Es gibt wie gesagt den von mir geschilderten übergeordnetn Zusammenhang
>> der Standard-Bibliothek.

> setvbuf() ist ISO-C, read() nicht. setvbuf() hat nichts mit dem Buffer
> zu tun, den read() benutzt. Es gibt keinen "übergeordneten Zusammenhang"
> (was immer "übergeordnet" in diesem Zusammenhang bedeuten soll). Es ist
> nicht mal sicher, dass fread() überhaupt read() benutzt.

Doch, auf einem Unix-System nutzt fread() read().
Und der Puffer den read() dann bentuzt kann man mit svbuf() setzen.

[Juergen Ilse]

Hallo,

In de.comp.os.unix.programming Bonita Montero <Bonita....@gmail.com> wrote:

Stimmt (ueblicherweise, wenn auch nicht notwendigerweise). Aber wenn du in
deinem eigenen Programm direkt read() statt fread() verwendest, hat ein vor-
heriges setvbuf i.d.R. exakt *gar* *keine* Wirkung, weil setvbuf lediglich
die fuer fread() verwendeten Buffereinstellungen aendert, und du deren
Nutzung durch Vermeidung von fread() komplett umgehst.

> Und der Puffer den read() dann bentuzt kann man mit svbuf() setzen.

Quatsch. setvbuf() aendert an den Buffereinstellungen fuer fread() und hat
mit read() nichts zu tun. Lies endlich mal die Dokumentation statt wild
herumzuspekulieren.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

In de.comp.os.unix.programming Bonita Montero <Bonita....@gmail.com> wrote:

> Stream = Datenstrom.

Im Zusammenhang mit der Sprache C ist das nicht zwingend zutreffend.
Lies doch endlich mal den Standard! Oder die man-pages auf dem unix
System! Oder irgendein gutes C-Buch!

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Bonita Montero]

> Stimmt (ueblicherweise, wenn auch nicht notwendigerweise). Aber wenn du in
> deinem eigenen Programm direkt read() statt fread() verwendest, hat ein vor-
> heriges setvbuf i.d.R. exakt *gar* *keine* Wirkung, weil setvbuf lediglich
> die fuer fread() verwendeten Buffereinstellungen aendert, und du deren
> Nutzung durch Vermeidung von fread() komplett umgehst.

Ach!

>> Und der Puffer den read() dann bentuzt kann man mit svbuf() setzen.

> Quatsch. setvbuf() aendert an den Buffereinstellungen fuer fread() ...

Du verstehst mal wieder alles verkehrt. Ich sagte nur, dass der Buffer
den fread() für seine read()-Aufrufe nutzt eben via setvbuf gesetztz
werden kann.

und hat
> mit read() nichts zu tun. Lies endlich mal die Dokumentation statt wild
> herumzuspekulieren.
>
> Tschuess,
> Juergen Ilse (jue...@usenet-verwaltung.de)
>

--
http://facebook.com/bonita.montero/

[Bonita Montero]

>> Stream = Datenstrom.

> Im Zusammenhang mit der Sprache C ist das nicht zwingend zutreffend.
> Lies doch endlich mal den Standard! Oder die man-pages auf dem unix
> System! Oder irgendein gutes C-Buch!

Jetzt hör mit den Wortklaubereien auf. Sowohl das was man mit read()
liest als auch mit fread(), das sind beides Datenströme. Und die nennt
man im englischen nun mal Streams.

[Juergen Ilse]

Hallo,

In de.comp.os.unix.programming Bonita Montero <Bonita....@gmail.com> wrote:

> Du verstehst mal wieder alles verkehrt. Ich sagte nur, dass der Buffer
> den fread() für seine read()-Aufrufe nutzt eben via setvbuf gesetztz
> werden kann.

Warum faselst du dann dauernd von read() herum, wenn setvbuf() doch nur
*ausschliesslich* auf die funktion von fread() Einfluss hat und direkte
read() Aufrufe davon voellig unbeeinflusst sind?
Btw. verlangt der standard keienswegs, dass fread() mittels read() imple-
emntiert werden muss. Es waere auch durchaus standardkonform, wenn z.B.
fread() (library funktion) und read() (Systemaufruf) direkt auf die selbe
noch mehr "low level" Funktion zurueckgreifen wuerden und fread() nicht
mittels read() implementiert waere.

>> Lies endlich mal die Dokumentation statt wild herumzuspekulieren.

Dabei bleibe ich nach wie vor, solange du noch immer nicht der Sprache C
entsprechend sauber zwischen file-handle und file-pointer unterscheiden
kannst ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Bonita Montero]

>> Du verstehst mal wieder alles verkehrt. Ich sagte nur, dass der Buffer
>> den fread() für seine read()-Aufrufe nutzt eben via setvbuf gesetztz
>> werden kann.

> Warum faselst du dann dauernd von read() herum, wenn setvbuf() doch nur
> *ausschliesslich* auf die funktion von fread() Einfluss hat und direkte
> read() Aufrufe davon voellig unbeeinflusst sind?

Ganz ruhig und obigen Absatz nochmal - verstehend - lesen.
Irgendwie bist Du dazu nämlich nicht in der Lage.

> Btw. verlangt der standard keienswegs, dass fread() mittels read() imple-
> emntiert werden muss.

Auf unixoiden Systemen sit das aber der Fall.

[Juergen Ilse]

Hallo,

In de.comp.os.unix.programming Bonita Montero <Bonita....@gmail.com> wrote:

Die korrekte Formulierung (es war vorher von "Stream" und nicht von
"Datenstrom" die Rede, und nein, im Zusammenhang mit Normen darf man
nicht mal eben nach Gefuehl Fachbegriffe uebersetzen, denn man riskiert
damit den Sinn zu verlfaelschen) ist gerade im Zusammenhang mit Normen
und Sprachstandards Wichtig, auch bei POSIX oder der Sprache C. Wenn du
dank schlampiger Uebersetzung Bloedsinn schreibst, dann wird man dich
korrigieren, also gewoehn dich besser daran. Und deine urspruengliche
Behauptung, setvbuf haette einen Einfluss auf die Systemfunktion read()
ist nach wie vor hahnebuechenr Unfug und keine Wortklauberei.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

In de.comp.os.unix.programming Bonita Montero <Bonita....@gmail.com> wrote:

> Jetzt hör mit den Wortklaubereien auf. Sowohl das was man mit read()
> liest als auch mit fread(), das sind beides Datenströme. Und die nennt
> man im englischen nun mal Streams.

Und noch etwas:

| Du hast mich nicht verstanden. setvbuf() setzt ja eben die
| Buffer-Größe für das dem fread() zugrundeliegende read().

Das ist ein *WOERTLICHES* Zitat von dir, zu finden in *DEINEM* Posting
mit der Msg-ID <q8io9k$nu2$1...@news.albasani.net>. Und in diesem Satz be-
hauptest du *EINDEUTIG*, setvbuf() wuerde die Buffergroesse fuer read()
setzen, und das ist und bleibt der bluehende Bloedsinn.
Gib doch wenigstens zu, wenn du Unfug behauptest hast.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Bonita Montero]

> Die korrekte Formulierung (es war vorher von "Stream" und nicht von
> "Datenstrom" die Rede, und nein, im Zusammenhang mit Normen darf man
> nicht mal eben nach Gefuehl Fachbegriffe uebersetzen, denn man riskiert
> damit den Sinn zu verlfaelschen) ist gerade im Zusammenhang mit Normen
> und Sprachstandards Wichtig, auch bei POSIX oder der Sprache C.

Stream und Datenstrom sind das gleiche. Wennn dir die englische Defini-
tion eher gefällt, dann guck in die englischsprachigen Wikipedia. Da
steht das gleiche.

> ... Und deine urspruengliche Behauptung, setvbuf haette einen Einfluss
> auf die Systemfunktion read() ...

Hab ich nie behauptet.
Ist nur eine Interpretation von dir weil Du nicht lesen kannst.

[Bonita Montero]

> | Du hast mich nicht verstanden. setvbuf() setzt ja eben die
> | Buffer-Größe für das dem fread() zugrundeliegende read().

> Das ist ein *WOERTLICHES* Zitat von dir, zu finden in *DEINEM* Posting
> mit der Msg-ID <q8io9k$nu2$1...@news.albasani.net>. Und in diesem Satz be-
> hauptest du *EINDEUTIG*, setvbuf() wuerde die Buffergroesse fuer read()
> setzen, und das ist und bleibt der bluehende Bloedsinn.
> Gib doch wenigstens zu, wenn du Unfug behauptest hast.

Nein, das behaupte ich mit obigem zitat nicht.
Wenn Du Dummkopf nicht lesen kannst, dann kann ich dafür auch nichts.

[Bonita Montero]

> | Du hast mich nicht verstanden. setvbuf() setzt ja eben die
> | Buffer-Größe für das dem fread() zugrundeliegende read().

> Das ist ein *WOERTLICHES* Zitat von dir, zu finden in *DEINEM* Posting
> mit der Msg-ID <q8io9k$nu2$1...@news.albasani.net>. Und in diesem Satz be-
> hauptest du *EINDEUTIG*, setvbuf() wuerde die Buffergroesse fuer read()
> setzen, und das ist und bleibt der bluehende Bloedsinn.
> Gib doch wenigstens zu, wenn du Unfug behauptest hast.

Nein, das behaupte ich nicht.

[Helmut Schellong]

On 04/12/2019 16:53, Bonita Montero wrote:

> Stream und Datenstrom sind das gleiche. Wennn dir die englische Defini-
> tion eher gefällt, dann guck in die englischsprachigen Wikipedia. Da
> steht das gleiche.

'Stream' und 'Datenstrom' sind _nicht_ das Gleiche.
'Data stream' und 'Datenstrom' sind das Gleiche.

Allgemein sprachlich heißt 'stream': Strom, Fluß, Bach, Strahl, Strömung, ...

Die Bedeutung von 'Stream' im C-Standard
ist im C-Standard definiert.

[Claus Reibenstein]

Bonita Montero schrieb am 12.04.2019 um 12:53:

> Stream = Datenstrom.

Falsch!

Hier geht es um die Sprache C und um nichts Anderes. Die Sprache C
definiert eindeutig, was ein "Stream" ist. Diese Definition - und _nur_
diese - ist hier in dieser Gruppe relevant.

Gruß
Claus

[Claus Reibenstein]

Bonita Montero schrieb am 12.04.2019 um 16:55:

>> | Du hast mich nicht verstanden. setvbuf() setzt ja eben die
>> | Buffer-Größe für das dem fread() zugrundeliegende read().
>>
>> Das ist ein *WOERTLICHES* Zitat von dir, zu finden in *DEINEM* Posting
>> mit der Msg-ID <q8io9k$nu2$1...@news.albasani.net>. Und in diesem Satz be-
>> hauptest du *EINDEUTIG*, setvbuf() wuerde die Buffergroesse fuer read()
>> setzen, und das ist und bleibt der bluehende Bloedsinn.
>> Gib doch wenigstens zu, wenn du Unfug behauptest hast.
>
> Nein, das behaupte ich nicht.

Doch, behauptest Du. Eindeutig.

> Wenn Du Dummkopf nicht lesen kannst, dann kann ich dafür auch nichts.

Aha.

Du behauptest etwas. Andere widerlegen Dich. Du behauptest, das nie
behauptet zu haben. Andere _beweisen_ Dir das Gegenteil. Du behauptest
trotzdem abermals, das nie behauptet zu haben, und beschimpfst die
anderen auch noch.

Deine Sturheit erinnert mich verdächtig an den aktuellen amerikanischen
Präsidenten. Bist Du vielleicht mit dem verwandt?

Warum gibst Du nicht einfach zu, dass Du Dich geirrt hast? Ist das
wirklich so schwer?

Gruß
Claus

[Bonita Montero]

> 'Stream' und 'Datenstrom' sind _nicht_ das Gleiche.
> 'Data stream' und 'Datenstrom' sind das Gleiche.

Doch, ist es. Stream und Datenstrom ist eine Folge von Datensätzen
in zeitlicher Abfolge.

[Bonita Montero]

>> Nein, das behaupte ich nicht.

> Doch, behauptest Du. Eindeutig.

Nein, tu ich nicht.

[Bonita Montero]

>> Stream = Datenstrom.

> Falsch!

Stream und Datenstrom sind die zeitliche Abfolge mehrerer Datensätze.
Das trifft auf beides zu da beides identische Begriffe sind. Wenn Du
zu doof bist, das zu begreifen, dann lies den englischen oder deutschen
WP-Artikel dazu.

[Claus Reibenstein]

Bonita Montero schrieb am 12.04.2019 um 19:17:

>>> Stream = Datenstrom.
>>
>> Falsch!
>
> Stream und Datenstrom sind die zeitliche Abfolge mehrerer Datensätze.

Falsch!

> Das trifft auf beides zu da beides identische Begriffe sind.

Falsch!

> Wenn Du
> zu doof bist, das zu begreifen, dann lies den englischen oder deutschen
> WP-Artikel dazu.

Ich kenne den C-Standard (solltest Du Dir auch mal zu Gemüte führen) und
begreife sehr wohl, was dort drinsteht. Die Meinung irgendwelcher
ominöser Sekundärquellen interessieren mich nicht.

Im Übrigen ist für mich hier EOD. Ich habe keine Lust auf solche
fruchtlosen Diskussionen mit Leuten, die andere für doof halten und
selber zu doof sind, um zu merken, wie doof sie selber sind.

Gruß
Claus

[Thomas Koenig]

Bonita Montero <Bonita....@gmail.com> schrieb:

Erstaunlich, so viele Fehler und Ungenauigkeiten in einem
Satz unterzubringen.

Ein Stream (lt. C-Norm) hat halt eben _keine_ Datensätze. Wenn du
record-orientierte I/O ansehen willst, dann schau dir Fortran an
(oder OS/360 und Nachfolger - FB80 yay!)

Und was ist eine "zeitliche Abfolge" im Bezug auf eine Datei?
Die Daten liegen einfach auf der Platte.

[Bonita Montero]

>>>> Stream = Datenstrom.

>>> Falsch!

>> Stream und Datenstrom sind die zeitliche Abfolge mehrerer Datensätze.

> Falsch!

Nix falsch, das ist so.

> Ich kenne den C-Standard (solltest Du Dir auch mal zu Gemüte führen)

> und begreife sehr wohl, was dort drinsteht. ...

Du kennst aber nicht die allgemeine Terminiologie, die sagt, dass
Stream und Datenstrom das selbe sind und auf beidess zutrifft.

[Bonita Montero]

>> Doch, ist es. Stream und Datenstrom ist eine Folge von Datensätzen
>> in zeitlicher Abfolge.

> Ein Stream (lt. C-Norm) hat halt eben _keine_ Datensätze.

Guck, in die Wikipedia, Du Nase.

> Und was ist eine "zeitliche Abfolge" im Bezug auf eine Datei?
> Die Daten liegen einfach auf der Platte.

Die werden aber in zeitlicher Abfolge gelesen.

[Bonita Montero]

Du kennst den Begriff lediglich aus dem C-Standard und das ist das
was deinen Gewohnheiten entspricht. Alles was über diese Gewohnheiten
bzw. über deinen Horizont hinaus geht darf für dich nicht sein.

[Thomas Koenig]

Bonita Montero <Bonita....@gmail.com> schrieb:

>>> Doch, ist es. Stream und Datenstrom ist eine Folge von Datensätzen
>>> in zeitlicher Abfolge.
>
>> Ein Stream (lt. C-Norm) hat halt eben _keine_ Datensätze.
>
> Guck, in die Wikipedia, Du Nase.

In der Informatik kommt es auf genaue Definitionen an, sonst
liegt man auf selbiger.

Und maßgeblich sind nun mal die entsprechenden Normen, nicht das,
was irgendein Schreiberling auf Wikipedia sich da zurechtgeschrieben
hat oder was du meintest, daraus abzulesen.

>> Und was ist eine "zeitliche Abfolge" im Bezug auf eine Datei?
>> Die Daten liegen einfach auf der Platte.
>
> Die werden aber in zeitlicher Abfolge gelesen.

Oder auch nicht - siehe tac(1) .

[Bonita Montero]

>>> Ein Stream (lt. C-Norm) hat halt eben _keine_ Datensätze.

>> Guck, in die Wikipedia, Du Nase.

> In der Informatik kommt es auf genaue Definitionen an, sonst
> liegt man auf selbiger.

Das in der Wikipedia ist die genaue Definition der Informatik und
nicht die spezielle der C-Sprache.

> Und maßgeblich sind nun mal die entsprechenden Normen, nicht das,
> was irgendein Schreiberling auf Wikipedia sich da zurechtgeschrieben
> hat oder was du meintest, daraus abzulesen.

Ganz schön polemisches Abgetue.

>> Die werden aber in zeitlicher Abfolge gelesen.

> Oder auch nicht - siehe tac(1) .

Dass man Seeken kann um nicht linear zu lesen heißt nicht, dass man es
nicht mit einem Datenstrom zu tun hat.

[Helmut Schellong]

Der C-Standard zu 'Streams' (Auszug):
-------------------------------------
7.21.2 Streams
Input and output, whether to or from physical devices such as terminals
and tape drives, or whether to or from files supported on structured
storage devices, are mapped into logical data streams, whose properties
are more uniform than their various inputs and outputs.
Two forms of mapping are supported, for text streams and for binary
streams.266)

A text stream is an ordered sequence of characters composed into lines,
each line consisting of zero or more characters plus a
terminating new-line character.
Whether the last line requires a terminating new-line character is
implementation-defined.
Characters may have to be added, altered, or deleted on input and output
to conform to differing conventions for representing text in the host
environment.
Thus, there need not be a one-to-one correspondence between the characters
in a stream and those in the external representation.
Data read in from a text stream will necessarily compare equal to the data
that were earlier written out to that stream only if: the data consist
only of printing characters and the control characters horizontal tab
and new-line; no new-line character is immediately preceded by space
characters; and the last character is a new-line character.
Whether space characters that are written out immediately before
a new-line character appear when read in is implementation-defined.

A binary stream is an ordered sequence of characters that can
transparently record internal data.
Data read in from a binary stream shall compare equal to the data that
were earlier written out to that stream, under the same implementation.
Such a stream may, however, hav e an implementation-defined number
of null characters appended to the end of the stream.

266) An implementation need not distinguish between text streams
and binary streams.
In such an implementation, there need be no new-line characters
in a text stream nor any limit to the length of a line.

[Thomas Koenig]

Bonita Montero <Bonita....@gmail.com> schrieb:

>>>> Ein Stream (lt. C-Norm) hat halt eben _keine_ Datensätze.
>
>>> Guck, in die Wikipedia, Du Nase.
>
>> In der Informatik kommt es auf genaue Definitionen an, sonst
>> liegt man auf selbiger.
>
> Das in der Wikipedia ist die genaue Definition der Informatik und
> nicht die spezielle der C-Sprache.

Und hier ist die für C relevant. Die Norm könnte auch, um Hilbert
zu zitieren, "Tisch, Stuhl oder Bierdeidel" verwenden, solange
es eindeutig definiert ist.

Und ja, das unterscheidet sich zwischen verschiedenen
Programmiersprachen. Man vergleiche z.B. die unterschiedliche
Bedeutung von "fuction" in C und Fortran.

>> Und maßgeblich sind nun mal die entsprechenden Normen, nicht das,
>> was irgendein Schreiberling auf Wikipedia sich da zurechtgeschrieben
>> hat oder was du meintest, daraus abzulesen.
>
> Ganz schön polemisches Abgetue.

Entspricht nun mal den Tatsachen.

>>> Die werden aber in zeitlicher Abfolge gelesen.
>
>> Oder auch nicht - siehe tac(1) .
>
> Dass man Seeken kann um nicht linear zu lesen heißt nicht, dass man es
> nicht mit einem Datenstrom zu tun hat.

Das "zeitlich" macht einfach keinen Sinn.

[Bonita Montero]

>> Du kennst den Begriff lediglich aus dem C-Standard und das ist das
>> was deinen Gewohnheiten entspricht. Alles was über diese Gewohnheiten
>> bzw. über deinen Horizont hinaus geht darf für dich nicht sein.

> Der C-Standard zu 'Streams' (Auszug):
> -------------------------------------

> ...

Eben, und das ist nur der C-Standard und nicht die allgemeine Definition
des Begriffes Stream.

[Bonita Montero]

>> Das in der Wikipedia ist die genaue Definition der Informatik und
>> nicht die spezielle der C-Sprache.

> Und hier ist die für C relevant. Die Norm könnte auch, um Hilbert
> zu zitieren, "Tisch, Stuhl oder Bierdeidel" verwenden, solange
> es eindeutig definiert ist.
>
> Und ja, das unterscheidet sich zwischen verschiedenen
> Programmiersprachen. Man vergleiche z.B. die unterschiedliche
> Bedeutung von "fuction" in C und Fortran.

Es wurde aber gesagt, dass das was man mit den POSIX-Funktion read()
liest kein Stream ist. Und da darf man ja wohl mal auf die allgemeine
Definition kommen.

>> Ganz schön polemisches Abgetue.

> Entspricht nun mal den Tatsachen.

Ja, reduzierte Tatsachen.

>>>> Die werden aber in zeitlicher Abfolge gelesen.

>>> Oder auch nicht - siehe tac(1) .

>> Dass man Seeken kann um nicht linear zu lesen heißt nicht, dass man es
>> nicht mit einem Datenstrom zu tun hat.

> Das "zeitlich" macht einfach keinen Sinn.

Doch, macht es, denn das Programm macht keine Bearbeitung auf einen
Schlag.

[Helmut Schellong]

Die allgemeine Definition spielt hier keine Rolle.
Hier zählt nur die Definition des C-Standards, im Zusammenhang
mit den STREAM-Funktionen des C-Standards.
Das ist das bonita-Problem in diesem Thread.

[Helmut Schellong]

On 04/13/2019 17:14, Bonita Montero wrote:
>>> Das in der Wikipedia ist die genaue Definition der Informatik und
>>> nicht die spezielle der C-Sprache.
>
>> Und hier ist die für C relevant.  Die Norm könnte auch, um Hilbert
>> zu zitieren, "Tisch, Stuhl oder Bierdeidel" verwenden, solange
>> es eindeutig definiert ist.
>>
>> Und ja, das unterscheidet sich zwischen verschiedenen
>> Programmiersprachen.  Man vergleiche z.B. die unterschiedliche
>> Bedeutung von "fuction" in C und Fortran.
>
> Es wurde aber gesagt, dass das was man mit den POSIX-Funktion read()
> liest kein Stream ist. Und da darf man ja wohl mal auf die allgemeine
> Definition kommen.

Beide Funktions-Familien lesen/verarbeiten Bytes.
Auch für open() gibt es Text- und Binär-Modus: O_TEXT|O_BINARY

Der Unterschied ist, daß der C-Standard das Wort 'Streams'
benutzt und zuordnet, was er nicht gemußt hätte.
Man könnte im C-Standard auf die Benutzung des Wortes 'Streams'
(ersatzlos) verzichten, und trotzdem bliebe alles semantisch
so, wie es ist.
Warum?
Weil 'Streams' nur ein Wort ist, das durch vielerlei Formulierungen
ersetzt werden könnte.

[Bonita Montero]

>> Es wurde aber gesagt, dass das was man mit den POSIX-Funktion read()
>> liest kein Stream ist. Und da darf man ja wohl mal auf die allgemeine
>> Definition kommen.

> Beide Funktions-Familien lesen/verarbeiten Bytes.
> Auch für open() gibt es Text- und Binär-Modus: O_TEXT|O_BINARY

Jetzt schwafel nicht rum. Lies die Wikipedia. Beides sind im Sinne der
Informatik Streams, nur das eine eben kein C-Stream.

[Bonita Montero]

>> Eben, und das ist nur der C-Standard und nicht die allgemeine Definition
>> des Begriffes Stream.

> Die allgemeine Definition spielt hier keine Rolle.

Doch, spielt hier, denn es wurden auch die POSIX-APIs ins Spiel
gebracht.

[Helmut Schellong]

open() und read() haben mit dieser Definition in Wikipedia
nichts zu tun.
Laut POSIX liest read() nbyte Bytes.
Von Stream ist da keine Rede.

[Bonita Montero]

>> Jetzt schwafel nicht rum. Lies die Wikipedia. Beides sind im Sinne
>> der Informatik Streams, nur das eine eben kein C-Stream.

> open() und read() haben mit dieser Definition in Wikipedia
> nichts zu tun.

Doch, lies die Definition in der englischsprachigen Wikipdia.

> Laut POSIX liest read() nbyte Bytes.
> Von Stream ist da keine Rede.

Muss auch nicht.

[Helmut Schellong]

On 04/13/2019 19:21, Bonita Montero wrote:

POSIX definiert, daß nbyte bytes von read() gelesen werden.
Von Stream ist dort keine Rede.

[Helmut Schellong]

On 04/13/2019 20:21, Bonita Montero wrote:
>>> Jetzt schwafel nicht rum. Lies die Wikipedia. Beides sind im Sinne
>>> der Informatik Streams, nur das eine eben kein C-Stream.
>
>> open() und read() haben mit dieser Definition in Wikipedia
>> nichts zu tun.
>
> Doch, lies die Definition in der englischsprachigen Wikipdia.

Nein, weil es sinnlos ist.
Diese Definitionen in Wikipedia sind hier irrelevant.
Mit diesen Definitionen kann ich nichts tun - Zeitverschwendung!

[Bonita Montero]

>> Doch, spielt hier, denn es wurden auch die POSIX-APIs ins Spiel
>> gebracht.

> POSIX definiert, daß nbyte bytes von read() gelesen werden.
> Von Stream ist dort keine Rede.

Im Sinne der Informatik ist es aber dennoch ein Stream, aber nur eben
ein C-Stream. Wenn das in dein beschränktes Weltbild nicht reinpasst,

dann kann ich dafür auch nichts.

Du urteilst nach deinen Gewohnheiten und alles was dem nicht entpsicht

darf für dich nicht sein.

Außerdem muss read() nicht nbytes lesen, es kann auch weniger abliefern.

[Bonita Montero]

>>> open() und read() haben mit dieser Definition in Wikipedia
>>> nichts zu tun.

>> Doch, lies die Definition in der englischsprachigen Wikipdia.

> Nein, weil es sinnlos ist.
> Diese Definitionen in Wikipedia sind hier irrelevant.

Ne, sind die nicht. Wenn die Diskussion ist, ob eine Datei die ich
mit read() lese auch ein Stream ist, dann ist der Einwand im Sinne
der Informatik einfach erlaubt, denn in dem Sinne ist es einfach
ein Stream.

> Mit diesen Definitionen kann ich nichts tun - Zeitverschwendung!

Natülrich kann man mit unserer Diskussion hier nichts tun. Das kann
ich aber mit der Aussage, dass nur ein C-Stream ein Stream wäre auch
nicht.

[Helmut Schellong]

On 04/13/2019 20:27, Bonita Montero wrote:
>>> Doch, spielt hier, denn es wurden auch die POSIX-APIs ins Spiel
>>> gebracht.
>
>> POSIX definiert, daß nbyte bytes von read() gelesen werden.
>> Von Stream ist dort keine Rede.
>
> Im Sinne der Informatik ist es aber dennoch ein Stream, aber nur eben
> ein C-Stream. Wenn das in dein beschränktes Weltbild nicht reinpasst,
> dann kann ich dafür auch nichts.

Wer hier von 'Stream' schreibt, jedoch nicht die 'Streams' aus dem
C-Standard meint, stiftet Verwirrung, denn hier nimmt jeder an,
daß die 'Streams' aus dem C-Standard gemeint sind.

[Helmut Schellong]

On 04/13/2019 20:31, Bonita Montero wrote:
>>>> open() und read() haben mit dieser Definition in Wikipedia
>>>> nichts zu tun.
>
>>> Doch, lies die Definition in der englischsprachigen Wikipdia.
>
>> Nein, weil es sinnlos ist.
>> Diese Definitionen in Wikipedia sind hier irrelevant.
>
> Ne, sind die nicht. Wenn die Diskussion ist, ob eine Datei die ich
> mit read() lese auch ein Stream ist, dann ist der Einwand im Sinne
> der Informatik einfach erlaubt, denn in dem Sinne ist es einfach
> ein Stream.

Eine Datei ist kein Stream, auch kein Data stream, sondern
eine Ansammlung von Bytes, die durch Seeken in beliebiger
Reihenfolge und beliebiger jeweiliger Menge gelesen werden können.

Die Funktionen, die lesen oder schreiben, lesen oder schreiben
einen Datenstrom in oder aus ihren Puffern, oder eine Byte-Folge
oder eine Zeichenfolge.

>> Mit diesen Definitionen kann ich nichts tun - Zeitverschwendung!
>
> Natülrich kann man mit unserer Diskussion hier nichts tun. Das kann
> ich aber mit der Aussage, dass nur ein C-Stream ein Stream wäre auch
> nicht.

Niemand hat behauptet, daß nur ein Stream im Sinne des C-Standards
ein Stream sei.
Ich schrieb bereits, daß Stream bedeutet: Strom, Fluß, Bach, Strömung,

[Bonita Montero]

>> Ne, sind die nicht. Wenn die Diskussion ist, ob eine Datei die ich
>> mit read() lese auch ein Stream ist, dann ist der Einwand im Sinne
>> der Informatik einfach erlaubt, denn in dem Sinne ist es einfach
>> ein Stream.

> Eine Datei ist kein Stream, ...

Ich schrob: "eine Datei die dih mit read() lese". Und aus
informationstechnnischer Sicht ist das auch ein Stream.

> Niemand hat behauptet, daß nur ein Stream im Sinne des C-Standards
> ein Stream sei.

Doch, mehrere hier.

[Bonita Montero]

>> Im Sinne der Informatik ist es aber dennoch ein Stream, aber nur eben
>> ein C-Stream. Wenn das in dein beschränktes Weltbild nicht reinpasst,
>> dann kann ich dafür auch nichts.

> Wer hier von 'Stream' schreibt, jedoch nicht die 'Streams' aus dem
> C-Standard meint, stiftet Verwirrung, denn hier nimmt jeder an,
> daß die 'Streams' aus dem C-Standard gemeint sind.

Nö.

[Bonita Montero]

Ach, noch ein schönes Beispiel für die mehrfache Bedeutung des Wortes
"Stream": bei den Berkeley-Sockets gibt es es verschiedene typen von
Sockets, SOCK_STREAM, SOCK_DGRAM und SOCK_SEQPACKET. Im Sinne der
Sockets ist nur SOCK_STREAM ein Stream. Aber im Sinne der Informatik
sind alle drei Typen Streams weil es sich hier jeweils um zeitliche
Abfolgen von Datensätzen handelt die man damit lesen und schreiben
kann.

[Thomas Koenig]

Bonita Montero <Bonita....@gmail.com> schrieb:

s/stiftet Verwirrung/ist verwirrt/

[Bonita Montero]

Nö, ich hab mich ganz klar ausgedrückt.
Nur ist das für andere aversiv weil die ein festes, widerspruchsfreies
Weltbild haben wollen. Wenn es für den selben Begriff mehrere (in dem
Fall sehr ähnliche) Definitionen gibt, dann können die das nicht tole-
rieren.

[Juergen Ilse]

Hallo,

In de.comp.os.unix.programming Bonita Montero <Bonita....@gmail.com> wrote:
>>> Das in der Wikipedia ist die genaue Definition der Informatik und
>>> nicht die spezielle der C-Sprache.
>> Und hier ist die für C relevant. Die Norm könnte auch, um Hilbert
>> zu zitieren, "Tisch, Stuhl oder Bierdeidel" verwenden, solange
>> es eindeutig definiert ist.
>> Und ja, das unterscheidet sich zwischen verschiedenen
>> Programmiersprachen. Man vergleiche z.B. die unterschiedliche
>> Bedeutung von "fuction" in C und Fortran.
> Es wurde aber gesagt, dass das was man mit den POSIX-Funktion read()
> liest kein Stream ist. Und da darf man ja wohl mal auf die allgemeine
> Definition kommen.

Wenn im Zusammenhang mit der Sprache C von "stream" die Rede ist, dann
ist exakt das gemeint, was die C-Norm als "stream" definiert, und das
womit man es bei read() zu tun hat, entspricht nicht dieser Definition,
also ist es (im Zusammenhang mit der Sprache C) eben *kein* stream.
Da kannst du noch so viel mit irgendwelchen Quellen abseits der Sprache
C wedeln, das aendert daran schlicht ueberhaupt nichts. Wenn du hier
ueber etwas im Kontext mit C diskutieren willst, halte dich an das ent-
sprechende Vokabuular oder halte die Schnauze.

>>>>> Die werden aber in zeitlicher Abfolge gelesen.
>>>> Oder auch nicht - siehe tac(1) .
>>> Dass man Seeken kann um nicht linear zu lesen heißt nicht, dass man es
>>> nicht mit einem Datenstrom zu tun hat.
>> Das "zeitlich" macht einfach keinen Sinn.
> Doch,

Nein, und das wird auch durch Wiederholung nicht richtiger.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Bonita Montero]

>> Es wurde aber gesagt, dass das was man mit den POSIX-Funktion read()
>> liest kein Stream ist. Und da darf man ja wohl mal auf die allgemeine

>

> Wenn im Zusammenhang mit der Sprache C von "stream" die Rede ist, dann

> ist exakt das gemeint, was die C-Norm als "stream" definiert, ...

Darum gings hier aber nicht nur allein.

> und das womit man es bei read() zu tun hat, entspricht nicht dieser
> Definition, also ist es (im Zusammenhang mit der Sprache C) eben *kein*
> stream.

Kein C-Stream, aber ein Stream.

> Da kannst du noch so viel mit irgendwelchen Quellen abseits der Sprache C wedeln, das aendert daran schlicht ueberhaupt nichts. Wenn du hier
> ueber etwas im Kontext mit C diskutieren willst, halte dich an das ent-
> sprechende Vokabuular oder halte die Schnauze.

Du willst mir meinen Mund verbieten weil dir meine Feststellung nicht
gefällt weil es in deinem starren Weltbild keine Unschärfen bzgl.
solcher Definitionen geben darf.

> Nein, und das wird auch durch Wiederholung nicht richtiger.

Doch, das gilt selbst für die C-Streams und entspricht auch dem was
in der englischsprachigen Wikipedia steht.

Du bist wirklich ein unglaublich dummer Mensch!

[Juergen Ilse]

Hallo,

In de.comp.os.unix.programming Bonita Montero <Bonita....@gmail.com> wrote:

Auch im POSIX standrd wird der Begriff stream definiert, und auch dort
arbeiten read() und write() nicht auf streaams, sondern auf file handles.
Im Zusammenahng mit POSIX wird die POSIX Definition verwendet, im Zu
sammenhang mit C die Definition der C-Norm. Beide sind weitgehend aus-
tauschbar (was wenig verwunderlich ist, da beide Standards die selben
Wurzeln haben). Deine "allgemeine Definition" unterscheidet sich da er-
heblich und hat weder im Zusammenhang mit POSIX noch im Zusammenhang mit
C irgend eine Relevanz. Ja, das ist so, egal wie oft du anderes behauptest.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Bonita Montero]

>>>> Eben, und das ist nur der C-Standard und nicht die allgemeine Definition
>>>> des Begriffes Stream.

>>> Die allgemeine Definition spielt hier keine Rolle.
>> Doch, spielt hier, denn es wurden auch die POSIX-APIs ins Spiel
>> gebracht.

> Auch im POSIX standrd wird der Begriff stream definiert, und auch dort
> arbeiten read() und write() nicht auf streaams, sondern auf file handles.

Sag mal, diskutier ich hier mit Detlef Bosau oder was? Ähnlich dumm
kommen mit deine Kommentare vor.
Nochmal: was ein Stream ist je nach Wahl der Terminologie unterschied-
lich definiert. Aus sicht der Informatik ist ein Stream eben eine zeit-
liche Abfolge von Datensätzen. Und mit der Terminologie ist alles was
Du mit read() liest ein Stream.

[Thomas Koenig]

Bonita Montero <Bonita....@gmail.com> schrieb:

>>>>> Eben, und das ist nur der C-Standard und nicht die allgemeine Definition
>>>>> des Begriffes Stream.
>
>>>> Die allgemeine Definition spielt hier keine Rolle.
>>> Doch, spielt hier, denn es wurden auch die POSIX-APIs ins Spiel
>>> gebracht.
>
>> Auch im POSIX standrd wird der Begriff stream definiert, und auch dort
>> arbeiten read() und write() nicht auf streaams, sondern auf file handles.

> Sag mal, diskutier ich hier mit Detlef Bosau oder was? Ähnlich dumm
> kommen mit deine Kommentare vor.

Ein Geisterfahrer? Hunderte!

[Juergen Ilse]

Hallo,

In de.comp.os.unix.programming Bonita Montero <Bonita....@gmail.com> wrote:

> Nochmal: was ein Stream ist je nach Wahl der Terminologie unterschied-
> lich definiert.

Stimmt, und in de.comp.lang.c ist die Definition im Rahmen der Sprache C
relevent, in der Gruppe de.comp.os.unix.programming die Definition im Zu-
sammenhang mit POSIX. Beide stimmen weitgehend ueberein. Die von dir postu-
lierte Definition ist eine andere, die mit keiner der beiden genannten ueber-
einstimmt, also in keiner der beiden Gruppen in die du gepostet hast relevant
ist. Hast du merkbefreiter Troll das nun endlich begriffen?

> Aus sicht der Informatik ist ein Stream eben eine zeitliche Abfolge von
> Datensätzen.

Das wird durch Wiederholung nicht richtiger. "geordnet" wuerde zutreffen,
"zeitliche Abfolge" ist aber so ziemlich *immer* Unsinn. Wenn in der Wiki-
pedia etwas von "zeitlicher Abfolge" steht, sollte das mal jemand mit Ahnung
korrigieren ...

> Und mit der Terminologie ist alles was Du mit read() liest ein Stream.

read() und write() arbeiten mit filehandles, nicht mit C-Streams, setvbuf()
hat nur bei C-streams Auswrkungen, nicht aber bei read() und write(). Ja, das
ist so, egal wie sehr du d ich um diese Erkenntnis herumwinden willst.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

In de.comp.os.unix.programming Thomas Koenig <tko...@netcologne.de> wrote:
> Bonita Montero <Bonita....@gmail.com> schrieb:
>> [...]
> Ein Geisterfahrer? Hunderte!

Ich wuerde eher sagen "tausende" (Obelix haette wohl eher gesagt "Dutzende",
siehe der Aserixband "die goldene Sichel").

Tschuess,
Juergen Ilse (juergenqusenet-verwaltung.de)

[Bonita Montero]

> Stimmt, und in de.comp.lang.c ist die Definition im Rahmen der Sprache C
> relevent, in der Gruppe de.comp.os.unix.programming die Definition im Zu-
> sammenhang mit POSIX. Beide stimmen weitgehend ueberein. Die von dir postu-
> lierte Definition ist eine andere, die mit keiner der beiden genannten ueber-
> einstimmt, also in keiner der beiden Gruppen in die du gepostet hast relevant
> ist. Hast du merkbefreiter Troll das nun endlich begriffen?

Du willst hier mit irgendwelchen Vorwänden mir Regeln setzen damit
deine Anichten eben maßgblich sein sollen und deine Ansichten mir
das Wort verbieten sollen.

>> Aus sicht der Informatik ist ein Stream eben eine zeitliche Abfolge von
>> Datensätzen.

> Das wird durch Wiederholung nicht richtiger. "geordnet" wuerde zutreffen,

Nur weil Du so beschränkt bist muss das nicht alles nach deinem Denken
zurechtdefiniert sein.

> "zeitliche Abfolge" ist aber so ziemlich *immer* Unsinn.

Nein ist's nicht.
Beim Lesen und Schreiben gibt's immer eine zeitliche Abfolge.

> Wenn in der Wiki- pedia etwas von "zeitlicher Abfolge" steht, sollte das
> mal jemand mit Ahnung korrigieren ...

Du hast auf jeden Fall keine an der Stelle.

>> Und mit der Terminologie ist alles was Du mit read() liest ein Stream.

> read() und write() arbeiten mit filehandles, nicht mit C-Streams, ...

> setvbuf() hat nur bei C-streams Auswrkungen, nicht aber bei read() und write().

Hab ich auch gar nichts Gegenteilighes gesagt. Sondern nur, dass
setvbuf() die Größe eines Puffers gesetzt wird der unter unixoiden
Systemen dann mit read() befüllt wird.

[Juergen Ilse]

Hallo,

In de.comp.os.unix.programming Bonita Montero <Bonita....@gmail.com> wrote:

>> Stimmt, und in de.comp.lang.c ist die Definition im Rahmen der Sprache C
>> relevent, in der Gruppe de.comp.os.unix.programming die Definition im Zu-
>> sammenhang mit POSIX. Beide stimmen weitgehend ueberein. Die von dir postu-
>> lierte Definition ist eine andere, die mit keiner der beiden genannten ueber-
>> einstimmt, also in keiner der beiden Gruppen in die du gepostet hast relevant
>> ist. Hast du merkbefreiter Troll das nun endlich begriffen?
> Du willst hier mit irgendwelchen Vorwänden mir Regeln setzen damit
> deine Anichten eben maßgblich sein sollen und deine Ansichten mir
> das Wort verbieten sollen.
>>> Aus sicht der Informatik ist ein Stream eben eine zeitliche Abfolge von
>>> Datensätzen.
>> Das wird durch Wiederholung nicht richtiger. "geordnet" wuerde zutreffen,
> Nur weil Du so beschränkt bist muss das nicht alles nach deinem Denken
> zurechtdefiniert sein.

Zumindest bei "seekbaren" Dateien kann wahlfrei an beliebige Stellen
geschrieben und von beliebigen stellen gelesen werden, da ist dann
"geordneter Satz von Daten" noch akzeptabel, aber "zeitliche Abfolge"
ist kompletter Nonsens.

>> "zeitliche Abfolge" ist aber so ziemlich *immer* Unsinn.
> Nein ist's nicht.

Doch.

> Beim Lesen und Schreiben gibt's immer eine zeitliche Abfolge.

... die aber (zumindest bei "seekable files") nicht unbedingt mit der
Reihenfolge der Daten ion der Datei uebereinstimmen muss ...

>>> Und mit der Terminologie ist alles was Du mit read() liest ein Stream.
>> read() und write() arbeiten mit filehandles, nicht mit C-Streams, ...
>> setvbuf() hat nur bei C-streams Auswrkungen, nicht aber bei read() und write().
> Hab ich auch gar nichts Gegenteilighes gesagt.

Ich habe dir sogar die stelle zitiert, wo du das geschrieben hast.
Und anscheinend hat das so ziemlich *jeder* in dieser Gruppe genauso
verstanden wie ich, auch wenn du jetzt behauptest, wir haetten das
ja alles nur flacsh verstanden ... Wenn du wenigstens zugeben wuerdest,
dass du einmal Unfug geschrieben hast ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Bonita Montero]

> Zumindest bei "seekbaren" Dateien kann wahlfrei an beliebige Stellen
> geschrieben und von beliebigen stellen gelesen werden, da ist dann
> "geordneter Satz von Daten" noch akzeptabel, aber "zeitliche Abfolge"
> ist kompletter Nonsens.

Zwischen den Seeks hast Du dann aber Datenströme.
Und: demnach wäre ja auch ein C-Stream kein Stream.

>> Beim Lesen und Schreiben gibt's immer eine zeitliche Abfolge.

> Ich habe dir sogar die stelle zitiert, wo du das geschrieben hast.
> Und anscheinend hat das so ziemlich *jeder* in dieser Gruppe genauso
> verstanden wie ich, auch wenn du jetzt behauptest, wir haetten das
> ja alles nur flacsh verstanden ... Wenn du wenigstens zugeben wuerdest,
> dass du einmal Unfug geschrieben hast ...

Tja, Sprache ist halt nicht so oberflächlich logisch wie Du dir das
denkst.