On Fri, 12 May 2006 12:51, Steve Wampler wrote: > > FPATH is used in Unicon (probably also Icon, I've forgotten, and I can't > find a reference to it in the chess book...) to establish a path of > directories to search for loadable C functions.
In a fit of idle curiosity, I've been browsing the source of Icon 9.4.2 and Unicon 11.1beta, and make the following observations: 1) The code in Icon 9.4.2 uses a fixed length char[1000] buffer, so it's vaguely vulnerable to a buffer overrun. The Unicon uses a malloc'd buffer to prevent the overrun, but otherwise all following comments apply to both. 2) The code appends the bin directory of the current iconx. I see no attempt to check if the directory is already in the FPATH, so in the case of nested calls of *icon programs, FPATH will tend to grow without bound. 3) A space character is used as the separator between components, whereas ksh and other shells use : as the separator. Therefore if a *icon program calls a shell script which relies on the contents of FPATH, the last component of FPATH will be ruined as far as the shell script is concerned. 4) most concerning of all, and perhaps the source of the problem: The (SuSE Linux 10) man page for putenv(3) says: /QUOTE The libc4 and libc5 and glibc 2.1.2 versions conform to SUSv2: the pointer string given to putenv() is used. In particular, this string becomes part of the environment; changing it later will change the environment. (Thus, it is an error is to call putenv() with an automatic variable as the argument, then return from the calling function while string is still part of the environment.) However, glibc 2.0-2.1.1 differs: a copy of the string is used. On the one hand this causes a memory leak, and on the other hand it violates SUSv2. This has been fixed in glibc2.1.2. The 4.4BSD version, like glibc 2.0, uses a copy. /END QUOTE So it seems, at least on Linux and probably other platforms, the use of an automatic variable in Icon or a malloc'd and free'd string in Unicon causes the variable to completely disappear. I'm surprised we're not getting nasty core dumps. Then again, perhaps if there's any outstanding hard-to-find crashes with unknown cause, maybe this putenv and others in the source are the culprit. ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
