found 655411 dpkg/1.2.0 thanks On Tue, 2012-01-10 at 16:40:00 -0600, Jonathan Nieder wrote: > dan...@ruoso.com wrote: > > The implementation of vsnprintf in the compat library uses and > > caches the file descriptor for a temporary file. > > > > If the vsnprintf function is called before a fork, two concurrent > > processes will share the cached file descriptor and will eventually > > cause a race condition where the output of snprintf in one process > > will leak to the other. > > Yeah, that's true. Maybe it would be worth dropping the > !HAVE_VSNPRINTF fallback altogether,
I'm assuming if Daniel found out about this is because that system does not provide a working vsnprintf(), so dropping it would not help much. > or we could use one of the many implementations of vsnprintf available > under GPL-compatible licenses. And while this is tempting as I've always found the compat vsnprintf() a bit gross, it has the nice property of being an extremely tiny implementation, and I despise embedded code copies. Something that has crossed my mind in the past to improve the function performance has been to make it use a memory backed FILE, through one of funopen(3), fopencookie(3), shm_open(3) or open_memstream(3). Although if the system has any of these then it most probably also has vsnprintf(3). Daniel does your HP-UX release suport any of these (my only dim expectation is for shm_open(3))? > What platform do you use? Does it support pthread_atfork? I'd rather avoid having to link against the pthread library. > > The easy solution is to simply stop using a global file descriptor > > Care to suggest a patch? I'm committing a fix, that still uses a cached file per process. thanks, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
