Re: [PATCH] Add getmntent_r

[Yaakov (Cygwin/X)]

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.

Yaakov

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

cygwin-getmntent_r.patch
Description: application/itunes-itlp