Re: gcc compiler

From: Arthur J. O'Dwyer (ajo_at_nospam.andrew.cmu.edu)
Date: 07/09/04 

Date: Fri, 9 Jul 2004 09:56:06 -0400 (EDT)

On Fri, 9 Jul 2004, An wrote:
>
> I'm new to C and now I encountered the following problem.
> When I compile the program hulp.c (the code is below) with the command
> gcc -O -o hulp hulp.c,
> running the program with input 1 2 3 4 1 2 3 4 1 2 3 4 1 2
> gives output
> 12341234123412
> 00041234123412.
> I don't understand how it is possible that the value of
> macht[0],macht[1]and macht[2] don't remain 1 2 3.

  You are overwriting them with zeroes, that's why. See below.

<snip>
> How is this possible? What is the influence of the -O in the compiler
> command? In the manual I read this has to do with optimization, but
> what does it do here?

  It optimizes. Since your code was wrong to begin with, *any*
optimization is correct. So it makes some optimizations that change
the behavior of your program from wrong to wrong --- not a problem!
Write correct code, and suddenly the optimizer has a lot less leeway. :)

> #include <stdio.h>
>
> main()

  int main(void) is preferred, and will work in C99 (the most recent
standardization).

> {FILE *fp;
> short i;
> char inleeslg;
> char macht[14];
> long pbas;
> char e;
>
> fp=fopen("Factortest","r");
> if ((fp=fopen("Factortest","r"))==NULL) printf("Kan datafile niet
> openen \n");

  Double whoops! First, you open the "Factortest" file *twice* here;
that's unwise, although I don't think it's a bug, strictly speaking.
The second problem is that your string literal overruns its line. Strings
in C can't span lines. Use a narrower margin for C code if necessary.

    if (fp == NULL) printf("Kan datafile niet openen!\n");

> else{
> printf("Type 14 small numbers:\n");
> for(i=0;i<14;i++)
> {scanf("%d",&macht[i]);

  Here is a bug. 'macht' is an array of char, not int. "%d" is the
format specifier for int. You mean something like

    {
        int tmp;
        scanf("%d", &tmp);
        macht[i] = tmp; /* with optional error-checking */

> }
> /*Printing the input */
> for(i=0;i<14;i++)
> {printf("%d",macht[i]);
> }
> printf("\n");
>
> fscanf(fp,"%d %d %d",&pbas,&e,&inleeslg);

  Here is another bug. 'pbas' is a long int. 'e' and 'inleeslg' are
chars. None of them are ints, which is what fscanf("%d") is expecting.
The correct format specifier for 'long int' is "%ld"; the two chars
can be read in using the temporary-variable solution I gave you above.

> /*Printing the input again */
> for(i=0;i<14;i++)
> {printf("%d",macht[i]);

  Note that this is *not* a bug, since while 'macht[i]' is a char,
it is passed as an int to 'printf'. However, learning when it is
safe to rely on the integer promotions is a tricky business.

> }
> printf("\n");
> }
> fclose(fp);

And last but not least,

    return 0;

> }

Relevant Pages

  • LD_PRELOAD odd woes
    ... which I do not have the source code that generates useful information ... static int dyn = 0; ... fopen(const char *path, const char *mode) { ... If I compile this like this: ...
    (comp.os.linux.development.system)
  • Problem using string/vector in MS Visual C++ 6/g++
    ... int main(int argc, char* argv){ ... I tried to compile the second code in UNIX again... ...
    (comp.lang.cpp)
  • Re: How to undef a typedef??
    ... typedef int Man; ... typedef char Man; ... Absolutely, positively, for sure you did not compile this with a C ... Since sizeof char is defined as "1", ...
    (comp.lang.c)
  • Re: gcc compiler
    ... > It gets even more mysterious to me, since when I compile things using ... > input as above BOTH compilers give the expected output: ... > char inleeslg; ... "%d" expects the address of an int. ...
    (comp.lang.c)
  • Re: Hash tables
    ... optimization; with optimization, the relative times are about the ... int main(int argc, char *argv) { ...
    (comp.programming)