Daten aus Speicher in FILE * lesen

[etk55 (Gast)]

Guten Tag,

derzeit versuche ich einige C Funktionen einer C-Software an einen ARM 
Controller anzupassen.
Es handelt sich hierbei um einen Datenkompressionsalgorithmus.

Auf dem PC wird über stdin eine Datei übergeben, die in der FILE * 
Struktur der stdio.h festgehalten wird.

ret = Datenkompression (stdin) ;

Der Prototyp der Datenkompressionsfunktion sieht folgendermaßen aus:

 int Datenkompression ( FILE * source);

Auf dem PC wird eine Datei über stdin eingelesen. Allerdings kann ich 
auf meinem ARM keine Datei über stdin einlesen. Ich würde hier gerne mit 
einem Zeiger auf eine Speicheradresse zeigen. Der Zeiger soll eine 
bestimmte Länge haben, je nachdem wie groß die Datei ist.

Ich habe jedoch im Moment keine Idee, wie ich das umsetzen könnte. Kennt 
ihr eine Funktion oder habt ihr eine Idee, wie ich meinen Speicherinhalt 
in
FILE * hinterlegen kann ?

Mein Ziel ist es, dass ich nachher die Funktion Datenkompression aufrufe 
und einen Zeiger auf die Speicheradresse und Länge übergebe.
Habt ihr eine Idee ?

[Marcel (Gast)]

etk55 schrieb:
> Ich habe jedoch im Moment keine Idee, wie ich das umsetzen könnte. Kennt
> ihr eine Funktion oder habt ihr eine Idee, wie ich meinen Speicherinhalt
> in
> FILE * hinterlegen kann ?

Dokumentation lesen:

typedef struct  /* needs to be binary-compatible with old versions */
{
#ifdef _STDIO_REVERSE
  unsigned char  *_ptr;  /* next character from/to here in buffer */
  int    _cnt;  /* number of available characters in buffer */
#else
  int    _cnt;  /* number of available characters in buffer */
  unsigned char  *_ptr;  /* next character from/to here in buffer */
#endif
  unsigned char  *_base;  /* the buffer */
  unsigned char  _flag;  /* the state of the stream */
  unsigned char  _file;  /* UNIX System file descriptor */
} FILE;

Musst du nur entsprechen füllen.

etk55 schrieb:
> Mein Ziel ist es, dass ich nachher die Funktion Datenkompression aufrufe
> und einen Zeiger auf die Speicheradresse und Länge übergebe.
> Habt ihr eine Idee ?

Dann musst du die Funktion Datenkompression so umschreiben, dass sie ein 
Datenbuffer und Länge der Daten annimmt (Datenkompression(const char 
*daten, uin32_t laenge);) statt einer FILE Struktur.

[Dr. Sommer (Gast)]

Marcel schrieb:
> Musst du nur entsprechen füllen.

Und damit soll fread dann klar kommen? !

Marcel schrieb:
> Dann musst du die Funktion Datenkompression so umschreiben, dass sie ein
> Datenbuffer und Länge der Daten annimmt
Richtig. Oder ein Pipe und fdopen verwenden; dann braucht's aber 
multithreading um die Daten reinzuschaufeln.

[Marian (phiarc)]

Dr. Sommer schrieb:
> Und damit soll fread dann klar kommen? !

Das ist natürlich alles fernab der Spezifikationen, aber einen Versuch 
wärs wert zu schauen, ob fread() überhaupt irgendwelche Syscalls 
absetzt, wenn der Buffer noch gefüllt ist.

[Dr. Sommer (Gast)]

Marian B. schrieb:
> Das ist natürlich alles fernab der Spezifikationen, aber einen Versuch
> wärs wert zu schauen, ob fread() überhaupt irgendwelche Syscalls
> absetzt, wenn der Buffer noch gefüllt ist.
So etwas vorzuschlagen ist ja geradezu gemeingefährlich... Da wäre ich 
doch stark für pipe+fdopen. Oder tatsächlich eine Datei anzulegen, aber 
sie in ein tmpfs zu packen. Oder den Algorithmus umzuschreiben, das 
dürfte mit Abstand das einfachste sein.
Was für ein komischer Kompressionsalgorithmus verlangt überhaupt 
zwingend ein FILE*? Vernünftige Implementierungen wie die zlib können 
das auch direkt im Speicher...

[Karl H. (kbuchegg)]

Marian B. schrieb:
> Dr. Sommer schrieb:
>> Und damit soll fread dann klar kommen? !
>
> Das ist natürlich alles fernab der Spezifikationen, aber einen Versuch
> wärs wert zu schauen, ob fread() überhaupt irgendwelche Syscalls
> absetzt, wenn der Buffer noch gefüllt ist.

Ach so war das gemeint!


Hmm. Gar nicht mal so dumm, die Idee. Dem I/O System quasi sowas wie 
eine 'RAM-Disk' in Form eines gefüllten Memory-Buffers unterjubeln.
Aber nichts für jemanden, der in einem Forum mit einer Wortwahl fragen 
muss, die ganz klar zeigt dass das alles böhmische Dörfer für ihn sind.

Probleme könnten bei der eof Behandlung innerhalb des I/O Systems 
auftreten.