Slackware 12.1 GCC Problems

acheong87 · 07-30-2008, 03:33 AM

Hi, I just installed Slackware 12.1, accepting all defaults. I compiled a few C programs using GCC, and I'm getting very weird results.

One program, at the end of its run, should simply output the result of a basic "strcmp()". Compiled with gcc in Ubuntu, I get "0", as expected. Compiled with gcc in Slackware, I get "49". Another program, at the end of its run, should simply output a string. Compiled with gcc in Ubuntu, I get the expected string. Compiled with gcc in Slackware, I get an infinite loop printing the string.

What's going on? I understand that there are different headers and code libraries, but I'm not doing anything sophisticated here! Just a bunch of bit-wise and boolean operations. I'm only using "stdio.h".

Thanks in advance!

Alien Bob · 07-30-2008, 05:16 AM

If you post your code and the makefile, I could check if this is any different on older Slackwares (or on Slackware 12.1 using gcc3 instead of gcc4)

Eric

acheong87 · 07-30-2008, 12:52 PM

Quote:

Originally Posted by Alien Bob

If you post your code and the makefile, I could check if this is any different on older Slackwares (or on Slackware 12.1 using gcc3 instead of gcc4)

Eric

I don't have a makefile; each program is just a single C file, and I simple run "gcc *.c" followed by "./a.out". The programs are actually quite hefty because of a hard-coded 569610-digit binary string. I uploaded them to my server: http://www.thecheong.com/tmp_crypt/. Thanks a lot for offering this help!

I didn't think the language C would change so much between versions.

Alien Bob · 07-30-2008, 01:23 PM

The language did not change. The compiler changes.
This is on my old Slackware 10.0 box using gcc.3:

Code:

eha@door:/tmp$ gcc test-0.1.c 
eha@door:/tmp$ ./a.out 
0
eha@door:/tmp$ gcc test-0.2.c 
eha@door:/tmp$ ./a.out 
110110010000011110001001010100000000000000000000000000000110110101101011100001000101110110
110110010000011110001001010100000000000000000000000000000110110101101011100001000101110110
0

eha@door:/tmp$ gcc --version
gcc (GCC) 3.3.4

While on Slackware 12.0 the first binary returns '1' and the second one outputs 3 lines. Below are the last bits of the first line, and all of the second and third:

Code:

...01100111010110101010111000100100010111100011100101101110111011011100001000101011011101o
110110010000011110001001010100000000000000000000000000000110110101101011100001000101110110
1
eha@icculus:~/downloads$ ./a.out |wc -l
3
eha@icculus:~/downloads$ ./a.out |wc -c
1139405

eha@icculus:~/downloads$ gcc --version
gcc (GCC) 4.1.2

Note that there is a 'o' not a zero at the end of the first line!

Eric

acheong87 · 07-30-2008, 01:28 PM

I see. However, I thought the compiler, in a way, defined the language. When I say "The sky is blue and the grass is green," and I'm using English, I wouldn't expect the meaning to change over time. I guess I have a lot to learn about compilers and languages. Anyway, do you think the problem could also be caused by different versions of header files?

Thanks for your help! For others' reference, what versions of GCC I was using.

Alien Bob · 07-30-2008, 01:36 PM

The language remains the same - C has an unchanging language definition. But the libraries and headers that come with glibc and friends, do change.
I have no idea what exactly changed to make your program behave differently between gcc3 and gcc4 but I am sure you are going to find out :-)

Eric

mostlyharmless · 07-31-2008, 04:24 PM

I've had some code that gave different results with different compilers - it can be a hard bug to find. As I recall (it was a long time ago) the same iterative loop was handled differently in each compiler - erroneously by one, correctly by the other. It was a very simple loop, nothing complicated. Had to rewrite the loop to a different form, and later found out it was a compiler bug in that particular version of that particular compiler.

Names of compliers and versions have been forgotten to protect the guilty.

acheong87 · 07-31-2008, 08:18 PM

Both versions are 4.2.3! I'm not sure what the problem is...

Are there sub-versions within 4.2.3? What else can I check?

bgeddy · 07-31-2008, 09:46 PM

Sorry but the bugs are in the C code - not the compiler. In both programs the array Decrypted is treated as a string - in test-0.1.c by passing it as a parameter to strcmp here:

Code:

printf("%i\n",strcmp(Decrypted,"110110010000011110001001010100000000000000000000000000000110110101101011100001000101110110"));

and in test-0.2.c by also passing it as a parameter to printf here :

Code:

printf("%s\n", Decrypted);

The C language and it's libraries expect character strings to be terminated by a null byte - in effect the null byte is used to mark the end of the string. Allocating a quoted string such as "This is a string" automatically appends 0x00 to the end of the string behind the scenes. You are not specifically doing this in the code with the array Decrypt and so bugs will occur. This is effectively causing a buffer overflow bug. I have made modifications to the two code files here which should make the program run the same under both versions. I have only posted the relevant parts that I have changed at the end. NB both programs should be changed to declare Decrypt as char Decrypt[91] not char Decrypt[90] to save stomping over memory when appending the null byte:

test-0.1.c:-

Code:

	/* change - null terminate char string */
	Decrypted[90]=0x00;
	/* end change	*/
	printf("%i\n", strcmp(Decrypted,"110110010000011110001001010100000000000000000000000000000110110101101011100001000101110110"));

}

test-0.2.c:-

Code:

	/* null terminate char string  change	*/
	Decrypted[90]=0x00;
       /* change end */
	printf("%s\n", Decrypted);
	printf("110110010000011110001001010100000000000000000000000000000110110101101011100001000101110110\n");
	printf("%i\n", strcmp(Decrypted,"110110010000011110001001010100000000000000000000000000000110110101101011100001000101110110"));

}

The fact that you say it worked with Ubuntu is probably just down to the way memory allocation was done.

Note that these fixes are quick hacks as hard coding string terminating nulls is not elegant or safe.

acheong87 · 08-01-2008, 10:12 AM

Ohh, I see, thank you very much for your insight! You don't need to rewrite my code or get too specific but... what would be the correct way of doing this?

bgeddy · 08-01-2008, 11:08 AM

Being a Slackware forum it's not the place to go into C programming semantics but rather than rewrite anything I will give you some quick pointers to look into and hope members will be tolerant. A good idea is to avoid error prone areas in coding.

Hard coding constants is error prone so when declaring and initializing character strings it's safer to let the compiler decide the size as in : char mystring[]="This is a string"; the size may be returned, if needed later, with strlen(). Some declarations/definitions are best kept in their own separate header files. Be aware of the basic difference between the memory functions (the mem* group) and the string functions (the str* group) when comparing and moving data around and look into the length limited strn* functions. Be aware of the functionality the standard libraries offer which will save you tons of coding and eliminate looping constructs. Check out a good book to fully understand these concepts - oh and become familiar with pointers. The original K & R volume is indispensable.

Anyways - I've probably already strayed to far from this forums subject matter. Good luck and keep at it ! The C language is both terse and elegant and will give you a good grounding in how the underlying hardware works.