[PATCH] Add getmntent_r

Yaakov (Cygwin/X) yselkowitz@users.sourceforge.net
Wed Jul 18 10:21:00 GMT 2012

Somehow this one fell through the cracks.  Picking up where we left off:

On 2012-06-06 02:33, Corinna Vinschen wrote:
> On Jun  5 21:29, Yaakov (Cygwin/X) wrote:
>> The string returned into buf is in the following format:
>> mnt_fsname\0mnt_dir\0mnt_type\0mnt_opts\0mnt_freq" "mnt_passno\0
> Yes, but this is not something inherent to the functionality of
> getmntent_r, it's just residue from the way getmntent_r works.  It reads
> a line from /etc/fstab or /etc/mtab into the buffer via fgets:
>    mnt_fsname\tmnt_dir\tmnt_type\tmnt_opts\tmnt_freq\n
> and then creates the content of mntbuf from there, replacing the \t with
> \0 as it goes along.  So it starts with mnt_opts and mnt_freq strings in
> buf, but only to sscanf them into their respective mntbuf->mnt_opts and
> mntbuf->mnt_freq members.

Since glibc is getting this information from the kernel, that makes sense.

> In case of Cygwin this is not needed since we don't read from the file
> but from the internal datastructure.  There's no reason to create
> garbage in buf just because this is by chance the layout the buffer gets
> when operating under Linux.
> The *important* thing is that buf contains the strings the members of
> mntbuf points to.

OK, revised patch attached.

>> glibc makes no attempt to verify buf or mntbuf; if either of them
>> are not initialized or too small, you're in "undefined behaviour"
>> territory (aka SEGV :-).
> You're basically right.  But it won't SEGV if buf is too small.

By "too small", I meant sizeof(buf) < buflen, or sizeof(mntbuf) < 
sizeof(struct mntent); then glibc definitely does SEGV.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygwin-getmntent_r.patch
Type: application/x-itunes-itlp
Size: 4602 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20120718/dae11163/attachment.bin>

More information about the Cygwin-patches mailing list