🚀 go-pugleaf

Sepp@ppcger.ppc.sub.org (Josef Wolf) writes:

>In <1992Jul21.093829.5477@infoserver.th-darmstadt.de> misch@rbhp90.rbg.informatik.th-darmstadt.de (Clemens Misch) writes:
>] In article <1992Jul20.141723.16054@news.DKRZ-Hamburg.DE>, peters@dkrz-hamburg.dbp.de (Heino Peters) writes:
>] > In article <BvuoqG@ppcger.ppc.sub.org> Sepp@ppcger.ppc.sub.org (Josef Wolf) writes:
>] > >n = 0;
>] > >if (tmp -> bar = (char **) malloc (arraysize * sizeof (char *))) {
>] > >    while (laber) {
>] > >        [ ... ]
>] > >        if (!((tmp -> bar)[n++] = strdup (blubber)))  /* hier kracht es */
>] > >	    break;
>] > >    }
>] > >}
>] > > [..]
>] > >Er berechnet saemtliche offsets _bevor_ er strdup() aufruft. Soweit, so
>] > >gut. Das Problem ist nun dass der Inhalt von d1 nach der Rueckkehr von
>] > >strdup() zerstoert ist. Ansonsten ist der Code durchaus akzeptabel.
>[ ... ]
>] > Ein gemeiner Hack waere strdup(blubber,0) aufzurufen. Das zweite Argument
>] > wird in d1 uebergeben und dann (hoffentlich) von strdup() ignoriert.
>] Das ist ein bekannter Fehler von MW CC 3.2. In einer der Release Notes
>] fuer OSK V2.3 ist dieser Fehler beschrieben mit genau dem Workaround
>] die Du angegeben hast.

>Da koennte man auf die Idee kommen, einfach einen #define reinzumachen.
>Trotzdem habe ich da ein sehr ungutes Gefuehl bei. Wenn das bei strdup()
>passiert, kann es ja mindestens genauso auch bei jeder anderen Funktion
>mit nur einem Parameter und einer lokalen Variable passieren...

>Gibt es da evtl noch einen anderen Workaround?

>Gruss
>    Sepp

Aehm. Ich habe mich nochmal sachkundig gemacht. Der von mir zitierte
Fehler trifft nur auf Funktionen zu, die mit einer variabel langen
Parameterliste aufgerufen werden, aber in der formalen Parameterliste
(d.h. bei der Deklaration) nur einen Parameter deklariert haben. Dann
sichert der Compiler nicht das Register D1. Der Compiler der mit der
OS Version 2.4 geliefert wird, hat angeblich den Fehler nicht mehr
(dafuer sicher andere :-)

'Strdup' ist meines Wissens nach nicht in der Microware Bibliothek
dabei. Es koennte durchaus sein, dass die benutzte Implementieung
fehlerhaft ist. 

BTW. Ich verwende keine so komplexen Konstrukte wie oben. Typischer- 
weise erzeugt der MW Compiler besseren Code, wenn man ihm etwas unter
die Arme greift (in dem man komplizierete Sachen selber auseinander
nimmt :-( ). Ich hoffe noch auf gcc 2.2.2 (keine Zeit das selbst zu
machen)!  Den Compilern aus dem Hause MW traue ich nicht mehr ueber
den Weg.
-- 
===============================================================================
Clemens Misch                                        Rechnerbetriebsgruppe FB20
                                                     Merckstrasse 25 
EMail: misch@rbhp90.rbg.informatik.th-darmstadt.de   W6100 Darmstadt (Germany)