juancho@dgp.toronto.edu (John Buchanan) (02/23/88)
I have three questions that people out there might have
answers to.
1) I just finished porting a 12K line program from our unix
system to a 1040 using MWC 2.1.7. The system() calls simply print
no shell when the program is running under gulam. I know that
setting the SHELL environment variable to GULAM will fix that. The
problem is that other mark william tools seem to be able to run
shell commands with out the SHELL variable being set, and if the
environment variable is set then a new copy of the shell is started up
for each cc in a make.
2) How does a typical mwc tool know that it has been called
from a shell. When ever I use a tool it seems to assume that the
program was run from the desktop and I have to press return.
3) How reliable are the malloc() and free() functions
provided with MWC.
--
John W. Buchanan Dynamic Graphics Project
Computer Systems Research Institute
University of Toronto
(416) 978-6619 Toronto, Ontario M5S 1A4sid@brambo.UUCP (Sid Van den Heede) (03/03/88)
In article <1988Feb22.221218.13780@jarvis.csri.toronto.edu> juancho@dgp.toronto.edu (John Buchanan) writes: > > 3) How reliable are the malloc() and free() functions >provided with MWC. I have had no problems with the MWC routines themselves. But I have run out of memory (according to malloc()) while there was still plenty of memory left (prox 1/4Mb according to malloc(-1) or Malloc(-1)...it's been a while and I don't have my documentation here). This is due to the problem with the memory allocation scheme in TOS. When malloc() is called, it calls Malloc to get a chunk of memory, from which it doles out the amount you requested. Subsequent malloc() calls give you more of the memory left from the previous Malloc or calls Malloc again as appropriate. After a small number of Malloc calls (20, 40?) you don't get any more. -- Sid Van den Heede Voice: 416-792-1137 sid@brambo.UUCP FAX: 416-792-1536 ...!utgpu!telly!brambo!sid Bramalea Software, Suite 406, 44 Peel Centre Dr, Brampton, Ontario L6T 4B5
wes@obie.UUCP (Barnacle Wes) (03/03/88)
In article <1988Feb22.221218.13780@jarvis.csri.toronto.edu>, juancho@dgp.toronto.edu (John Buchanan) writes: > > I have three questions that people out there might have > answers to. > > 1) [....] The > problem is that other mark william tools seem to be able to run > shell commands with out the SHELL variable being set, and if the > environment variable is set then a new copy of the shell is started up > for each cc in a make. I can't say for sure, but I think the tools are probably exec'ing the programs they call directly, rather than using system(). MWC provides two library functions to make this somewhat easier, look up access() and path() in the Lexicon. > 2) How does a typical mwc tool know that it has been called > from a shell. When ever I use a tool it seems to assume that the > program was run from the desktop and I have to press return. I think there is an environment variable called CAMEFROM they are checking. Usual entries are desktop and msh, or something like that. The tools probably assume the worst (desktop) if they don't see anything. > 3) How reliable are the malloc() and free() functions > provided with MWC. I haven't had any problems with them in 2.1.7, but I am (now) very careful to free() objects in the reverse order I malloc() them. As it turns out, this isn't that much of a limitation - I (NOW) always free blocks in the same routine that malloc()'s them. I've been stung by other compilers on other systems when I didn't do this. -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes
sid@brambo.UUCP (Sid Van den Heede) (03/24/88)
In article <80@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >...MWC provides >two library functions to make this somewhat easier, look up access() >and path() in the Lexicon. >... So where in the Lexicon would one find these entries? They're not in my version 1.0.4 nor in my version 2.0 manuals. Where are they in yours? -- Sid Van den Heede Voice: 416-792-1137 sid@brambo.UUCP FAX: 416-792-1536 ...!utgpu!telly!brambo!sid Bramalea Software, Suite 406, 44 Peel Centre Dr, Brampton, Ontario L6T 4B5
dag@chinet.UUCP (Daniel A. Glasser) (03/26/88)
The documentation for these two routines was omitted from the first few
revisons of the MWC manual. They were included in the manual (revison 4)
that was shipped with version 2.1.7. With several products on the market
and several more in development, sometimes these things slip past overworked
tech writers... (and those who review the manual drafts)
access -- unix standard library function (libc)
Check to see if a file can be accessed in a given mode
#include <access.h>
int access(filename, mode) char *filename; int mode;
access check whether a file can be accessed in the mode you wish.
filename is the full path name of the file you wish to check.
mode is the mode in which you wish to access file filename, as
follows:
value define access
1 AEXEC execute
2 AWRITE write/append
4 AREAD read
The defined values are set up by the header, access.h.
access returns zero if filename can be accessed in the requested mode,
non-zero if not.
<example omitted>
path -- Coherent library function (libc)
find a file in directories specified in a path list
#include <stdio.h>
#include <path.h>
char *path(pathlst, filename, mode) char *pathlst, *filename; int mode;
path is a general function that finds a file along a path.
pathlst points to a null terminated string containing the names
of the directories to be searched for filename, in search order,
separated by commas. filename points to a null terminated string
containing the name of the file (including extension) for the
search, and mode is the mode of access desired, as used in the
libc function access. path searches each directory in pathlst
until a file with name filename that can be accessed for the
desired mode is found or the end of the list is reached.
If the file is found, path returns a pointer to a static internal
buffer that contains the pathname that the file can be opened as.
This buffer is overwritten by subsequent calls to path.
If the file is not found, path returns NULL.
The header file path.h includes default paths for lookup of
binary (programs) and library (programs, data, objects, etc.)
files, defined as DEFPATH and DEFLIBPATH, respectively.
(these correspond to the PATH and LIBPATH environment variables
used in MSH.)
example:
/*
* Search along PATH (or a default) for each of the files on the command
* line. Prints out the first occurrence of each file to which you have
* execute access that is found, or a message that says it is not found
* if it can't find it.
*
* This is not the example for path() from the Mark Williams C manual,
* similar, but not the same.
*/
#include <stdio.h>
#include <path.h>
extern char *path();
extern char *getenv();
main(argc, argv)
int argc;
char *argv[];
{
char *fullpath, *pathspec;
int i;
/* We are going to look up our files along PATH, from the env. */
if ((pathspec = getenv("PATH")) == NULL)
pathspec = DEFPATH; /* If none in the env, use default */
/* Loop through all the files... */
for (i = 1; i < argc; ++i)
if ((fullpath = path(pathspec, argv[i], 1)) == NULL)
printf("%s not found along path %s\n",
argv[i], pathspec);
else
printf("%s found as %s\n", argv[i], fullpath);
exit(0);
}
Note that the above example program was written out of my head. I used
the MWC manual for the text, though I paraphrased a bit, but the example
is new and I have not tested this program. I believe it should work.
--
Daniel A. Glasser dag@chinet.UUCP
One of those things that goes "BUMP!!! (ouch!)" in the night.
...!att-ih!chinet!dag | ...!ihnp4!mwc!dag | ...!ihnp4!mwc!gorgon!dag