Rolf-Hubert Pobloth schrieb: TEXTEINTRAG00000000000000000000000000000000000000000000000000325,2500000 000

Wo kann man dieses in unserer Linux-Dokumentationeventuell finden. "sizeof (..)" ist hierbei leider nicht hilfreich, da ich nichts kompiliere.

Das hat mit den Größen der Datentypen selbst nur bedingt etwas zu tuen. Die genannten Größen waren die Größen in dem Speicher. Hier hast Du aber eine Textform vorliegen. Da kann ich Dir nur raten, dass Du selbst die Trennzeichen herausbekommst. Einfach die Einträge anschauen, ob Du hier Felder erkennen kannst. Bei dem Eintrag vermute ich z.B. hinter der ,25 ein Feldende (Falls es sich um einen Betrag handelt). Das dies so korrekt ist, ist auch einfach erkennbar. Beispiel Geldbetrag. Ich kann einen Geldbetrag in einem double speichern. Jetzt kann ich im double auch werte wie 1,02345783576 speichern. Aber als Geldbetrag ist es unsinn und wird in der Applikation nicht vorkommen. Somit gebe ich auch nur zwei Stellen hinter dem Komma aus. Oder in der Höhe. Es mag zwar sein, dass auch ein Betrag von 123.425.432.432.432,23 abspeicherbar wäre. Aber ich gehe erst einmal davonaus, dass es diese hohen Beträge nie geben wird! (Was soll soviel kosten? Und was kriegt man dann noch für die ,23 ???) Daher ist dieses Format, welches Du erraten willst, komplett eigen vom Entwickler gewählt. Und je nachdem, wie sinnvoll er es gemacht hat, kann es alles oder nichts sein. Entweder Du hast eine Datensatzbeschreibung oder Du musst raten. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53

Frank Spiess [Thu, 26 Jun 2003 12:50:38 +0200]:

...

short

2 Byte

Nur mindestens

...

long

4 Byte

ebenfalls nur mindestens. Auf einem 64-Bit System ist long z.B. meistens 8 Byte lang. Der C Standard definiert nur jeweils die Mindestlänge, die ein Typ haben muss und dass z.B. int niemals kürzer als short ist. Genau deshalb kann das zur Plattform gehörende ABI long als 8 Byte definieren. Richtig nett wird es jetzt noch, wenn diese Werte Teil von Strukturen sind, denn dann kommen u.U. noch Füllbytes dazu, die dazu dienen, die Felder im Speicher so anzuordnen, dass der Prozessor möglichst optimal zugreifen kann. So können Sparcs z.B. nicht auf ungerade Adressen zugreifen, weswegen der Compiler dafür sorgen muss, dass Werte immer mit einer geraden Adresse beginnen. Philipp

Adalbert Michelic ," schrieb:

#include

int main() { printf("sizeof(char) = %d\n", sizeof(char)); printf("sizeof(short) = %d\n", sizeof(short)); printf("sizeof(double) = %d\n", sizeof(double)); printf("sizeof(long) = %d\n", sizeof(long)); return 0; }

Sehr schön - dazu war ich etwas zu faul :)

adalbert@pepe:/tmp > gcc -o sizeof sizeof.c adalbert@pepe:/tmp > ./sizeof sizeof(char) = 1 sizeof(short) = 2 sizeof(double) = 8 sizeof(long) = 4

Diese Werte sind aber nicht festgelegt! Dies kann somit ganz klar variieren! Und evtl. auch mit wichtig: Ebenfalls die Codierung kann sich unterscheiden, sprich: Selbst wenn man durch Zufall zwei Systeme hat, wo ein long genau 4 Bytes gross ist, kann die gleiche Zahl unterschiedlich codiert sein. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53

Am Don, 2003-06-26 um 13.41 schrieb Ralf Corsepius:

Am Don, 2003-06-26 um 12.08 schrieb Konrad Neitzel:

...

Adalbert Michelic ," schrieb:

...

...

adalbert@pepe:/tmp > gcc -o sizeof sizeof.c adalbert@pepe:/tmp > ./sizeof sizeof(char) = 1 sizeof(short) = 2 sizeof(double) = 8 sizeof(long) = 4 Darüberhinaus können die Grössen sogar noch von Compiler-Flags abhängen, weshalb jede hard-codierte Grössenanname in Programmcode per Definition als Programmierfehler anzusehen ist (Einer *der* weitest verbreiteten Fehler und Portabilitätsprobleme)

In modernem Code sollte man für Typen fester Grösse statt char, short etc. die in stdint.h definierten Typen int8_t, int16_t usw. verwenden. (stdint.h ist neuerer POSIX-Standard und auf allen halbwegs aktuellen POSIX-kompatiblen Systemen vorhanden).

Habe mir mal die stdint.h angesehen und kann mir unter int8_t z.B. den Wertebereich ansehen. Wenn aber diese Variable nun als int_8t, int16_t oder int32_t abgespeichert wird, dann bleibt für mich noch die Frage, wenn die Variable den Wert 0 enthält, wieviele Bytes finde ich dann in der Datei im Datensatz. Betrag1 = int32_t Wert 12.345.678.90 (die Punkte nur wg der besseren Übersicht. Und nun die Frage: Sind es 32 Bits = 2 Bytes oder sind es 4 oder 8 Bytes. Es handelt sich bei der Datei nicht um eine Textdatei, sondern um kumulierte Buchhaltungsdaten. Es gibt kein Satzendezeichen und die Sätze sind verschieden lang. Die Sätze werden nur durch ihre Satzart 4 Stellen Textfeld definiert Eine alte Index-Sequentielle Datenbank

Und wenn wir mal pedantisch sein wollen, es gibt auch Systeme auf denen der ein oder andere "Fixed-Size"-Typ nicht vorhanden ist. Diese sind zwar selten anzutreffen und im Linux/Unix-Umfeld ziemlich bedeutungslos, doch es gibt sie.