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

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

2019-04-05 17:44:48 UTC

Post by Helmut Waitzmann
[...]
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.

Rainer Weikusat

2019-04-08 16:55:38 UTC

Post by Michael BÃ¤uerle

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.

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

Helmut Schellong

2019-04-05 18:01:19 UTC

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.

POSIX The Open Group Base Specifications Issue 7, 2018 edition
SYNOPSIS
#include <unistd.h>
[…]
ssize_t read(int fildes, void *buf, size_t nbyte);
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.

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.

Post by Helmut Waitzmann
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 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.

Post by Helmut Waitzmann
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.

Post by Helmut Waitzmann
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 ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm

Helmut Waitzmann

2019-04-08 07:05:35 UTC

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.

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.

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.

Post by Helmut Waitzmann
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«.)

Post by Helmut Schellong
|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.

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

2019-04-08 11:03:07 UTC

[... ...]

Post by Helmut Waitzmann
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.
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.

[...]

Post by Helmut Waitzmann
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

[...]

Post by Helmut Schellong
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.

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

Stefan Reuther

2019-04-08 16:24:55 UTC

Post by Helmut Waitzmann
If count is greater than SSIZE_MAX, the result is
unspecified.
Auf gut Deutsch: »Wir wollen oder können nicht sagen, was dann
geschieht«.)

[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).

Post by Helmut Schellong
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

Michael Bäuerle

2019-04-08 11:17:02 UTC

Post by Helmut Waitzmann
[...]
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.
^^^^^^^ ^^^^^^

Bonita Montero

2019-04-09 13:19:11 UTC

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

2019-04-09 13:37:33 UTC

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

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.

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

Bonita Montero

2019-04-09 15:49:34 UTC

Post by 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.

Post by Helmut Schellong
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

2019-04-09 17:46:51 UTC

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

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.

Post by Helmut Schellong
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.

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

Bonita Montero

2019-04-09 18:29:07 UTC

Post by Helmut Schellong
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.

Post by Helmut Schellong
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().

Post by Helmut Schellong
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.

Post by Helmut Schellong
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.

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

Ist meistens nicht realistisch.

Post by Helmut Schellong
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

2019-04-09 19:08:20 UTC

Post by Helmut Schellong
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.

Post by Helmut Schellong
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(.....)".

Post by Helmut Schellong
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.

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

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.

Post by Helmut Schellong
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.

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.

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

Bonita Montero

2019-04-09 19:14:09 UTC

Post by 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.

Post by Helmut Schellong
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.

Post by Bonita Montero
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.

Post by Bonita Montero
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.

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

Post by Bonita Montero
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

2019-04-09 20:07:32 UTC

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

Post by Helmut Schellong
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!

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

Bonita Montero

2019-04-09 20:31:22 UTC

Post by 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.

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

2019-04-09 20:36:02 UTC

Post by Helmut Schellong
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

2019-04-10 09:32:51 UTC

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

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.

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

Bonita Montero

2019-04-10 10:56:24 UTC

Post by 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

2019-04-10 11:09:54 UTC

Post by Helmut Schellong
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

2019-04-10 12:38:00 UTC

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

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.

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

Bonita Montero

2019-04-10 13:41:11 UTC

Post by 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.
...
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

2019-04-10 14:56:39 UTC

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.

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

Rainer Weikusat

2019-04-10 16:01:15 UTC

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.

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

2019-04-10 16:30:59 UTC

Post by Rainer Weikusat
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.

Helmut Schellong

2019-04-10 18:42:57 UTC

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.

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

Bonita Montero

2019-04-10 18:49:38 UTC

Post by 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

2019-04-10 19:57:57 UTC

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

2019-04-10 20:01:07 UTC

Post by Rainer Weikusat

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" ...).

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

Helmut Schellong

2019-04-11 13:49:09 UTC

Post by Rainer Weikusat

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.

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 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...

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

Bonita Montero

2019-04-09 19:08:31 UTC

Post by Helmut Schellong
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.

Helmut Schellong

2019-04-09 19:41:19 UTC

Post by Helmut Schellong
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.

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.

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

Bonita Montero

2019-04-09 19:51:42 UTC

Post by 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.

Claus Reibenstein

2019-04-10 17:46:12 UTC

Post by Helmut Schellong
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.

Post by 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.

Gruß
Claus

Bonita Montero

2019-04-10 18:11:45 UTC

Post by 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.

Juergen Ilse

2019-04-12 08:27:28 UTC

Hallo,

Post by 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.

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 (***@usenet-verwaltung.de)

Bonita Montero

2019-04-12 09:09:04 UTC

Post by Juergen Ilse
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.

Claus Reibenstein

2019-04-12 11:34:01 UTC

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.

Du konstruierst da etwas, was gar nicht existiert.

Gruß
Claus

Bonita Montero

2019-04-12 12:18:38 UTC

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

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

Juergen Ilse

2019-04-12 13:49:29 UTC

Hallo,

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

Doch, auf einem Unix-System nutzt fread() read().

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.

Post by Bonita Montero
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 (***@usenet-verwaltung.de)

Bonita Montero

2019-04-12 13:51:43 UTC

Post by Juergen Ilse
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!

Post by Bonita Montero
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

Post by Juergen Ilse
mit read() nichts zu tun. Lies endlich mal die Dokumentation statt wild
herumzuspekulieren.
Tschuess,

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

Juergen Ilse

2019-04-12 14:37:50 UTC

Hallo,

Post by 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?
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 (***@usenet-verwaltung.de)

Bonita Montero

2019-04-12 14:44:28 UTC

Post by 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.

Post by Juergen Ilse
Btw. verlangt der standard keienswegs, dass fread() mittels read() imple-
emntiert werden muss.

Auf unixoiden Systemen sit das aber der Fall.

Bonita Montero

2019-04-10 18:28:47 UTC

Post by Claus Reibenstein
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.

Juergen Ilse

2019-04-12 08:34:47 UTC

Hallo,

Post by Claus Reibenstein
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.

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 (***@usenet-verwaltung.de)

Bonita Montero

2019-04-12 09:09:52 UTC

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

Juergen Ilse

2019-04-12 09:35:41 UTC

Hallo,

Post by Bonita Montero
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 (***@usenet-verwaltung.de)

Bonita Montero

2019-04-12 10:53:05 UTC

Stream = Datenstrom.

Juergen Ilse

2019-04-12 13:51:30 UTC

Post by 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!

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

Bonita Montero

2019-04-12 14:03:37 UTC

Post by 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

2019-04-12 14:45:30 UTC

Hallo,

Post by 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.

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 (***@usenet-verwaltung.de)

Bonita Montero

2019-04-12 14:53:21 UTC

Post by Juergen Ilse
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.

Post by Juergen Ilse
... 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.

Helmut Schellong

2019-04-12 15:38:16 UTC

Post by Bonita Montero
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.

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

Bonita Montero

2019-04-12 17:15:46 UTC

Post by Helmut Schellong
'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.

Thomas Koenig

2019-04-12 19:43:28 UTC

Post by Helmut Schellong
'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.

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

2019-04-13 08:08:10 UTC

Post by 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.

Post by Thomas Koenig
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.

Thomas Koenig

2019-04-13 10:48:58 UTC

Post by 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.

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.

Post by Thomas Koenig
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

2019-04-13 10:58:07 UTC

Post by Thomas Koenig
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.

Post by Thomas Koenig
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.

Post by Bonita Montero
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.

Thomas Koenig

2019-04-13 13:44:51 UTC

Post by Thomas Koenig
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.

Ganz schön polemisches Abgetue.

Entspricht nun mal den Tatsachen.

Post by Bonita Montero
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

2019-04-13 15:14:01 UTC

Post by 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.

Post by Bonita Montero
Ganz schön polemisches Abgetue.

Entspricht nun mal den Tatsachen.

Ja, reduzierte Tatsachen.

Post by Bonita Montero
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

2019-04-13 17:17:14 UTC

Post by 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.

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.

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

Bonita Montero

2019-04-13 17:21:08 UTC

Post by 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.

Helmut Schellong

2019-04-13 18:20:06 UTC

Post by 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.

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

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

Bonita Montero

2019-04-13 18:21:31 UTC

Post by 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.

Post by Helmut Schellong
Laut POSIX liest read() nbyte Bytes.
Von Stream ist da keine Rede.

Muss auch nicht.

Helmut Schellong

2019-04-13 18:25:33 UTC

Post by 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.

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

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

Bonita Montero

2019-04-13 18:31:35 UTC

Post by Helmut Schellong
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.

Post by Helmut Schellong
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

2019-04-13 23:01:38 UTC

Post by Helmut Schellong
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.

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.

Post by Helmut Schellong
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,

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

Bonita Montero

2019-04-14 07:41:43 UTC

Post by 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

2019-04-14 09:10:39 UTC

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.

Juergen Ilse

2019-04-14 17:54:01 UTC

Hallo,

Post by 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.

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.

Post by Bonita Montero
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 (***@usenet-verwaltung.de)

Bonita Montero

2019-04-14 17:57:32 UTC

Post by 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.

Post by Juergen Ilse
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.

Post by Juergen Ilse
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.

Post by Juergen Ilse
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

2019-04-12 14:52:35 UTC

Hallo,

Post by Bonita Montero
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$***@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 (***@usenet-verwaltung.de)

Bonita Montero

2019-04-12 14:54:15 UTC

Post by Juergen Ilse
| 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
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

2019-04-12 14:55:20 UTC

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

Claus Reibenstein

2019-04-12 16:15:33 UTC

Nein, das behaupte ich nicht.

Doch, behauptest Du. Eindeutig.

Post by Bonita Montero
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

2019-04-12 17:16:17 UTC

Post by Bonita Montero
Nein, das behaupte ich nicht.

Doch, behauptest Du. Eindeutig.

Nein, tu ich nicht.

Claus Reibenstein

2019-04-12 16:06:08 UTC

Post by Bonita Montero
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

Bonita Montero

2019-04-12 17:17:19 UTC

Post by 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

2019-04-12 19:28:28 UTC

Post by Bonita Montero
Stream = Datenstrom.

Falsch!

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

Falsch!

Post by Bonita Montero
Das trifft auf beides zu da beides identische Begriffe sind.

Falsch!

Post by Bonita Montero
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

Bonita Montero

2019-04-13 08:07:11 UTC

Post by Bonita Montero
Stream = Datenstrom.

Falsch!

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

Falsch!

Nix falsch, das ist so.

Post by Claus Reibenstein
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

2019-04-13 08:40:27 UTC

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.

Helmut Schellong

2019-04-13 12:43:33 UTC

Post by 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):
-------------------------------------
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.

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

Bonita Montero

2019-04-13 15:12:04 UTC

-------------------------------------
...

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

Helmut Schellong

2019-04-13 17:04:38 UTC

-------------------------------------
...

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

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.

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

Bonita Montero

2019-04-13 17:21:57 UTC

Post by 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

2019-04-13 18:22:20 UTC

Post by 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.

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

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

Bonita Montero

2019-04-13 18:27:27 UTC

Post by 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.

Helmut Schellong

2019-04-13 22:45:30 UTC

Post by 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.

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.

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

Bonita Montero

2019-04-14 08:54:32 UTC

Post by 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ö.

Thomas Koenig

2019-04-14 11:04:44 UTC

Post by 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ö.

s/stiftet Verwirrung/ist verwirrt/

Bonita Montero

2019-04-14 11:44:29 UTC

Post by 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ö.

s/stiftet Verwirrung/ist verwirrt/

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

2019-04-14 18:08:51 UTC

Hallo,

Post by 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.
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 (***@usenet-verwaltung.de)

Bonita Montero

2019-04-14 18:17:36 UTC

Post by 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

2019-04-14 18:51:00 UTC

Post by 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.

Ein Geisterfahrer? Hunderte!

Juergen Ilse

2019-04-14 21:41:45 UTC

Hallo,

[...]

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)

Juergen Ilse

2019-04-14 21:38:14 UTC

Hallo,

Post by Bonita Montero
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?

Post by Bonita Montero
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 ...

Post by Bonita Montero
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 (***@usenet-verwaltung.de)

Bonita Montero

2019-04-15 06:27:38 UTC

Post by Juergen Ilse
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.

Post by Bonita Montero
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.

Post by Juergen Ilse
"zeitliche Abfolge" ist aber so ziemlich *immer* Unsinn.

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

Post by Juergen Ilse
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.

Post by Bonita Montero
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

2019-04-15 08:10:23 UTC

Hallo,

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.

Post by Bonita Montero
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.

Post by Juergen Ilse
"zeitliche Abfolge" ist aber so ziemlich *immer* Unsinn.

Nein ist's nicht.

Doch.

Post by Bonita Montero
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 ...

Post by Bonita Montero
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 (***@usenet-verwaltung.de)

Bonita Montero

2019-04-15 09:13:37 UTC

Post by Juergen Ilse
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.