This is the mail archive of the cygwin-patches mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
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.
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.
Attachment:
cygwin-getmntent_r.patch
Description: application/itunes-itlp
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |