Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!iuvax!iucs!bobmon
From: bobmon@iucs.UUCP (RAMontante [condition that I not be identified])
Newsgroups: comp.sys.ibm.pc
Subject: Re: MSC spawn() problem
Message-ID: <4764@iucs.UUCP>
Date: Sat, 5-Dec-87 17:09:15 EST
Article-I.D.: iucs.4764
Posted: Sat Dec  5 17:09:15 1987
Date-Received: Thu, 10-Dec-87 20:01:47 EST
References: <149000015@inmet> <474@silver.bacs.indiana.edu>
Reply-To: bobmon@iucs.UUCP (RAMontante [condition that I not be identified])
Organization: Indiana University, Bloomington
Lines: 26

creps@silver.UUCP (Steve Creps) writes:
>In article <149000015@inmet> ronw@inmet.UUCP writes:
>>
>>I believe that the Microsoft C Compiler has problems with environment
>>space when spawn-like library functions are used.  Consider the following
>(deleted)
>
>>examine the environment variables with the SET command they appear fine
>>except there is a little string of garbage at the end of the list that
>>always contains the string ";C_FILE_INFO".  To make matters worse, if you
>>attempt to use SET to change old variables or create new ones, they are
>>placed at the end of the list (after the garbage).  When this happens,
>
>   I don't think it's a bug; I think it's a feature, a feature of MS-DOS.
>When you spawn a new shell in DOS it should return the environment the same

Unless I'm overlooking a smiley here, I have to disagree.  When I spawn a
subshell out of Procomm I get the offending garbage at the end of the
environment space -- and Procomm contains a Microsoft copyright statement.
When I spawn a subshell out of microEmacs, which I compiled with Turbo C,
I have a nice clean environment.

Checking quickly here, I see that the garbage string is 19 (visible) characters
long.  I guess I could believe that Microsoft intentionally uses 19+ bytes
of garbage to mark the end of a block of storage... :-)
Can anyone comment on microEmacs' behavior under other compilers?