From: frank on
Seebs wrote:
[x-posted to c.u.p.]
> -s
> p.s.: Off-topic: There isn't a guaranteed predefined value for the
> maximum length of a thing linked to, so if you want to be paranoid,
> check to make sure that the value returned is less than the buffer
> size, and if it wasn't, use a bigger buffer.

Determining the size of these buffers seems like a usual introduction to
unix. I started my little PATH_MAX hack at 100, was amazed at the
varieties of undefined behavior I brought forth on my machine, and now I
think 4096 might be a good number to start with on these buffers.


--
frank
From: Nobody on
On Mon, 01 Feb 2010 16:42:24 -0700, frank wrote:

>> p.s.: Off-topic: There isn't a guaranteed predefined value for the
>> maximum length of a thing linked to, so if you want to be paranoid,
>> check to make sure that the value returned is less than the buffer
>> size, and if it wasn't, use a bigger buffer.
>
> Determining the size of these buffers seems like a usual introduction to
> unix. I started my little PATH_MAX hack at 100, was amazed at the
> varieties of undefined behavior I brought forth on my machine, and now I
> think 4096 might be a good number to start with on these buffers.

The correct answer for Unix (readlink() isn't in ANSI C) is to use
pathconf(path, _PC_PATH_MAX) or fpathconf(fd, _PC_PATH_MAX), where path or
fd identify the filesystem (the values can vary between filesystems, so
you might get a different result for /usr or /tmp than for the root
filesystem).

However:

1. [f]pathconf can return -1, indicating that there is no pre-determined
limit.

2. If the buffer isn't large enough, readlink() *doesn't* include a
terminating NUL byte.

So the safest approach is to malloc() a buffer, then call readlink() in a
loop, realloc()ing the buffer until the value returned from readlink() is
strictly less than (i.e. "<", *not* "<=") the the buffer size.

From: Seebs on
On 2010-02-02, Nobody <nobody(a)nowhere.com> wrote:
> 2. If the buffer isn't large enough, readlink() *doesn't* include a
> terminating NUL byte.

Actually, so far as I can tell, it's not guaranteed to anyway.

> So the safest approach is to malloc() a buffer, then call readlink() in a
> loop, realloc()ing the buffer until the value returned from readlink() is
> strictly less than (i.e. "<", *not* "<=") the the buffer size.

Yeah. Annoying!

(followups to c.u.p.)

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: micropentium on
On Feb 1, 6:42 pm, frank <fr...(a)example.invalid> wrote:
> Seebs wrote:
>
> [x-posted to c.u.p.]
>
> > -s
> > p.s.: Off-topic: There isn't a guaranteed predefined value for the
> > maximum length of a thing linked to, so if you want to be paranoid,
> > check to make sure that the value returned is less than the buffer
> > size, and if it wasn't, use a bigger buffer.
>
> Determining the size of these buffers seems like a usual introduction to
> unix. I started my little PATH_MAX hack at 100, was amazed at the
> varieties of undefined behavior I brought forth on my machine, and now I
> think 4096 might be a good number to start with on these buffers.
>
> --
> frank

Check Richard Stevens APUE charpter 2.5 Fig 2.15, it offers a good
solution to dynamically allocate space for this purpose.