
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

FONT-SIZE: 10pt;

FONT-FAMILY:Tahoma

}

</style>

</head>

<body class='hmmessage'>  > consider that (on Unix systems at least) '..' does not back out of a <BR>  > symbolic link, but may go somewhere else entirely.  Whether you want <BR> > this behaviour is, of course, up to you.<BR>

 <BR>

cm3 does this. Not up to me or you probably.<BR>

 <BR>

See m3-sys/cm3/src/M3Path.m3<BR>

 <BR>

PROCEDURE FixPath (VAR p: ARRAY OF CHAR;  host: BOOLEAN): TEXT =<BR>  (* remove redundant "/arc/../" and "/./" segments *)<BR>  VAR os := os_map [host];  len, x, s0, s1, s2: INTEGER;  info: SepInfo;<BR><BR>

 <BR>

 - Jay<BR><BR><BR>


<HR id=stopSpelling>

<BR>

> Date: Mon, 28 Jan 2008 09:46:29 -0500<BR>> From: hendrik@topoi.pooq.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] heap vs. stack? (sort of)<BR>> <BR>> On Mon, Jan 28, 2008 at 02:00:46PM +0000, Jay wrote:<BR>> > Both.<BR>> > In thinking about how to write the code, there is no point in splitting the code into two functions.<BR>> > They are each small and the one is only called once.<BR>> > The language should in general not force me to write functions merely to work over the type system.<BR>> > <*inline*> is not implemented by the integrated backend. I assume every function call I write will not be inlined.<BR>> > <BR>> > > Functions can return pointers to open arrays - isn't this enough?<BR>> > <BR>> > Yes that might help.<BR>> > I had tried like<BR>> > <BR>> > PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY OF CHAR =<BR>> > BEGIN<BR>> > IF len <= NUMBER(buf) RETURN buf;<BR>> > END;<BR>> > RETURN NEW ARRAY OF CHAR (len);<BR>> > END PickBuffer;<BR>> > <BR>> > PROCEDURE Parse(...)<BR>> > VAR<BR>> > stack: ARRAY [0..255] OF CHAR;<BR>> > BEGIN<BR>> > ...<BR>> > WITH buf = PickBuffer(stack, len) DO use buf<BR>> > END;<BR>> > END Parse<BR>> > <BR>> > but I couldn't come up with a PickBuffer that the compiler liked.<BR>> > <BR>> > PickBuffer is still a bit iffy.<BR>> > <BR>> > More generally in C++ I would implement that as a template class where one of the parameters is how much to preallocate. In C I would implement it as a struct and some functions and the initialization function would take the preallocated buffer and size.<BR>> > <BR>> > Surely Modula-3 can do either/both of those patterns well and it doesn't have to be reimplemented over and over.<BR>> > <BR>> > The Modula-3 code I see around the system is way more low level and repetitive than seems appropriate, more so than C code that I write.<BR>> > <BR>> > Another example is that it definitely appears that if I try to compile code with a path like<BR>> > \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3<BR>> > <BR>> > that has more than around 32 path separators, I'll just get some random failures since the code just "gives up".<BR>> > M3Path has an array of 32 to store the positions of path separators.<BR>> > That whole chunk of code, to remove \.\ I'll probably rewrite to be both more efficient and have no such capacity limits.<BR>> > For \.\ it is trivial.<BR>> > For \..\ it takes a bit of cleverness -- rather than rely on any indefinite amount of storage, what you can do is first reverse the string, then whenever you se .., bump up a counter, whenever you see not .., bump it down, only copy from source to dest when the counter is zero. Roughly.<BR>> <BR>> If you are talking about paths for naming files, you might want to <BR>> consider that (on Unix systems at least) '..' does not back out of a <BR>> symbolic link, but may go somewhere else entirely. Whether you want <BR>> this behaviour is, of course, up to you.<BR>> <BR>> -- hendrik<BR><BR><br /><hr />Need to know the score, the latest news, or you need your Hotmail®-get your "fix". <a href='http://www.msnmobilefix.com/Default.aspx' target='_new'>Check it out.</a></body>

</html>