sprintf und NULL

[rarup]

Hallo !
Ich muß eine recht komplexe Software nach Linux portieren.
Dabei bin ich über ein dummes Problem mit sprintf gestolpert:
Der Code ist sowas wie :

void test(char *b)
{
char *a;
a = malloc(strlen(b)+1); //nachträglich einen Tippfehler korrigiert
sprintf(a, "%s", b);
}

Jetzt lassen wir b mal NULL sein.

Auf AIX, Linux und NT liefert strlen(b) == 0
Auf AIX und NT wird in a auch wirklich nur `\x0`reingeschrieben. Auf Linux dagegen wird da "(null)" (im Klartext) reingeschrieben.

Jetzt stehe ich ratlos vor meinem Suse 8.2 und frag mich was das soll und wie ich das Problem lösen kann ohne eine Wrapperfunktion für das Linux-sprintf zu schreiben. (wie gesagt: der Codzeilen gibt es viele - auch mit sprintf !)
(Ach ja .. der Code ist auch nicht wirklich so wie oben, sondern mit variablen Argumentenlisten, etc. ...)

Wenn man sich das Codebeispiel (welches auf HPUX, Sinix, Aix und NT läuft) oben ansieht ist auch unmittelbar klar, dass es eine schlechte Idee ist sprintf in a was reinschreiben zu lassen, wiels nämlich abstürzt .. aber was solls.

Ein Linux - Programmiererforum gibts hier leider nicht aber vielleicht kann mir trotzdem jemand meine Frage beantworten (bzw. mir einen Tipp zu einem guten Linux-Programmiererforum geben)

Danke, Rainer

[fs111]

doch wir haben auch ein Programmierforum unter www.mrunix.de. Da bist Du besser aufgehoben.

fs111

[Thomas Engelke]

Wie wär's denn mit einem

a=(char*)malloc(strlen(b)+1)
? Oder vielleicht wär ein

a=(char*)calloc(strlen(b)+1,1)
die Lösung?

AD!

[rarup]

Danke für die Antworten !
@fs111
Ich habe die Frage nochmal im Programmiererforum gepostet, danke für den Tipp.
@Thomas
Ok, erwischt ... natürlich muss es malloc(strlen(b)+1) heissen .. den Code hatte ich auch nur schnell fürs Forum entworfen (natürlich unter der GPL ;-) ).

Mein eigentliches Problem sieht sowieso nochmal ganz anders aus und ist mit meiner Test()-Funktion nur zusammengefasst ...

Und, wie gesagt, das Problem ist "sprintf()".

[zander]

Ein NULL Zeiger ist keine gültige C Zeichenkette, Du kannst also nicht mit einer einheitlichen, wohl definierten Reaktion auf einen solchen Rechnen.

[rarup]

@zander
Du hast natürlich recht. Korrekterweise fängt man ab, ob der Zeiger NULL ist. Allerdings habe ich es hier mit Code zu tun, der seit einiger Zeit im Einsatz ist und läuft. Da der Code auch weiterhin auf allen bisherigen Plattformen sowie neuerdings auch Linux laufen soll muß ich mich allso um eine kompatible Lösung bemühen. Dabei kann ich auch hergehen und die Parameter überprüfen. Je mehr ich aber Code ändere der bereits läuft, desto größer wird der Aufwand und das Risko einen Fehler zu machen (wir reden von einigen 100000 Zeilen Code .. und mein Beispiel ist wirklich ganz grob vereinfacht).
Nach aktuellem Stand werde ich also doch speziell für Linux eine Wrapperfunktion schreiben die das macht was ich möchte (die Parameter prüfen und korrekt reagieren)

Ich war halt zunächst baff, dass wenn schon jemand so schlau war das Argument zuverlässig auf NULL zu prüfen, warum derjenige dann ausgerechnet eine 6-zeichen lange Zeichenkette schreibt statt eben einfach *nichts* und dass dann nicht mal in den manpages dokumentiert.

[zander]

Ich kann die glibc Vorgehensweise gut nachvollziehen, die übergebene Zeichenkette ist immerhin nicht "", sondern ungültig: es macht Sinn darauf hinzuweisen. Du wirst wohl nicht vermeiden können, die glibc sprintf Funktion durch eine eigene zu ersetzen, wenn Du die eigentlichen Fehler nicht beheben möchtest (was prinzipiell sinnvoller wäre).

[rarup]

Ja, du hast vollkommen recht was Fehlerbehebung anbelangt.
Allerdings funktioniert das z.B.: auf AIX nicht zufällig richtig. Vielmehr liegt das daran, dass auf AIX auf Adresse NULL halt immer 0 steht. Mir gefällt das besser als die Linux-Lösung die mir etwas zu geschwätzig ist ;-)
Und mit "eigentliche Fehler beheben" ist das so eine Sache denn wie gesagt: der Code läuft und wenn ich jetzt mit - ich nenne das jetzt mal - Codeverbesserungen anfange, dann tue ich mich halt schwer den Termin zu halten.
Zu meiner Ehrenrettung sei jedoch gesagt, dass ich bis jetzt noch immer wenn Zeit ist den Code reviewe und überarbeitete.

Danke nochmal allen, Rainer

[zander]

Ich keine Situation gut verstehen, ich war häufig genug in ähnlichen. Die glibc ist (soviel ich weiß) übrigends weniger geschwätzig, wenn in dem Zielfeld nicht ausreichend Platz für "(null)" ist. ;)