pete@violet.berkeley.edu (02/07/88)
In a recent posting, David Roch [roch@b.uiuc.edu] asked: > While looking through the include files for Lattice 4.0, I noticed > that getenv is defined in stdlib.h. Curious, I tried accessing > the environment variables set by assign, both with and without > the colon, but in each case the null string was returned. > > [...sample program omitted...] > > The map file shows that getenv is 0x328 bytes. Can anyone tell > me what's going on? > thanks, > david roch > roch@b.uiuc.edu OK -- you got me curious, so I did some code disassembly... You're right [strangely...!] in that getenv searches the Device List for names. However, what's returned is NOT another character string (despite the prototype in stdlib.h!), but the ADDRESS of the relevant DevInfo block. (It can be any device -- not just assigned ones.) Try feeding this little test program some device names (no colons): /* stalking the phantom environment */ #include <stdio.h> #include <stdlib.h> void main(argc,argv) char **argv; { APTR v; while (--argc) { v = getenv(*++argv); printf("%s = %x\n", *argv, v); } } I wonder what Lattice intends this for? You can of course use it just to test if a device is "mounted" (just like Bryce and others have done). Why use the name "getenv" though? ...Not exactly ANSI compatible! -- Pete G. --
toebes@sas.UUCP (John Toebes) (02/17/88)
In article <6893@agate.BERKELEY.EDU>, pete@violet.berkeley.edu writes: > In a recent posting, David Roch [roch@b.uiuc.edu] asked: > > While looking through the include files for Lattice 4.0, I noticed > > that getenv is defined in stdlib.h. Curious, I tried accessing > > the environment variables set by assign, both with and without > > the colon, but in each case the null string was returned. > OK -- you got me curious, so I did some code disassembly... > You're right [strangely...!] in that getenv searches the Device List for > names. However, what's returned is NOT another character string (despite > the prototype in stdlib.h!), but the ADDRESS of the relevant DevInfo block. > (It can be any device -- not just assigned ones.) > > I wonder what Lattice intends this for? You can of course use it just > to test if a device is "mounted" (just like Bryce and others have done). > Why use the name "getenv" though? ...Not exactly ANSI compatible! Actually it is quite ANSI compatible (in a sense). To quote the standard: Description the getenv function searches an environment list, provided by the host environment, for a string that matches the string pointed to by name. The set of environment names and the method for altering the environment list are implementation-defined. Returns The getenv function returns a pointer to a string associated with the matched list member. The array pointed to shall not be modified by the program, but may be overwritten by a subsequent call to the getenv function. If the specified name cannot be fount, a null pointer is returned. Since the description requires the environment list to be provided by the host environment and we wish to follow the Amiga standards, the appropriate place to get the information is from the list of assigns. When an alternative to this is provided by Commodore as a standard defined interface we would certainly look toward that. However since this is what is to be done, we must return an indicator of whether or not the item exists. Note that ANSI imposes no restrictions on the format of the information returned. You have the ability to cast the pointer to a DevInfo structure and get additional information out of the return value. It's best use is for testing whether something is mounted, but there are other possibilities. (Testing for the presence of a configuration file by name). /*---------------------All standard Disclaimers apply---------------------*/ /*----Working for but not officially representing SAS or Lattice Inc.-----*/ /*----John A. Toebes, VIII usenet:...!mcnc!rti!sas!toebes-----*/ /*------------------------------------------------------------------------*/
peter@nuchat.UUCP (Peter da Silva) (02/21/88)
> [Explanation of why Lattice "getenv" searches the assign list, based on > loose terminology in the ANSI draft standard] If you notice, it does say that getenv returns a *string*, which to me implies a null terminated sequence of characters. Besides, there's more to writing a good 'C' library than just following ANSI. The semantics of getenv should be the same as the semantics of the UNIX getenv function. This is what any portable programs will be looking for, and that after all is the purpose of ANSI 'C'. Getenv variables don't have to be local but shared by child processes, as the UNIX ones are. Making them global as Manx does is OK... however they should be names that the user can assign arbitrary character strings to befoire running your program. If you don't like Manx's method of hiding them, you could always store them in RAM:ENVIRON or something. It'd be better to maintain compatibility on that level, since it's become a bit of a standard (well, the ARP people seem to like it). Suggestion for C=: come up with formal support for environment variables in some future version of the Amiga O/S. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.