defining after execution
in [Unix Programming]
|
From: frank on 1 Feb 2010 18:42 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 1 Feb 2010 20:52 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 1 Feb 2010 21:05 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 2 Feb 2010 10:43 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.
|
Pages: 1 Prev: How to set mtime etc Next: readlink (was: defining after execution) |