DragonFly BSD
DragonFly users List (threaded) for 2006-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: [OT] C pointers: BSD versus Linux?


From: Erik Wikström <erik-wikstrom@xxxxxxxxx>
Date: Thu, 01 Jun 2006 18:46:42 +0200

On 2006-06-01 17:21, walt wrote:
Simon 'corecode' Schubert wrote:
On 31.05.2006, at 20:37, jwatson@xxxxxxxxxxxx wrote:
Style 1:
time_t t*;
time(t);
[...]

Also, style 1 is technically "incorrect" since you never allocated the
memory that t is pointing to before passing it into time().

maybe the compiler on BSD by chance put NULL into "t" and thus made it a
valid parameter?

First, thanks to all who replied! I've been playing with gdb and I'm seeing a significant difference between linux and *BSD.

I added a dummy variable to my program, like this:
time_t t*, d;
and then ran the program in gdb.  I printed out t and &d and
compared the two values under *BSD and linux.

What I see in linux is that the two values are miles apart,
but in *BSD they differ by only a few bytes.  I *assume* this
means that in *BSD, t is pointing to a valid memory location
very close to d, whereas in linux t is pointing to some
random number.  Does this seem a reasonable idea?

In general when dealing with uninitialized variables any value is "reasonable" since there's no guarantee what their value will be. Thus you shall never write an application that depends on the behavior of uninitialized variables since this behavior can change between different architectures, compilers and OS'es.


In this case the fact that t points to an address near d does not make that address valid, since d is allocated on the stack and the only valid addresses for t to point to would be a variable on the stack or some allocaed area on the heap

Erik Wikström
--
 "I have always wished for my computer to be as easy to use as my
 telephone; my wish has come true because I can no longer figure
 out how to use my telephone" -- Bjarne Stroustrup



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]