FW: Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API

FW: Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API

[Dave Korn]

On 02 May 2006 16:57, Christopher Faylor wrote:

> On Tue, May 02, 2006 at 03:32:44PM +0100, Dave Korn wrote:
>> On 02 May 2006 15:18, Kaveh Goudarzi wrote:

>>> Also I noticed that the address of environ seems always to be at
>>> 0x460090 ...  is it safe to assume this to always be the case?
>> 
>> No, absolutely not.
> 
> What he said.  It's hard to believe that question would even be
> seriously asked.
> 
> cgf


  WTF is going on in the world of computer programming?  We appear to be going
backwards.  When I first began coding on 8-bit single tasking micros, with
rom-kernels, you could rely on the memory map being constant and everything
being in the same place all the time.  But that was already invalid on big
iron and *nix boxen and when I moved up to 16-bit coding (Amiga mostly) the
very first thing that was hammered into us with a big hammer was "Don't
hardcode addresses - the memory map changes all the time and you might get
loaded anywhere and your stack might be anywhere else and malloc will often
return different values!  You don't own the whole system any more and you have
to play nice!  Allocate everything and get a pointer to it and lookup stuff
that can be lookedup every time!  Free every resource you use so you don't
starve the system!"

  Now everyone seems to have been thoroughly spoilt by MMUs, and assume that
leaking memory and file handles is unimportant ("Oh, they'll all be cleaned up
when the process exits won't they?"), and that the memory layout will be the
same every single time.  Gah.  Even GCC dumps out huge chunks of memory full
of internal data structures and pointers (precompiled header support) and
expects to just be able to load it back in at the same address.

  Has everyone just forgotten everything we learned in the last few decades
about resource management, position-independence and serialisation?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....