If you really want to get into realpath():
https://www.securecoding.cert.org/confluence/display/seccode/FIO02-A.
+Canonicalize+path+names+originating+from+untrusted+sources
.hc
On May 22, 2008, at 10:06 PM, Hans-Christoph Steiner wrote:
To quote the whole text:
Avoid using this function. It is broken by design since (unless
using the non-
standard resolved_path == NULL feature) it is impossible to
determine a suitable
size for the output buffer, resolved_path. According to POSIX a
buffer of size
PATH_MAX suffices, but PATH_MAX need not be a defined constant,
and may have to
be obtained using pathconf(). And asking pathconf() does not
really help, since
on the one hand POSIX warns that the result of pathconf()
may be huge and
unsuitable for mallocing memory. And on the other hand pathconf
() may return -1
to signify that PATH_MAX is not bounded.
I think whoever wrote that man page is really splitting hairs
there, the FreeBSD/Mac OS X man page has no complaints about it.
They are complaining that PATH_MAX _might_ not be defined. But on
GNU/Linux, MinGW, and FreeBSD/Mac OS X, FILENAME_MAX _is_
defined. So just use FILENAME_MAX to allocate the buffer that
realpath() uses (which was already happening anyway in s_main.c,
but with MAXPDSTRING instead). It's a widely implemented POSIX
function, how much more standard do you want? ;)
I think that Pd should give reliable information in the publically
defined API (ok, s_stuff.h, but still). For example, it makes
life easier in a lot of ways if you can count on sys_libdir being
an absolute path, rather than making every other bit of code that
might every use a path that is based on sys_libdir check to make
sure that it is indeed absolute. The vast majority of the time,
sys_libdir is an absolute path, and AFAIK, on Windows it is always
an absolute path.
.hc
On May 22, 2008, at 9:44 PM, Miller Puckette wrote:
I finally realized realpath() is a pre-existing function. (I
imagined
it was sitting in another source file that didn't make it to the
patch)
but.. "man realpath" says "Avoid using this function. It is
broken by design..."
so I'm sceptical of the idea. Anyway, why can't [import] just
make the
call if it needs it?
cheers
M
On Thu, May 22, 2008 at 09:33:14PM +0200, Hans-Christoph Steiner
wrote:
The only real change to s_main.c in that path is the addition of
realpath(). It seems that the function there is just copying the
strings back and forth between sbuf and sbuf2, so I just added one
more iteration of that back and forth for realpath().
.hc
On May 22, 2008, at 9:25 PM, Miller Puckette wrote:
I might have missed it, but I didn't see that realpath() itself
made it into
the patch... ?
M
On Thu, May 22, 2008 at 09:22:12PM +0200, Hans-Christoph Steiner
wrote:
The realpath() is definitely related. If you start Pd using a
relative path, like I do when doing dev work (e.g. make && ../
bin/
pd), then sys_libdir will be a relative path. That means it is
impossible to make absolute paths using sys_libdir, which is
what I
need to do to make [import] work, or loading libdirs with
[declare -
lib] and the libdir loader.
I can't see any problems that realpath() might cause.
.hc
On May 22, 2008, at 8:45 PM, Miller Puckette wrote:
OK, I took most of the patch (not the "realpath()" call which
seems
unrelated) and uploaded to SVN, unless I'm mistaken.
cheers
Miller
On Wed, May 21, 2008 at 08:22:23PM +0200, Hans-Christoph Steiner
wrote:
I was looking into this a bit more, and from what I can
tell, the
canvas-local path (ce_path) is always relative to the path
of the
parent patch. Here's the commit for pd-extended that adds
support
for absolute paths:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?
view=rev&revision=9862
Also, I submitted a patch:
http://sourceforge.net/tracker/index.php?
func=detail&aid=1917574&group_id=55736&atid=478072
.hc
On May 19, 2008, at 9:42 PM, Hans-Christoph Steiner wrote:
I think I fixed the full paths bug, here's the commit:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?
view=rev&revision=9856
.hc
On May 19, 2008, at 8:03 PM, Hans-Christoph Steiner wrote:
I think this issue is pretty clear, and the languages that
I know
would fall along the lines of "each patch/abstraction has
its own
namespace" or in other words "#include only affects the
one .c
file", "import only affects the one .py file", etc. So I
agree
with Frank. Global settings are global, and canvas-local
settings
are local to the original file.
The "semi-functional" part is the full paths that Marius
mentioned.
Then the other question is how to use something like "#X
declare"/
canvas_savedeclarationsto() in externals. I'd like to
create an
[import] modelled after Python's import does, so I'd like
to use
"#X declare"/canvas_savedeclarationsto() with it.
.hc
On May 19, 2008, at 6:33 PM, Miller Puckette wrote:
Hi all,
I use 'declare' all the time.. don't think it's
semifunctional at
all.
I think the questions about how declares should act inside
abstractions
are hard to resolve; in my own usage (and in the way I
suggest
others might
want to use declare) it's always in the main patch, as a
way to
show the
patch what libraries, etc, it needs.
cheers
Miller
On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph
Steiner
wrote:
Hey,
So I am diving into the whole canvas-local namespace and
[declare]
issue these days. I like the new "#X declare"/
canvas_savedeclarationsto() functionality, I think it
could be
useful
for a lot of things. I was thinking of making an API to
use
it in
externals, something like sys_register_loader(). I have
two
questions, first, how entrenched is the current behavior of
[declare]? It currently is only semi-functional, and I
think few
people use it.
The second is how to structure this for general use. I
have
thought
of two ways:
- make "declare" the key word and allow other
objectclasses to
have
their own custom "#X declare" data.
- allow objectclasses to register their own declaration key
words,
like [import] could have "#X import".
The first would mean changing the behavior of [declare],
the
second
could lead to a big mess...
.hc
-----------------------------------------------------------
----
--
--
-----
----
Man has survived hitherto because he was too ignorant to
know
how to
realize his wishes. Now that he can realize them, he must
either
change them, or perish. -William Carlos Williams
_______________________________________________
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
-------------------------------------------------------------
----
--
--
-------
News is what people want to keep hidden and everything
else is
publicity. - Bill Moyers
--------------------------------------------------------------
----
--
--
------
You can't steal a gift. Bird gave the world his music, and
if you
can hear it, you can have it. - Dizzy Gillespie
---------------------------------------------------------------
----
--
---
----
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
_______________________________________________
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
-----------------------------------------------------------------
----
---
----
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
-------------------------------------------------------------------
-----
----
"It is convenient to imagine a power beyond us because that
means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
---------------------------------------------------------------------
-------
If you are not part of the solution, you are part of the problem.
------------------------------------------------------------------------
----
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
_______________________________________________
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
