Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.wizards
Subject: Re: of course!
Message-ID: <1989Nov22.224209.28911@athena.mit.edu>
Date: 22 Nov 89 22:42:09 GMT
References: <152@norsat.UUCP> <2586@unisoft.UUCP> <15769@bloom-beacon.MIT.EDU> <17264@rpp386.cactus.org> <4526@ski.cs.vu.nl> <17303@rpp386.cactus.org> <1051@root44.co.uk>
Sender: news@athena.mit.edu (News system)
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 61

In article <1051@root44.co.uk> gwc@root.co.uk (Geoff Clare) writes:
=>>	isadir(char *path)
=>>	{
=>>		char dir[PATH_MAX];
=>>
=>>		strcpy(dir, path);
=>>		strcat(dir, "/.");
=>>
=>>		return access(dir, 0);
=>>	}
=The fact that the strcat() may write past the end of dir[] is more of
=a problem.

  Yes, this is definitely a problem.  There should be a check on the
length of path before strcat'ing onto the end of it.

=            Another is that PATH_MAX might not be defined (it should
=always be obtained via pathconf() in portable applications).

  Not convinced this is a major problem.  I've yet to run into a Unix
programming environment that doesn't somewhere in a header file give
you some indication of the maximum path length, although that may be
just my limit Unix experience talking.  I also don't know about
non-Unix C libraries....

=                                                              Anyway,
=using a maximum length array is rather wasteful - malloc(strlen(path)+3)
=would be much better all round.

  This, I must completely disagree with.

  An automatic variable of a procedure is placed on the stack (with
the rest of the procedure's stack frame) when the procedure is called,
and is removed from the stack when the procedure exits.  Unless the
program is using *lots* of memory and stack space, there is very
little likelihood of overflowing the stack.  Furthermore, all of this
allocation is done down at the machine instruction level, not up in
user-written code.

  Malloc, on the other hand, is user code,  It allocates memory that
is part of the data area of the program, and it takes more time than a
procedure call would take to do this *because* it is user code.
Furthermore, if the program's data area isn't big enough to hold the
malloc'd memory, malloc has to increase the datasize, and the data
size will NOT decrease, even after free has been called on the string.
Furthermore, a malloc is far more likely (in my experience) to cause a
program to run out of memory than a procedure call is.

  Therefore, malloc is slower than just putting it in an automatic
variable, it is more likely to cause the program to run out of memory,
and it might even cause the program's data size to grow unnecessarily.

  I therefore fail to see why malloc is a better choice than an
automatic variable.

  Then again, perhaps I'm just confused :-)

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710