Strings mit variabler Länge ohne Terminierung

  • Marco Feltmann schrieb:

    +hm+
    Offenbar gibt es bereits an vorheriger Stelle Probleme, den gewünschten Speicher zu allozieren.
    malloc: *** mmap(size=3482324992) failed (error code=12)
    *** error: can't allocate region
    *** set a breakpoint in malloc_error_break to debug
    Program ended with exit code: 0



    du willst über 3 GB auf dem stack reservieren. da ist ja klar dass er dir sagt dass nicht genügend speicher vorhanden ist (code 12)

  • Marco Feltmann schrieb:

    gritsch schrieb:

    achtung, char temp[length]; wird im stack reserviert und da hast du gleich mal nicht genügend platz dafür. verwende malloc und co um es auf dem heap zu reservieren (free nicht vergessen)!

    Auch das geht in diesem speziellen Fall mitunter in die Hose.

    Marco Feltmann schrieb:

    +hm+
    Offenbar gibt es bereits an vorheriger Stelle Probleme, den gewünschten Speicher zu allozieren.
    malloc: *** mmap(size=3482324992) failed (error code=12)
    *** error: can't allocate region
    *** set a breakpoint in malloc_error_break to debug
    Program ended with exit code: 0


    Ach, es ist auch immer was Anderes...


    was geht in die hose? malloc(3482324992)?

  • Ja, ich will über 3 GB auf dem Heap reservieren.
    Ja, malloc(über 3 GB) geht in die Hose.
    Vielen Dank für den Hinweis! Manchmal sieht man den Wald und so. :)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • gritsch schrieb:

    und warum geht das in die hose?

    malloc: *** mmap(size=3482324992) failed (error code=12)
    *** error: can't allocate region

    gritsch schrieb:

    wieviel speicher hast du frei (RAM/Platte)?

    800MB/195GB
    Wieviel davon dem iOS Simulator zur Verfügung steht weiß ich nicht.

    gritsch schrieb:

    32 oder 64 bit?

    64Bit
    Ob der iOS Simulator das genauso sieht weiß ich nicht.

    Da ich aber Gefahr laufe mehr als 1x mehr als 3GB RAM für einen String reservieren zu müssen, würde ich gern die Situation verhindern wollen, in der Length eine unwahrscheinlich große Größe hat.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    gritsch schrieb:

    und warum geht das in die hose?

    malloc: *** mmap(size=3482324992) failed (error code=12)
    *** error: can't allocate region

    gritsch schrieb:

    wieviel speicher hast du frei (RAM/Platte)?

    800MB/195GB
    Wieviel davon dem iOS Simulator zur Verfügung steht weiß ich nicht.

    gritsch schrieb:

    32 oder 64 bit?

    64Bit
    Ob der iOS Simulator das genauso sieht weiß ich nicht.

    Da ich aber Gefahr laufe mehr als 1x mehr als 3GB RAM für einen String reservieren zu müssen, würde ich gern die Situation verhindern wollen, in der Length eine unwahrscheinlich große Größe hat.


    achso, es geht um iOS development.
    wie willst du da gleichzeitig 8 GB an RAM haben (die 4 GB die du bekommst liegen ja wohl auch drin und dann willst du noch eine kopie davon in den ram legen).
    wozu brauchst du überhaupt die kopie?

  • aja, noch was zur länge. du kannst ja eventuell den pointer so lange dekrementieren bis malloc_size() nicht 0 liefert. dann kannst du mit der differenz der pointer die länge des buffers ausrechnen. wenn dir jemand aber irgendwelche ungültigen werte (zb buffer nicht initialisiert) übergibt dann kommst du auch mit der methode zu keiner gültigen länge (weil die daten ja offensichtlich ungültig sind))

  • gritsch schrieb:

    wie willst du da gleichzeitig 8 GB an RAM haben (die 4 GB die du bekommst liegen ja wohl auch drin und dann willst du noch eine kopie davon in den ram legen).

    Eben nicht. Ich bekomme meinetwegen 17 Zeichen, aber da diese 17 Zeichen Murks sind, erklärt mir der Längenindikator, es wären 3.234.792.138 Zeichen.
    Ich brauche eine Kopie, um daraus einen ordentlichen NSString zu zaubern. Dazu muss ich einerseits die Länge wissen um andererseits ans Ende der Daten ein 0 zu hängen. Dann kann ich nämlich +stringWithUTF8String: nutzen.

    Nach wie vor möchte ich Systemcrashes und Ähnliches vermeiden, wenn besagte Daten Müll sind.
    Und nach wie vor fällt mir dazu nix Sinnvolles ein…
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    gritsch schrieb:

    wie willst du da gleichzeitig 8 GB an RAM haben (die 4 GB die du bekommst liegen ja wohl auch drin und dann willst du noch eine kopie davon in den ram legen).

    Eben nicht. Ich bekomme meinetwegen 17 Zeichen, aber da diese 17 Zeichen Murks sind, erklärt mir der Längenindikator, es wären 3.234.792.138 Zeichen.
    Ich brauche eine Kopie, um daraus einen ordentlichen NSString zu zaubern. Dazu muss ich einerseits die Länge wissen um andererseits ans Ende der Daten ein 0 zu hängen. Dann kann ich nämlich +stringWithUTF8String: nutzen.

    Nach wie vor möchte ich Systemcrashes und Ähnliches vermeiden, wenn besagte Daten Müll sind.
    Und nach wie vor fällt mir dazu nix Sinnvolles ein…


    wie soll ich mir das vorstellen?
    du bekommst nur einen pointer übergeben und keine länge dazu? und die daten auf die der zeiger zeigt sind nicht 0-terminiert?
    was meinst du mit "Längenindikator"? das ergbnis von strlen()?

  • Ein gültiges Beispiel wäre:

    C-Quellcode

    1. uint8_t bytes[12] = {0xFF, 0x09, 0x00, 0x48, 0x61, 0x6C, 0x6C, 0x6F, 0x20, 0x44, 0x75, 0x21};


    Ein ungültiges Beispiel wäre:

    C-Quellcode

    1. uint8_t bytes[5] = {0xFF, 0xEE, 0xAC, 0xEE, 0x01};


    Davon ausgehend, dass 0xFF die Längenangabe einleitet und ein uint16_t mit der Länge folgt.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    Ein gültiges Beispiel wäre:

    C-Quellcode

    1. uint8_t bytes[12] = {0xFF, 0x09, 0x00, 0x48, 0x61, 0x6C, 0x6C, 0x6F, 0x20, 0x44, 0x75, 0x21};


    Ein ungültiges Beispiel wäre:

    C-Quellcode

    1. uint8_t bytes[5] = {0xFF, 0xEE, 0xAC, 0xEE, 0x01};


    Davon ausgehend, dass 0xFF die Längenangabe einleitet und ein uint16_t mit der Länge folgt.


    und du bist dir sicher dass du die werte korrekt ausliest (big/little-endian etc). wie willst du in 16 bit 1 bis 2^32+6 abbilden?
    das klingt irgendwie nach einem file-spec, da gibts ja manchmal auch verschiedene versionen des headers...

  • Hast du zufällig mal ein paar Beispiele wo die Länge nicht passt du aber den "richtigen" String trotzdem rausfinden konntest. Eventuell ist die länge doch nicht einfach ein uint_16 sondern lässt sich anders ermitteln und jemand hier sieht es auf den ersten Blick?

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • gritsch schrieb:

    und du bist dir sicher dass du die werte korrekt ausliest (big/little-endian etc). wie willst du in 16 bit 1 bis 2^32+6 abbilden?

    Nun, je nach Anzahl der 0xFF am Anfang weiß man, ob die Längenwerte uint8_t, uint16_t oder uint32_t sind. ;)

    gritsch schrieb:

    das klingt irgendwie nach einem file-spec, da gibts ja manchmal auch verschiedene versionen des headers...

    Und wie geht man in dem Fall mit korrupten Daten um?

    [Thallius]
    Wenn die Länge nicht passt (also zu kurz ist), ist es kein Problem den richtigen String herauszufinden.
    Wenn die Länge nicht passt (also zu lang ist), dann ist der String halt Müll.

    Ich versuche nur nach wie vor zu verhindern, dass das ganze System abschmiert. Was offenbar immer dann passiert, wenn die Länge so groß ist, dass malloc() den Speicher ob seiner Größe nicht zuweisen kann.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    gritsch schrieb:

    und du bist dir sicher dass du die werte korrekt ausliest (big/little-endian etc). wie willst du in 16 bit 1 bis 2^32+6 abbilden?

    Nun, je nach Anzahl der 0xFF am Anfang weiß man, ob die Längenwerte uint8_t, uint16_t oder uint32_t sind. ;)

    gritsch schrieb:

    das klingt irgendwie nach einem file-spec, da gibts ja manchmal auch verschiedene versionen des headers...

    Und wie geht man in dem Fall mit korrupten Daten um?

    [Thallius]
    Wenn die Länge nicht passt (also zu kurz ist), ist es kein Problem den richtigen String herauszufinden.
    Wenn die Länge nicht passt (also zu lang ist), dann ist der String halt Müll.

    Ich versuche nur nach wie vor zu verhindern, dass das ganze System abschmiert. Was offenbar immer dann passiert, wenn die Länge so groß ist, dass malloc() den Speicher ob seiner Größe nicht zuweisen kann.


    kannst du uns nicht verraten woher die daten kommen?

    warum ist es kein problem die richtige länge des strings rauszufinden wenn die länge zu kruz ist?

  • Die Daten werden als Stream übers Netzwerk von einer Gegenstelle bereit gestellt.

    Wenn die Länge kleiner oder gleich dem Streambuffer ist, dann kann ich darauf ja bequem zugreifen.
    Dies kann beispielsweise passieren, wenn der Streambuffer zwei oder mehr Strings auf einmal beinhaltet.
    In dem Fall hilft der Längenindikator des Strings, die Länge zu bekommen. Der Pointer wird um so viele Bytes verschoben und bekommt dann auch den zweiten und alle weiteren Strings mit.

    Sofern der Längenindikator aber über die Länge des Streambuffers hinaus reicht, bekomme ich halt falsche Speicherdaten rein und habe es schlimmstenfalls mit Speicherverletzungen zu tun.
    Ich hoffte, dieses Problem irgendwie umgehen zu können.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    Die Daten werden als Stream übers Netzwerk von einer Gegenstelle bereit gestellt.

    Wenn die Länge kleiner oder gleich dem Streambuffer ist, dann kann ich darauf ja bequem zugreifen.
    Dies kann beispielsweise passieren, wenn der Streambuffer zwei oder mehr Strings auf einmal beinhaltet.
    In dem Fall hilft der Längenindikator des Strings, die Länge zu bekommen. Der Pointer wird um so viele Bytes verschoben und bekommt dann auch den zweiten und alle weiteren Strings mit.

    Sofern der Längenindikator aber über die Länge des Streambuffers hinaus reicht, bekomme ich halt falsche Speicherdaten rein und habe es schlimmstenfalls mit Speicherverletzungen zu tun.
    Ich hoffte, dieses Problem irgendwie umgehen zu können.


    achsoooo, du bekommst also die KORREKTE länge, aber hast zu wenig daten (die länge kennst du ja auch).
    du musst die daten also eventuell backuppen und weiter lauschen bis wieder daten vorhanden sind!