Hallo zusammen.
Ich hab ein Problem mit sprintf. Ich versuche einen Index aus einer über unixODBC angesprochenen Datenbank auszulesen und dann diesen integer Wert mit Hilfe von sprintf in einen char* umzuwandeln. Danach will ich den char* einfach nur ausgeben.
Die Syntax sieht wie folgt aus:
SQLINTEGER eins, seins;
char *streins, zwei[50];
/* Verbindung zur Datenbank aufbauen und Spalten anbinden
zwei wird an eine text-Spalte angebunden, eins an die Index-Spalte*/
while (odbc_erg!=SQL_NO_DATA)
{
odbc_erg=SQLFetch(odbc_hstmt);
sprintf(, seins, "%d", (int)eins);
cout<
On Thursday 04 September 2003 14:39, Volker Jacobsen wrote:
SQLINTEGER eins, seins; char *streins, zwei[50]; /* Verbindung zur Datenbank aufbauen und Spalten anbinden zwei wird an eine text-Spalte angebunden, eins an die Index-Spalte*/
while (odbc_erg!=SQL_NO_DATA) { odbc_erg=SQLFetch(odbc_hstmt); sprintf(, seins, "%d", (int)eins); cout<
Der Witz an der Sache ist der, daß, wenn ich das ganze unter DDD debuge alles einwandfrei läuft,
Glaub' ich nicht. Und wenn, dann wäre das reiner Zufall.
aber wenn ich das Programm in ner Shell laufen lasse, krieg ich nen Speicherzugriffsfehler. Und ich weiß einfach nicht wieso.
Abgesehen von dem Syntax-Error (der Code compiliert ja noch nicht mal):
Wo denkst Du kommt der Speicher her, in den Du mit sprintf() schreibst?
char * streins
Ist ein Zeiger auf Characters, der zu allem Überfluß auch noch ins Nirvana
zeigt. Entweder du allokierst Speicher (malloc(), calloc(), new) oder Du
reservierst ein Array fester Größe wie bei 'zwei'. So jedoch ist völlig klar,
daß es einen Core gibt.
Außerdem gibt es wirklich keinen Grund, bei Ausgabe mit 'cout' selber zu
konvertieren; Du kannst die Daten einfach nach 'cout' werfen. Das ist der
Witz bei C++ -Stream-I/O.
CU
--
Stefan Hundhammer
Stefan Hundhammer schrieb:
On Thursday 04 September 2003 14:39, Volker Jacobsen wrote:
SQLINTEGER eins, seins; char *streins, zwei[50]; /* Verbindung zur Datenbank aufbauen und Spalten anbinden zwei wird an eine text-Spalte angebunden, eins an die Index-Spalte*/
while (odbc_erg!=SQL_NO_DATA) { odbc_erg=SQLFetch(odbc_hstmt); sprintf(, seins, "%d", (int)eins); cout<
Der Witz an der Sache ist der, daß, wenn ich das ganze unter DDD debuge alles einwandfrei läuft,
Glaub' ich nicht. Und wenn, dann wäre das reiner Zufall.
Abgesehen von den Tippfehlern, die durch copy+paste passiert sein könnten, ist es durchaus möglich. Im gdb (der liegt ja meist unter dem DDD) wird der Speicher etwas anders verwaltet als im real life. Da kann dann ein Zeiger auf char, der irgendwohin zeigt, durchaus auf etwas halbwegs vernünftiges zeigen, das dann auch noch o-terminiert ist. -> Kein Speicherzugriffsfehler Das Binary kriegt aber trotzdem das K*tz*n.
aber wenn ich das Programm in ner Shell laufen lasse, krieg ich nen Speicherzugriffsfehler. Und ich weiß einfach nicht wieso.
Abgesehen von dem Syntax-Error (der Code compiliert ja noch nicht mal): Wo denkst Du kommt der Speicher her, in den Du mit sprintf() schreibst?
char * streins
Ist ein Zeiger auf Characters, der zu allem Überfluß auch noch ins Nirvana zeigt. Entweder du allokierst Speicher (malloc(), calloc(), new) oder Du reservierst ein Array fester Größe wie bei 'zwei'. So jedoch ist völlig klar, daß es einen Core gibt.
Sofern es nicht Tippfehler waren...
Außerdem gibt es wirklich keinen Grund, bei Ausgabe mit 'cout' selber zu konvertieren; Du kannst die Daten einfach nach 'cout' werfen. Das ist der Witz bei C++ -Stream-I/O.
Wenn er es aber trotzdem in einem String brauchen sollte, dann folgender Vorschlag: int main (int argc, char *argv[]) { int eins; char streins[51]; eins = atoi (argv[1]); memset (streins, 0, 51); int2string (streins, eins); printf ("%s\n", streins); } int int2string (char *strzwei, int zwei) { char dummy[2]; dummy[1] = 0; if (zwei > 9) { int2string (strzwei, zwei / 10); } dummy[0] = zwei % 10 + 48; strcat (strzwei, dummy); } Ist plain C. In main() hat er dann seinen String in streins stehen. Wenn er sich in int2string() die Schachtelungstiefe merkt, braucht er überhaupt keine Stringfunktion, sondern kann direkt nach strzwei[x] schreiben. Ihm kann egal sein (wenn er eine positive Zahl verwendet), ob bei der Ausgabe evtl. ein Leerzeichen für das nicht vorhandene Vorzeichen reserviert wird oder nicht. Usw. Es ist immer schwierig in solche aus dem Kontext gerissene Beispiele reinzuinterpretieren, wieso es grade so sein muß, und nicht komplett anders. CU Dierk
On Thursday 04 September 2003 15:47, dfroehling wrote:
Im gdb (der liegt ja meist unter dem DDD) wird der Speicher etwas anders verwaltet als im real life. Da kann dann ein Zeiger auf char, der irgendwohin zeigt, durchaus auf etwas halbwegs vernünftiges zeigen, das dann auch noch o-terminiert ist. -> Kein Speicherzugriffsfehler
Das meinte ich mit "Zufall". ;-)
CU
--
Stefan Hundhammer
Stefan Hundhammer schrieb:
On Thursday 04 September 2003 15:47, dfroehling wrote:
Im gdb (der liegt ja meist unter dem DDD) wird der Speicher etwas anders verwaltet als im real life. Da kann dann ein Zeiger auf char, der irgendwohin zeigt, durchaus auf etwas halbwegs vernünftiges zeigen, das dann auch noch o-terminiert ist. -> Kein Speicherzugriffsfehler
Das meinte ich mit "Zufall". ;-)
Ist aber reproduzierbar blöderweise. ;-) Wehe man (oder externe Ereignisse) füllen mal wieder einen String bis zum letzten Byte auf, und man verläßt sich an anderer Stelle drauf, daß man vorher alle Bytes auf 0 gesetzt hat (also eigentlich eine 0-Terminierung hat). Deswegen sind mir Char-Arrays oder Char-Pointer die auf Speicherbereiche mit geradzahliger Länge gehen, immer suspekt. Es ist zwar keine Garantie, daß man das Vollaufen korrekt abfängt, wenn man n+1 statt normalerweise n Bytes reserviert, aber es zeigt, daß der Programmierer zumindest tlw. mitgedacht hat. Deswegen hatte mein Array auch 51 und nicht 50 Elemente; auch wenn ich die Länge nicht abgeprüft habe. Wie auch immer; es ist müßig über Code zu diskutieren, der aus dem Zusammenhang gerissen ist. Wenn er's in einem String haben will, dann soll er es auch so bekommen. CU
participants (3)
-
dfroehling
-
Stefan Hundhammer
-
Volker Jacobsen