Bestehendes Projekt um arm64 erweitert - Was alles beachten/testen?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Bestehendes Projekt um arm64 erweitert - Was alles beachten/testen?

    Hallo,

    ich habe bei einem bestehenden iOS 7+ Projekt arm64 zu den Architekturen hinzugefügt. Der Compiler hat hiernach ein verschiedenen Stellen über int/long/NSInteger gemeckert, also dass, was man bei x64 auch erwartet. Nachdem das korrigiert war, läuft das Projekt aber eigentlich ohne Probleme.

    Ich bin etwas skeptisch ob die Umstellung/Erweiterung damit wirklich schon geschafft ist. Gibt es irgendetwas was man noch besonders beachten oder testen sollte? Bei meinen Tests ist mir wie gesagt nichts aufgefallen. Aber ein paar Testeingaben und -bedienungen sind natürlich etwas anderes als tausende von Nutzer die später in der App herum hacken.

    Habt ihr schon Projekte umgestellt und könnt sagen ob es wirklich so problemlos abläuft wie es aussieht?

  • NSInteger und NSUInteger sind auf 64-Bit-Prozessoren 8 Byte lang und auf 32-Bit nur 4 Byte. Dieser Unterschied macht sich gerne bei Formatangaben bemerkbar (z. B. NSLog, stringWithFormat:). In der Regel sollten die meisten int-Variablen im Programm unproblematisch sein. Da man long häufig verwendet, wenn man mehr Bytes braucht, würde ich eher die Typen mit expliziter Breitenangabe (z. B. int64_t) verwenden.
    „Meine Komplikation hatte eine Komplikation.“

  • Richtig auffällig wird das Ganze allerdings erst, wenn Du Binärdaten von einer 32Bit Maschine auf eine 64Bit Maschine überträgst und vice versa.
    Sei es via WLAN oder aus einem generierten Binary File.

    Da kann es einfach sein, dass Dein 64Bit Code aus zwei NSInteger einen NSInteger macht, dementsprechend nur die Hälfte an NSIntegern bekommt und diese sind dann auch noch falsch.

    Auf den einzelnen Architekturen selbst sollte es hingegen relativ wurscht sein.
    Es ist ja glücklicherweise nicht der Fall, dass das 64Bit System je nach Sonnenstand einmal den NSInteger mit 4 und einmal mit 8 Byte abbildet.
    «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

  • macmoonshine schrieb:

    NSInteger und NSUInteger sind auf 64-Bit-Prozessoren 8 Byte lang und auf 32-Bit nur 4 Byte. Dieser Unterschied macht sich gerne bei Formatangaben bemerkbar (z. B. NSLog, stringWithFormat:).


    das finde ich echt beschissen gelöst von apple. hätten sie nicht einfach neue format-specifier einführen können?
    dieses drecks gecaste auf long bzw unsigned long müsste echt nicht sein. viele drehen einfach die kompletten warnings für format specifier ab - das kann aber auch nicht sinn der sache sein und zu bösen überraschungen führen :(

  • Marco Feltmann schrieb:

    Richtig auffällig wird das Ganze allerdings erst, wenn Du Binärdaten von einer 32Bit Maschine auf eine 64Bit Maschine überträgst und vice versa.
    Sei es via WLAN oder aus einem generierten Binary File.

    Da kann es einfach sein, dass Dein 64Bit Code aus zwei NSInteger einen NSInteger macht, dementsprechend nur die Hälfte an NSIntegern bekommt und diese sind dann auch noch falsch.

    Auf den einzelnen Architekturen selbst sollte es hingegen relativ wurscht sein.
    Es ist ja glücklicherweise nicht der Fall, dass das 64Bit System je nach Sonnenstand einmal den NSInteger mit 4 und einmal mit 8 Byte abbildet.


    wer bei dateiformaten oder netzwerkverkehr sowas wie NSUInteger etc verbindet hat wohl auch ein rad ab. Wozu gibts denn schließlich XintYZ_t?

  • macmoonshine schrieb:

    Marco Feltmann schrieb:

    Sei es via WLAN oder aus einem generierten Binary File.

    Da sollte man sich vorher ordentlich Gedanken über die Bit-Breiten machen und nur die Typen mit definierter Breite verwenden. Außerdem sollte man auch an die Byte-Order denken.


    ja aber auch die byte-order spielt ja normalerweise keine rolle. denn es gibt normal eine definition der schnittstelle/dateiformat.
    auch wenn man 2 programme für unterschiedliche platformen entwicklet hat die jeweils das gleiche dateiformat verwenden aber einmal big- und einmal litte-endian verwenden, so ist das normalerweise bereits an einem feld im header erkennbar und kann noch korrigiert werden. wenn sich aber die programme nicht drum kümmern und der eine dann wild ein feld mit LE und der andere ein anderes mit BE befüllt dann ist es das ende.
    genauso ist derjenige selbst schuld der irgendwelche datentypen verwendet die nicht eine fixe länge haben. bei uint32_t kann man davon ausgehen dass dieses auf jeder platform ein unsigned integer aus 32 bit ist. gibt es diesen datentyp auf einer platform nicht, so kann der per typedef problemlos bereitgestellt werden. wenn aber irgendjemand davon ausgeht dass "int" 32 bit lang ist oder "long" bit dann gibts böse überraschungen ;)

  • gandhi schrieb:

    gritsch schrieb:

    wenn aber irgendjemand davon ausgeht dass "int" 32 bit lang ist oder "long" bit dann gibts böse überraschungen


    Aber sind wir mal ehrlich, das Problem ist in den C-Dialekten seit mindestens 30 Jahren bekannt. Wahrlich nix neues, und jeder der in C-ähnlichen Sprachen nicht ganz blind durch die Gegend läuft sollte sich dessen bewusst sein.

    ciao

    gandhi


    und es also seit 20 jahren korrekt machen ;)