please help with mysterious error....

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Hi,

In continuation of the thread I made "perhaps a stack problem? Long
calculations - strange error?", I think I now got a "stable" error,
meaning that the error always seem to come here now (tried: visual
studio 2005 + linux/macintosh gcc)...

That's a pretty good thing. I think the error still appears using both
gcc and visual studio 2005. Everything is standard C (ANSI C ?? I don't
know the difference) - but since so many functions depend on different
variables it's hard for me to isolate the error or to make a minimal
example ready for posting...

What can I say: I don't get any compile errors/warning... I tried
valgrind, but it wrote something I didn't agree with or I didn't
understood what it disliked...


Instructions:

1) Download + unzip (there are no binaries so no viruses/spam/whatever)
2a) Under linux/mac os: just type "make" (makefile included)
2b) Under windows: I guess you just create a new project and drag the
*.c and *.h files into it and compile/build.
3a) Either run the program and see the error or
3b) put a breakpoint in "result_output.c" line 748, then step a few
lines and watch what happens.

What is wrong?


for(i=0; i<total_linepieces; i++);
{
printf("i = %d\n", i); /* i should be 0 now, right? */
if( i != 0)
{
printf("\n\nTHE PROGRAM DOESN'T WORK\n\n");
quit_program(__FILE__, __LINE__);
}
else
{
printf("\n\nTHANKS!!! THE PROGRAM WORKS\n");
quit_program(__FILE__, __LINE__);
}
}

Some memory-garbage-thing, probably...


I'm really really fed up and tired of this bug, because I can't find it
and the compiler doesn't help me...

I've prepared 2 archives: .zip + .tar.gz.

(enter code + click blue button "START DOWNLOAD")
zip: http://www.uploading.com/?get=N3PT46TP

(click "DOWNLOAD", yellow bar bottom right).
tar.gz: http://www.savefile.com/files/2695995


It would also be nice to know how to avoid such a problem in the future,
when the compiler doesn't help...


Best regards
Martin Jørgensen

 

[Bas Wassink]

Hi,

In continuation of the thread I made "perhaps a stack problem? Long
calculations - strange error?", I think I now got a "stable" error,
meaning that the error always seem to come here now (tried: visual
studio 2005 + linux/macintosh gcc)...

That's a pretty good thing. I think the error still appears using both
gcc and visual studio 2005. Everything is standard C (ANSI C ?? I don't
know the difference) - but since so many functions depend on different
variables it's hard for me to isolate the error or to make a minimal
example ready for posting...

What can I say: I don't get any compile errors/warning... I tried
valgrind, but it wrote something I didn't agree with or I didn't
understood what it disliked...

What is wrong?


for(i=0; i<total_linepieces; i++);

I think you should remove the semicolon here, now this line just
increments i until it's equal to 'total_linepieces', and afterwars the
following code gets executed.

{
printf("i = %d\n", i); /* i should be 0 now, right? */ if( i != 0) {
printf("\n\nTHE PROGRAM DOESN'T WORK\n\n"); quit_program(__FILE__,
__LINE__);
}
else
{
printf("\n\nTHANKS!!! THE PROGRAM WORKS\n"); quit_program(__FILE__,
__LINE__);
}
}

Some memory-garbage-thing, probably...


I'm really really fed up and tired of this bug, because I can't find it
and the compiler doesn't help me...

It would also be nice to know how to avoid such a problem in the future,
when the compiler doesn't help...


Best regards
Martin Jørgensen

Hope this helps,
Bas Wassink

 

[=?windows-1252?Q?Martin_J=F8rgensen?=]

I think you should remove the semicolon here, now this line just
increments i until it's equal to 'total_linepieces', and afterwars the
following code gets executed.

OMFG! That code was driving me "#€%()#€%€(%##€(#€%( crazy and then I
just overlooked that?

I think I've looked many other places, but that... Oh, well. Nice to get
some feedback... Thanks.


Best regards
Martin Jørgensen

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Martin Jørgensen said:




I got 92 lines of complaint from gcc.

Ok, since this problem was just a semi-colon in the wrong place (C is
really a bitch to me sometimes, LOL) I have the feeling that my original
problem perhaps could have been that 2 of my variable arrays was
malloc'ed 2 bytes too small, each (the "perhaps a stack problem?-thing")...

Here are the edited highlights:

main.h:46: warning: declaration of `dx' shadows global declaration
main.h:47: warning: declaration of `dy' shadows global declaration

(lots and lots of similar diagnostics)

.//main.c:32: warning: passing arg 1 of `get_nx_ny_nz' discards qualifiers
from pointer target type
.//main.c:49: warning: passing arg 1 of `quit_program' discards qualifiers
from pointer target type

(lots and lots of similar diagnostics)

When you get a clean compile at a reasonably fascist warning level, come on
back.

Eerhm, please help me get to know how I get so many warnings printed out
so I can fix them... I don't get any if I just type make.

How did you compile (detailed instructions, please)...

I was told that just typing "make" was sufficient (I didn't make the
makefile myself), but I also had the feeling that much more was wrong...

I was actually also wondering why that global variable definitions
didn't work...


Best regards
Martin Jørgensen

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Martin Jørgensen said: -snip-

When you get a clean compile at a reasonably fascist warning level, come on
back.

Erhm, even better yet: How do I make a/modify my makefile so the program
gets compiled with the highest warning/error-output level every time?

Basically I just want something where I just type "make" and then I see
all (92 lines of or whatever..) warnings/errors?

Then I fix some of them and type "make" again until they're all gone...


Best regards
Martin Jørgensen

 

[santosh]

Erhm, even better yet: How do I make a/modify my makefile so the program
gets compiled with the highest warning/error-output level every time?

The documentation for your compiler will detail the command line flags
needed to set diagnostics level.

If you're using gcc, type info gcc under Linux or download the docs
available from gcc.gnu.org and read them.

A minimal set of switches is -W -Wall -ansi -pedantic. Richard
Heathfield posted recently a set of switches he uses to get even more
checking and diagnostics. Use Google Groups to search for it.

Once you get the command line right, you can then create your makefile.
To do that, GNU make's docs contain a tutorial.

Basically I just want something where I just type "make" and then I see
all (92 lines of or whatever..) warnings/errors?

Then I fix some of them and type "make" again until they're all gone...

As an alternative a graphical IDE might suit your needs, provided it
supplies options to pass to the compiler.

 

[Flash Gordon]

Erhm, even better yet: How do I make a/modify my makefile so the program
gets compiled with the highest warning/error-output level every time?

Basically I just want something where I just type "make" and then I see
all (92 lines of or whatever..) warnings/errors?

Then I fix some of them and type "make" again until they're all gone...

That depends on your compiler and make system (it would not be the same
for all the systems I use). Ask in a group that deals with your tool set.

 

[Richard Heathfield]

Martin Jørgensen said:

How did you compile (detailed instructions, please)...

I used your makefile (much against my better judgement), but changed:

CFLAGS = $(PROTO_DEFINES) $(STD_DEFINES) -g

to

CFLAGS = $(PROTO_DEFINES) $(STD_DEFINES) -g -W -Wall -ansi -pedantic
-Wformat-nonliteral -Wcast-align -Wpointer-arith -Wbad-function-cast
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Winline
-Wundef -Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-Wno-conversion -ffloat-store -O2

(all on one line, obviously).

 

[Richard Heathfield]

Martin Jørgensen said:

Erhm, even better yet: How do I make a/modify my makefile so the program
gets compiled with the highest warning/error-output level every time?

I have already demonstrated this elsethread.

Basically I just want something where I just type "make" and then I see
all (92 lines of or whatever..) warnings/errors?

Then I fix some of them and type "make" again until they're all gone...

I have a little program called makegen, which generates a makefile on
standard output. The simplest possible usage is:

makegen foo

Its output (which can of course be redirected to a Makefile) is:

CC=gcc
CFLAGS=-W -Wall -ansi -pedantic -Wformat-nonliteral -Wcast-align
-Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Winline -Wundef
-Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-Wno-conversion -ffloat-store -O2
DFLAGS=-g -pg
foo: foo.o
$(CC) $(CFLAGS) $(DFLAGS) -o foo foo.o
foo.o: foo.c
$(CC) $(CFLAGS) $(DFLAGS) -c -o foo.o foo.c

clean:
rm foo.o
rm foo

install:
cp foo /usr/local/bin

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Martin Jørgensen said:




I used your makefile (much against my better judgement), but changed:

CFLAGS = $(PROTO_DEFINES) $(STD_DEFINES) -g

to

CFLAGS = $(PROTO_DEFINES) $(STD_DEFINES) -g -W -Wall -ansi -pedantic
-Wformat-nonliteral -Wcast-align -Wpointer-arith -Wbad-function-cast
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Winline
-Wundef -Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-Wno-conversion -ffloat-store -O2

(all on one line, obviously).

Wow... Thanks a lot... The makefile is probably ugly and the code too,
with all those warnings, but now I have a change to fix them...

That was really helpful. Thanks.


Best regards
Martin Jørgensen

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Martin Jørgensen wrote: -snip-



As an alternative a graphical IDE might suit your needs, provided it
supplies options to pass to the compiler.

Perhaps <OT begin>, but: I already tried some including eclipse which I
didn't like (couldn't watch variable values when I debugged?), DDD and
Anjuta (+ can't remember if I tried kdevelop too).

Anjuta is really nice - the best I've tried so far. I supports "mouse
hovering" over a variable or an expression - that's suberb for me, when
I debug. DDD is also okay (supports a bit lesser "mouse hovering" - not
expressions that span several lines), but I think that at least for some
of these applications I would still need to modify my makefile and now I
have one that works well...

Eclipse wouldn't run without a makefile....

<OT end>


Best regards
Martin Jørgensen

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

That depends on your compiler and make system (it would not be the same
for all the systems I use). Ask in a group that deals with your tool set.

Compiler errors aren't compiler specific or at least they should
cover/warn about a language specific problem so I'll post my *language*
problem here and hope somebody bears over with me, since I'm really not
experienced enough to find this solution myself, even though I've
googled for a solution in an hour:

Many places I use:

"if(something goes wrong)" do: "quit_program(__FILE__, __LINE__);


But:

..//main.c:49: warning: passing argument 1 of 'quit_program' discards
qualifiers from pointer target type

And many other places...

***

check_errors.c:

void quit_program(char *filename, int line)
{
int ch;
printf("\n\nSomething went wrong in line %d of file:\n%s!\n\n",
line, filename);
printf("\nPress <ENTER> to finish the program...\n\n");
fflush(stdout);
getchar();
while( ( ch=getchar() ) != '\n'); /* clear keyboard buffer */
exit( EXIT_FAILURE );
}

check_errors.h:

/* quit_program pauses before exiting the program with an error */
void quit_program(char *filename, int line);

main.h:

void quit_program(char *filename, int line);

***

I read on google that this has something to with constness. So I tried
putting a "const"-keyword before "char *filename" and I tried inserting
a "const"-keyword like this: "char * const filename".

1) "const char *filename"
2) "char * const filename"
3) and then I tried combining both methods... "const char * const filename".

I know that when I'm calling the function with "quit_program(__FILE__,
__LINE__);" then ofcourse it must not try to change (char *) = __FILE__.
This is probably what it's complaining about, but how do I tell it
that whatever filename is pointed to should be const? I thought either
of method 1, 2 or 3 would do the job...

I never really cared of this earlier, because I never got warned about
it before... But it would be nice to learn to do it "the proper way".
Since I have 3 files (2 header files + the .c definition-file) that tell
the compiler these arguments, perhaps that's a problem?


TIA.


Best regards
Martin Jørgensen

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Flash Gordon wrote: -snip-

1) "const char *filename"
2) "char * const filename"
3) and then I tried combining both methods... "const char * const
filename".

Ups, sorry. Found the error... Method 1 it was... But I had quit_program
declared two places in the same header-file so it seems that if there is
only 1 place were the char* argument isn't const, it complains.... :-(

Damn, there are many warnings/errors... I guess I'll stay up long tonight...


Best regards
Martin Jørgensen

 

[Ian Collins]

Ups, sorry. Found the error... Method 1 it was... But I had quit_program
declared two places in the same header-file so it seems that if there is
only 1 place were the char* argument isn't const, it complains.... :-(

Damn, there are many warnings/errors... I guess I'll stay up long
tonight...

To make more mistakes? Not a good idea... One of the best bug fixing
techniques is a good night's sleep.

 

[Eric Sosman]

Martin Jørgensen wrote On 06/01/06 16:44,:

Ups, sorry. Found the error... Method 1 it was... But I had quit_program
declared two places in the same header-file so it seems that if there is
only 1 place were the char* argument isn't const, it complains.... :-(

(Reading up-thread, it seems the compiler complained about
"discards qualifiers from pointer target type" when passing
__FILE__ to a function taking a plain `char*'.)

Changing the function to take a `const char*' is a good
move, but the compiler's original complaint was a bit off the
mark. __FILE__ expands to a character string literal (says
the Standard, in section 6.10.8), and character string literals
produce arrays of plain `char' (6.4.5), not `const char'. The
compiler is permitted to complain about anything it desires,
but this particular complaint is misleading.

... or is it? String literals are arrays of plain `char'
in C, but in C++ they are arrays of `const char' and the
complaint would make sense. gcc is a compiler for several
different languages, C and C++ among them; is it possible that
you are inadvertently trying to compile C source with the C++
mode of gcc? If so, you'd better start by figuring out how
to operate gcc in C mode, lest you run into even more confusion.
(And if you're actually writing C++ rather than C, you're in
the wrong newsgroup: comp.lang.c++ is where the C++ people are.)

 

[Flash Gordon]

Compiler errors aren't compiler specific or at least they should

I've no problem with people posting their compiler errors/warnings
together with the code. What I said was that how to drive your tools to
get them is a question better served in another group. Although others
have pointed you in the right direction in this case.

cover/warn about a language specific problem so I'll post my *language*
problem here and hope somebody bears over with me, since I'm really not
experienced enough to find this solution myself, even though I've
googled for a solution in an hour:

Many places I use:

"if(something goes wrong)" do: "quit_program(__FILE__, __LINE__);

But:

.//main.c:49: warning: passing argument 1 of 'quit_program' discards
qualifiers from pointer target type

And many other places...

***

check_errors.c:

void quit_program(char *filename, int line)

This should probably be
void quit_program(const char *filename, int line)
since you are not going to modify what it points to.

{
int ch;
printf("\n\nSomething went wrong in line %d of file:\n%s!\n\n",
line, filename);
printf("\nPress <ENTER> to finish the program...\n\n");
fflush(stdout);
getchar();
while( ( ch=getchar() ) != '\n'); /* clear keyboard buffer */

With both the while loop and the getchar before it the user can end up
having to press enter twice! Also, since you are only checking for \n
and not for EOF this can turn in to an infinite loop!

exit( EXIT_FAILURE );
}

check_errors.h:

/* quit_program pauses before exiting the program with an error */
void quit_program(char *filename, int line);

main.h:

void quit_program(char *filename, int line);

You should not be putting it in both headers! Just put it in
check_errors.h and include that header in all your .c files where you
use the function.

***

I read on google that this has something to with constness. So I tried
putting a "const"-keyword before "char *filename" and I tried inserting
a "const"-keyword like this: "char * const filename".

1) "const char *filename"

This is saying that the chars being pointed to are const. As is
char const *filename

2) "char * const filename"

This is saying that the pointer itself is const, but the chars it points
to are not and so can be modified.

3) and then I tried combining both methods... "const char * const
filename".

I know that when I'm calling the function with "quit_program(__FILE__,
__LINE__);" then ofcourse it must not try to change (char *) = __FILE__.
This is probably what it's complaining about, but how do I tell it that
whatever filename is pointed to should be const? I thought either of
method 1, 2 or 3 would do the job...

Obviously you have to change both header and source file.

I never really cared of this earlier, because I never got warned about
it before... But it would be nice to learn to do it "the proper way".
Since I have 3 files (2 header files + the .c definition-file) that tell
the compiler these arguments, perhaps that's a problem?

That's too many places, you've probably not kept them all in sync.

 

[Flash Gordon]

Martin Jørgensen wrote On 06/01/06 16:44,:

(Reading up-thread, it seems the compiler complained about
"discards qualifiers from pointer target type" when passing
__FILE__ to a function taking a plain `char*'.)

Changing the function to take a `const char*' is a good
move, but the compiler's original complaint was a bit off the
mark. __FILE__ expands to a character string literal (says
the Standard, in section 6.10.8), and character string literals
produce arrays of plain `char' (6.4.5), not `const char'.
Correct.

> The
compiler is permitted to complain about anything it desires,
but this particular complaint is misleading.

... or is it? String literals are arrays of plain `char'
in C, but in C++ they are arrays of `const char' and the
complaint would make sense. gcc is a compiler for several
different languages, C and C++ among them; is it possible that
you are inadvertently trying to compile C source with the C++
mode of gcc? If so, you'd better start by figuring out how
to operate gcc in C mode, lest you run into even more confusion.
(And if you're actually writing C++ rather than C, you're in
the wrong newsgroup: comp.lang.c++ is where the C++ people are.)

I believe the warning is cause by the compiler switch -Wwrite-strings.
It can be argued that the switch makes the compiler non-conforming
because as you note the standard says string literals are arrays of
char, not arrays of const char. However, it can also be argued that the
compiler is still conforming, since having produced the warning the
compiler still produces code that will work as long as you don't modify
the string literal (attempting to modify it invokes undefined behaviour,
so it doe snot have to work then).

If you write your code using this switch I don't think it is
tremendously hard, but trying to introduce it to some code (badly
written in the case of the specific code I'm think of) can be a lot of work.

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Martin Jørgensen wrote:
-snip-

Then I fix some of them and type "make" again until they're all gone...

Hi,

I think I've got most under control... After I turned up the
compiler/warning setting, I hope I can make a much better program...
Here is the "problem left-overs" (the problems I don't know what to do
about):

1. The line: "sscanf(line, "%s", &argument);" gives:

warning: format %s expects type char * , but argument 3 has type
char (*)[63u]

Definitions: "char line[64], argument[10];"

Is it afraid that sscanf will put more than 10 characters into argument?
What's the solution?


2. The line: "fseek(fp, 0L, SEEK_SET);" gives:

warning: passing argument 1 of fseek discards qualifiers from pointer
target type

fp comes from an argument because the function that uses fseek looks like:

int integer_load_single_value(const FILE *fp,
const char *input_property)
{
// body with fseek
}

Does anything here have to be const? I would assume that wasn't my
problem to define since the prototyping in stdio.h/stdlib.h should write
if any argument were const's...?


3. I have a file called array_functions.c which has:

void int_fillinnumbers(int fillvalue, int startx,
int stopx, int starty,
int stopy, int **array)
{
int i, j; /* local index variables */

for(j=starty; j<=stopy; j++)
{
for(i=startx; i<=stopx; i++)
array[j] = fillvalue; /* integer-fill */
}
}

This function is used different places in the program and is called from
main.c. The problem is:

warning: no previous prototype for int_fillinnumbers

What's it whining about? It don't need another prototype, IMO...


4. I have a #pragma warning because I got some code that does some
nasty/stupid unsigned/signed-tricks so here I would like the compiler to
skip unsigned/signed-checks. But it just writes "ignoring #pragma
warning". Perhaps this is overruled by one of Richard's
-W(...)-arguments to gcc?


The rest of the errors, I'll deal with later (not many left now, when
I've fixed the above 4 "categories")...



Best regards
Martin Jørgensen

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Martin Jørgensen wrote: -snip-



With both the while loop and the getchar before it the user can end up
having to press enter twice! Also, since you are only checking for \n
and not for EOF this can turn in to an infinite loop!

Damn... I must look at that later tomorrow/in the weekend... I better
get some rest soon.

You should not be putting it in both headers! Just put it in
check_errors.h and include that header in all your .c files where you
use the function.

Damn... Ok, nice to know. I also think I tried it at some moment, but
somehow I went away from it (bug perhaps?)

This is saying that the chars being pointed to are const. As is
char const *filename



This is saying that the pointer itself is const, but the chars it points
to are not and so can be modified.

Ok, I never remember the difference.

Obviously you have to change both header and source file.

It's working now...

That's too many places, you've probably not kept them all in sync.

It's okay now, but I better clean it up so I don't have to keep
everything in sync in the future as the program grows bigger and bigger
(now 150 kb - I didn't upload all the code, only the first part until
the "mysterious error" came)...


Best regards
Martin Jørgensen

 

[Richard Heathfield]

Martin Jørgensen said:

1. The line: "sscanf(line, "%s", &argument);" gives:

warning: format %s expects type char * , but argument 3 has type
char (*)[63u]

Definitions: "char line[64], argument[10];"

Is it afraid that sscanf will put more than 10 characters into argument?
What's the solution?

if(sscanf(line, "%9s", argument) == 1)
{

Your spurious & on &argument means you're passing char (*)[10] - a pointer
to an array of 10 char - instead of char *, which is what you get when you
pass the name of an array of char to a function.

2. The line: "fseek(fp, 0L, SEEK_SET);" gives:

warning: passing argument 1 of fseek discards qualifiers from pointer
target type

fp comes from an argument because the function that uses fseek looks like:

int integer_load_single_value(const FILE *fp,

Drop the const from fp. The fseek function needs to be able to modify the
file position indicator member of the object pointed to by fp.

3. I have a file called array_functions.c which has:

void int_fillinnumbers(int fillvalue, int startx,
int stopx, int starty,
int stopy, int **array)
{
int i, j; /* local index variables */

for(j=starty; j<=stopy; j++)
{
for(i=startx; i<=stopx; i++)
array[j] = fillvalue; /* integer-fill */
}
}

This function is used different places in the program and is called from
main.c. The problem is:

warning: no previous prototype for int_fillinnumbers

What's it whining about? It don't need another prototype, IMO...

If the function is called only from within the translation unit in which it
is defined, and is called only /after/ the function definition, then you
can ignore the warning. Otherwise, but this:

void int_fillinnumbers(int fillvalue, int startx,
int stopx, int starty,
int stopy, int **array);

in a header, and #include that header in all translation units that contain
calls to the function. It is also wise to #include it in the translation
unit where the function is defined, as this will catch any mods that are
done to the definition which have not been reflected in the header.

4. I have a #pragma warning because I got some code that does some
nasty/stupid unsigned/signed-tricks so here I would like the compiler to
skip unsigned/signed-checks. But it just writes "ignoring #pragma
warning".

#pragmas are, by definition, non-portable (with one trivial C99 exception
which I'll ignore as irrelevant on this occasion).

The fix here is: don't use nasty/stupid unsigned/signed-tricks!