Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!sun-barr!newstop!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Folder hierarchy and pathname length
Message-ID: <2063@atari.UUCP>
Date: 1 Mar 90 19:53:08 GMT
References: <2051@atari.UUCP> <2018@laura.UUCP> <2056@atari.UUCP> <BAMMI.90Mar1035335@dsrgsun.ces.CWRU.Edu>
Organization: Atari Corp., Sunnyvale CA
Lines: 26

bammi@dsrgsun.ces.CWRU.Edu (Jwahar R. Bammi) writes:
>In article <2056@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
>> GEMDOS never *constructs* pathnames, so it doesn't have any buffers or
>> anything (of limited size or otherwise).  When you do a Dgetpath, *you*
>> supply the buffer, and it had better be big enough.

>huh? Dgetpath/gemdos whoever *does* monkey around in the buffer
>you supply.

That's what I said: Dgetpath writes the the current path into the
buffer you supply, and since you can't tell Dgetpath how long that
buffer is, it'd better be long enough.  If your current path is shorter
than 32 chars, Dgetpath should certainly not clobber anything outside
your 32-char buffer.

>	the developers gemdos documentation states that 125 is the max
>path length. i guess its either obsolete or incorrect.

That has always been specious: I think the original author must've used
that number because it's the longest filename you could pass as an
argument to a program via Pexec.  There's no such limit on filename
lengths and never has been.

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt