Pseudo-Zufallsdatenquelle/senke für Medientests unter Linux

[Uhu U. (uhu)]

Es ist ein einfacher Zufallsgenerator mit fest eingestelltem Startwert, 
der entweder einen "Zufalls"-Datenstrom über stdout ausgibt, oder einen 
Datenstrom von stdin einliest und mit der Ausgabe des Zufallsgenrators 
vergleicht.

# mockrand compilieren:
gcc -o mockrand mockrand.c

sudo -s         # Shell mit root-Rechten öffnen

# 16 GB Testdaten in 1MB-Blocks auf den Datenträger /dev/sdx schreiben:
./mockrand -w | dd of=/dev/sdx bs=1M count=16384

# 16 GB Testdaten in 1MB-Blocks vom Datenträger /dev/sdx lesen und vergleichen:
dd if=/dev/sdx bs=1M count=16384 | ./mockrand -r

Selbstverständlich sind nach dem Test die Daten futsch, die vorher auf 
dem Datenträger waren...

[Frank M. (ukw) (Moderator)]

Uhu Uhuhu schrieb:
> Es ist ein einfacher Zufallsgenerator mit fest eingestelltem Startwert,

Der Code ist leider nicht ganz "sauber".

Das hier:

   !strcmp(argv[1],...

kann einen Core-Dump erzeugen, da Du gar nicht prüfst, ob argc überhaupt 
gleich 2 ist. Wenn Du also das Programm versehentlich ohne Argument 
aufrufst, greift strcmp irgendwo ins Leere...

Die Meldung

   printf("read error @ block 0x%lx\n", lasterr);

ist irreführend. Wenn sie auftritt, dann sind lediglich die Daten 
verschieden. Aber es liegt kein Read-Error (im Sinne von Lesefehler auf 
Betriebssystem-Ebene) vor. Den hättest Du nämlich nach dem 
read-System-Call prüfen müssen... was Du leider vergessen hast ;-)

Verständlicher wäre daher:

   printf("data differs @ block 0x%lx\n", lasterr);

Ausserdem ist der Code nicht Endian-fest: Auf Maschine X (i386) die 
Platte vollschreiben, dann Platte auf andere Maschine Y (Power PC) 
umhängen kann evtl. beim Test in die Hose gehen.

[Uhu U. (uhu)]

Frank M. schrieb:
> kann einen Core-Dump erzeugen, da Du gar nicht prüfst, ob argc überhaupt
> gleich 2 ist.

Ein bischen was kannst du ja auch noch tun ;-) In meiner aktuellen 
Version sind noch einige Sachen mehr gefixt.

> Ausserdem ist der Code nicht Endian-fest: Auf Maschine X (i386) die
> Platte vollschreiben, dann Platte auf andere Maschine Y (Power PC)
> umhängen kann evtl. beim Test in die Hose gehen.

Na ja, für eine quick-and-dirty-Version kann man das verschmerzen...

[Christian B. (casandro)]

Ähm /dev/urandom?

[Alexander S. (esko)]

Hallo Christian,

Christian Berger schrieb:
> Ähm /dev/urandom?

Das ist zwar auch ein PRNG, aber dort werden nach meinem Verständnis 
immer wieder Bits von /dev/random zugeführt. Daher lässt sich die 
resultierende Bitfolge nicht vorhersehen, selbst wenn man einen seed 
festlegt.

Viele Grüße,
Alexander

[Uhu U. (uhu)]

Alexander Schmidt schrieb:
> Daher lässt sich die resultierende Bitfolge nicht vorhersehen, selbst
> wenn man einen seed festlegt.

Zudem können mehrere Programme gleichzeitig Zufallsdaten abrufen. Was 
der Zufallsgenerator dann wem zurückgibt, ist Zufall...