From: /^GHS^\\\\ S. <sf...@te...> - 2003-01-08 15:03:51
|
Well, first of all the code: #include <stdio.h> #include <stdlib.h> // simple vector printer void print_vector (int *matrix, int n) { int i; for(i=0; i<=(n-1); ++i) { if ((n-1)==0) printf("( "); else { if (i==0) printf("/ "); else if (i==(n-1)) printf("\\ "); else printf("| "); } printf("%i ",matrix[i]); //format of printed vectors if ((n-1)==0) printf(")\n"); else { if (i==0) printf("\\\n"); else if (i==(n-1)) printf("/\n"); else printf("|\n"); } } } // reads a vector with n elements from file "data" int *vec_input(int *n, FILE *inputfile) { int i; int *vec; fscanf(inputfile,"%d", n); vec = (int*)malloc(sizeof(int)); vec[0] = (int)calloc((int)n,sizeof(int)); for (i = 0; i < *n; i++ ) fscanf(inputfile,"%i", &(vec[i])); return vec; } void main(void) { FILE *inputfile; int *a, n; inputfile = fopen("data", "r"); a = vec_input(&n, inputfile); print_vector(a, n); free(a); //THIS LINE CRASHES LINUX!! } This programm reads an array (vector) from the file data, the first entry in this file is the count of vector elements. Afterwards it gets printed and the program should exit. What's weird is, that Windows and MinGW compiles this code perfectly, and there is no problem. Linux however produces a segmentation fault, when free(a) is executed. I have no idea why. I have also no idea why you have to use the malloc stuff in Linux, in Windows it would work with just with one simple vec = calloc((int)n,sizeof(int)); but when I try this in Linux, it produces also a segmentation fault, when the vector is accessed in the read function. But what I really want to know is, how to create a working free() call. Thanks for any help, Xen -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife |
From: Greg C. <chi...@mi...> - 2003-01-08 17:13:50
|
/^GHS^\\\\ SPhiNX wrote: > > Well, first of all the code: [...] > but when I try this in Linux, it produces also a segmentation fault, when the vector is accessed in the read function. > > But what I really want to know is, how to create a working free() call. This doesn't appear to bear directly on mingw or gcc. Suggest you try the alt.comp.lang.learn.c-c++ newsgroup. |
From: Benjamin R. <Ben...@ep...> - 2003-01-08 17:45:55
|
Hi Xen, I don't want to sound rude, but you should probably post to some C newbies list. There is nothing compiler specific to your problem, just confused programming. Of course we all were there at some time ;-). > I have also no idea why you have to use the malloc stuff in Linux, > in Windows it would work with just with one simple vec = > calloc((int)n,sizeof(int)); There is no difference how a C program should look between Linux and Windows, at least not at the level that you are using. It's just that bugs in your code cause different results on different compilers and OSs. Some tips: - Don't cast, unless you really know what you are doing. Casting is basically saying that you know better than the compiler. More often than not, you don't really know better (nor do other programmers). - Run at the highest possible warning level. For gcc I add -Wall to the command line, sometimes I also try -pedantic. - Run in standards compliance mode. For gcc that means -ansi or -std c9x. - Add error checking to all functions calls, especially when they return data your next code wants to work with and when you have problems. In your case error checking the results of fopen() and the first fscanf() are essential, because if these fail, it's no wonder when the rest of the code crashes. - Through away the book or tutorial that told you to use void main(). main() returns an int and there is no alternative. - When asking questions on mailing lists or newsgroups drop *anything* that doesn't add to the problem. Your example program can loose most of the printf() calls, and you can fold functions into main to reduce the size of the program text. Often when you reduce the code to essentials you may discover that the problem goes away - that means you have located the direct source of the problem in the bits that you removed - or you may understand better what your program actually does and from that you may understand the reason for your problem. - When free() or malloc() crash that is usually a sign that you have written to space that you didn't actually allocate. Some versions of malloc() write important data into the space before and/or after the blocks that you allocate. free() relies on that data to be correct, and it can crash when you have written into that memory. Hope this helps, benny |
From: Soren A <sor...@fa...> - 2003-01-09 21:17:14
|
Benjamin Riefenstahl <Ben...@ep...> wrote in news:m3v...@ci...: > > Some tips: > > - Don't cast, unless you really know what you are doing. Casting is > basically saying that you know better than the compiler. More often > than not, you don't really know better (nor do other programmers). Sorry to perpetuate a non-MinGW thread, but I have a quick observation. Isn't it the case that an exception to the above, that might be extremely familiar and self-evident to nearly all readers, but not to C/C++ newbies, is that a call to a standard malloc() such as in GNU C is always going to include a cast to the type you need allocated? (Thanks for your patience, everyone). Soren A |
From: Joerg B. <jo...@sq...> - 2003-01-10 10:15:18
|
Hi, and a Happy New Year to all of you! Soren A wrote: > > Benjamin Riefenstahl <Ben...@ep...> wrote in > news:m3v...@ci...: > > > > > Some tips: > > > > - Don't cast, unless you really know what you are doing. Casting is > > basically saying that you know better than the compiler. More often > > than not, you don't really know better (nor do other programmers). > > Sorry to perpetuate a non-MinGW thread, but I have a quick observation. Well, some time ago there was a (silent?) consensus to include some C / C++ programming questions for newcomers to the MinGW environment. > Isn't it the case that an exception to the above, that might be > extremely familiar and self-evident to nearly all readers, but not to > C/C++ newbies, is that a call to a standard malloc() such as in GNU C is > always going to include a cast to the type you need allocated? [...] AFAIR threads in C groups, there is a significant difference about the use of 'malloc' between C and C++. The way I understood it: - In C, 'malloc' (defined in "stdlib.h" headers) returns type 'void *', so the result can be assigned to any (data) pointer, and a cast should _not_ be used. (See http://www.eskimo.com/~scs/C-faq/q7.7.html and surrounding questions.) - In C++, the 'malloc' return value _must_ be cast because the implicit conversion from 'void *' to 'type_needed *' is not done. (source: comment in the German C FAQ at question 3.5, http://www2.informatik.uni-wuerzburg.de/dclc-faq/kap3.html ) Please see the C and C++ groups / FAQs for more details. Regards, Joerg Bruehe -- Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany (speaking only for himself) mailto: jo...@sq... |
From: Benjamin R. <Ben...@ep...> - 2003-01-10 18:13:05
|
Hi all, Joerg Bruehe <jo...@sq...> writes: > - In C++, the 'malloc' return value _must_ be cast because the > implicit conversion from 'void *' to 'type_needed *' is not done. > (source: comment in the German C FAQ at question 3.5, > http://www2.informatik.uni-wuerzburg.de/dclc-faq/kap3.html ) Of course C++ programers are *strongly* encouraged to use the new operator instead of malloc() anyway. so long, benny |