Conference turris::digital_unix

    The reason you are seeing a different behavior comparing the results of
    
    	cc -o provanull provanull.c
    
    between 3.2x and 4.0x is the fact that you are actually using two
    different compilers, 'man cc' on the 4.0 system will tell you. Try
    a 'cc -migrate ...' on your 3.2 system and see what happens.
    De-referencing an uninitialized pointer is a bad idea in any case.
    
    	Martin    

    ... and it's got nothing to do with the fact that you are using a
    pointer. Try what you did with a much simpler program like:
    
    #include <stdio.h>
    main()
    {
        int local_var;
    
        printf("local_var: %d\n", local_var);
    
    }
    
    and you'll find that the 3.2 default compiler initialized local
    variables with '0' (a behavior you should NOT rely on). So on 3.2
    the program will print a '0' whereas with the new compiler you just get
    some random number (e.g. 536869800 when I tried this).
    
    	Martin

>    This different behaviour broke a customer application.

No, the customer's application was always broken.  They should
be glad to learn about it (but they're probably not).

I don't think the old C compiler always initialized local variables
to 0.  Try this program:

#include <stdio.h>
foo()
{
  int var;
  printf("in foo, var = %d\n", var);
  var++;
}

main()
{
  foo();
  foo();
}

At least with "cc -oldc" on V4, it prints nonzero data for both calls.

C never guaranteed that it would initialize "automatic variables".  ANSI C
went on to say that program behavior is undefined if a variable that has
an auto storage class is used before it is initialized.

	-- Farrell

[Posted by WWW Notes gateway]

	On V3.2 the customer should try using -trapuv (trap un-initialized
	variable).  This will cause the compiler to cause stack variables
	to be initialized with values that will hopefully cause an
	access violation for pointers and hopefully obvious mis-behaviour
	when other variables are used.

"If you lie to the compiler, it will take its revenge."
     --Henry Spencer

The first thing I usually try in cases like this where we see strange behavior
at runtime is lint. Lint pointed out the problem right away. Below is what I see
with a slightly cleaned up version of the basenote example:

% lint t.c
"t.c", line 6: warning: pippo may be used before set

The DEC C compiler ("cc" on V4.0 and later, "cc -migrate" on V3.2) will also
point out this problem in -check mode.

% cc -check t.c
cc: Info: t.c, line 6: variable pippo is fetched, not initialized
  if (pippo != NULL)
------^

See also Henry Spencer's Ten Commandments for C Programmers at
  http://lglwww.epfl.ch/~wolf/c/ten_commandments.html

-Jeff

The reason this failure "shows up" in V4.* but not in V3.* has nothing
to do with the compilers but with the changes that occured with crt0
in V4.0.  Crt0, which is executed before the main() in your program,
had some new functionality added to it in V4.0.  As a result, the
stackframe for main() in V4.0 will definitely contain garbage in it
whereas the V3.* main() stackframes only "might" have contained garbage.