File and directory primitives are severely broken
John M McIntosh
johnmci at smalltalkconsulting.com
Tue Apr 25 17:06:36 UTC 2006
mmm as part of this issues, I had suggested to Stef that someone
needed to sit down (any takers) and document all the basic VM api
calls that rely on host operating system support. Plus of course
explore what to do about unsafe calls that have buffer overflow
Given that he was willing to find someone to help write a set of
SUnits that test these interface points.
On 24-Apr-06, at 3:06 PM, Ian Piumarta wrote:
> Many of the file primitives allocate 1000-byte buffers for path
> names and pass their address to functions defined in support code,
> without passing their length or in any way trying to agree with
> support code about what the maximum length of a path name should
> be. Directory primitives are worse: in one place a 256-byte buffer
> is allocated on the stack and expected to be sufficient for any
> directory entry.
> Here's the portable way to fix this without changing any of the APIs.
> I suggest everyone who maintains a platform check that they do
> indeed have <limits.h> (its availability is mandated by ANSI C) and
> once nobody reports it missing that this header file be included at
> the beginning of sq.h. All occurrences of
> char buf;
> char entryName;
> that allocate space for path names in the file and directory prims
> should then be changed to read
> char buf[PATH_MAX];
> before one of these ticking time bombs explodes in someone's face.
> FWIW: The Unix VM uses PATH_MAX religiously when checking for over-
> length, or allocating space for, path names. (This is the correct
> thing to do.) On OS X PATH_MAX is 1024; on Linux it's 4096.
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
More information about the Vm-dev