Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Mon, 5 Jan 2004 19:43:25 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: readlink null termination problem Message-ID: <20040106004325.GA3579@redhat.com> Mail-Followup-To: cygwin AT cygwin DOT com References: <20040106001714 DOT 13201 DOT qmail AT linuxmail DOT org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040106001714.13201.qmail@linuxmail.org> User-Agent: Mutt/1.4.1i X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com On Tue, Jan 06, 2004 at 08:17:14AM +0800, peter garrone wrote: >I was having a problem with mkcramfs on cygwin creating symbolic links >for the compressed linux filesystem. > >mkcramfs uses malloc to allocate a buffer that it sends to the readlink function in cygwin path.cc >That function uses memcpy to do a copy of the link into a buffer. >Neither mkcramfs or readlink is null-terminating the string representing the link. > >Probably both are at fault. I have fixed my problem by zeroing the buffer in mkcramfs > before calling readlink, but it would probably be beneficial if readlink terminates > the returned string, if there is room. NAME readlink - read value of a symbolic link SYNOPSIS #include int readlink(const char *path, char *buf, size_t bufsiz); DESCRIPTION readlink places the contents of the symbolic link path in the buffer buf, which has size bufsiz. readlink does not append a NUL character to buf. It will truncate the contents (to a length of bufsiz charac- ters), in case the buffer is too small to hold all of the contents. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/