You are not logged in.


malloc / calloc in Verbindung mit char**

Cray X-MP

Moderator

  • "Cray X-MP" started this thread

Posts: 484

Location: Rechenzentrum

Occupation: IT-lerin mit wenig Zeit

  • Send private message

1

Thursday, January 8th 2009, 2:38pm

malloc / calloc in Verbindung mit char**

Hallo an euch,

beim Programmieren eines variablen Stringpuffers (ich benutze dazu char**), ist mir ein etwas Merkwürdiges in Zusammenhang mit malloc bzw. calloc aufgefallen.
Hier ein kleines Beispielprogramm zur Veranschaulichung:

Source code

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#include <stdio.h>
#include <stdlib.h>

#define SIZE 3
 
int main(int argc, char** argv) {
 
    char **buf;
    int i;
 
    //In buf soll spaeter der Inhalt von SIZE C-Strings Platz finden
    buf = (char**) calloc(SIZE, sizeof (char*));
 
    for(i=0; i < SIZE; i++){
        // Jeder einzelne C-String soll eine Zeichenlaenge von 25 inklusive dem Null-Byte haben
        buf[i] = (char*) calloc(25,sizeof(char));
    }
 
    for(i = 0; i < SIZE; i++)
        free(buf[i]);
 
    free(buf);
 
    return (EXIT_SUCCESS);
}


Wenn ich für SIZE z.B. 3 oder eine andere ungerade Zahl einsetze und in der nachfolgenden Schleife beginne Speicher für die einzelnen C-Strings zu reservieren, dann zeigt der Debugger (bei mir unter NetBeans ist das GDB) mehr als drei C-Strings in buf an. Bei geraden Zahlen für SIZE passiert das nicht.

Meine Beobachtungen unter Linux (openSuSE 10.3):
http://compiler.cwsurf.de/blog/2009/01/0…mal-mehr-nimmt/

und Windows XP:
http://compiler.cwsurf.de/blog/2009/01/0…r-nimmt-teil-2/

habe ich schon mit entsprechenden Screenshots auf meinem Blog veröffentlicht.
Durch Verändern der Werte für calloc in Zeile 16 ergab sich kein anderes Resultat. Eine Erklärung dafür habe ich bisher nicht
Weil ich eventuelle Fehler z.B. in GDB nicht ausschließen kann, würde es mich freuen, wenn ein paar Freiwillige das Programm compileren und im Debugger laufen ließen. Gerne auch unter verschiedenen Betriebssystemen und anderen Compilern / Debuggern. Die Ergebnisse sollten dann hier als Beitrag mit Angabe folgender Daten gepostet werden:
  • Betriebsystem ==> bei mir z.B. openSuSE 10.3 / Linux 2.6.22.19-0.1-default i686
  • Architektur ==> bei mir z.B. 32 Bit
  • Compiler ==> bei mir z.B. gcc 4.2.1
  • Debugger ==> bei mir z.B. GNU gdb 6.6.50.20070726-cvs
  • eventuell IDE ==> bei mir z.B. NetBeans 6.5

Erklärungen über mögliche Ursachen sind natürlich auch erwünscht.

Liebe Grüße

Cray X-MP
Die Utopie von heute ist die Realität von morgen. (Ernst Bloch)

Jockel

Ehrenmitglied mit Auszeichnung

Posts: 3,219

Location: 5<<0xE|5<<6|5>>2<<4

  • Send private message

2

Thursday, January 8th 2009, 3:25pm

Hallo!

Alignment. Der Compiler führt ein align an geraden (meist sogar 4/8 Byte) Wortgrenzen durch. Teilweise kann der Prozessor gar nicht anders auf die Speicherseiten zugreifen oder es ist zumindest performanter.

Ich hoffe, dass war das, was du wissen wolltest.

mfg

J.
P = NP.

Cray X-MP

Moderator

  • "Cray X-MP" started this thread

Posts: 484

Location: Rechenzentrum

Occupation: IT-lerin mit wenig Zeit

  • Send private message

3

Thursday, January 8th 2009, 4:52pm

Hallo Jockel,

ah, so ist das also. Wahrscheinlich wird die Anpassung wegen der Breite des Datenbusses durchgeführt.
Beim Blick ins Debuggerfenster hatten mich die "zusätzlichen" Elemente etwas irritiert. Bei einer Google Recherche habe ich dann auch irgendwann mal was gelesen, dass es günstiger sei, wenn die Größe des angeforderten Speichers einer 2er Potenz entspricht.

Danke für die Erklärung, jetzt weiß ich auf jeden Fall mehr.

Liebe Grüße

Cray X-MP
Die Utopie von heute ist die Realität von morgen. (Ernst Bloch)

Similar threads

Rate this thread