about summary refs log tree commit diff
path: root/src/misc/mntent.c
Commit message (Collapse)AuthorAgeFilesLines
* mntent: fix potential mishandling of extremely long linesRich Felker2022-05-151-0/+2
| | | | | | | | | | | commit 05973dc3bbc1aca9b3c8347de6879ed72147ab3b made it so that lines longer than INT_MAX can in theory be read, but did not use a suitable type for the positions determined by sscanf. we could change to using size_t, but since the signature for getmntent_r does not admit lines longer than INT_MAX, it does not make sense to support them in the legacy thread-unsafe form either -- the principle here is that there should not be an incentive to use the unsafe function to get added functionality.
* mntent: fix parsing lines with optional fieldsAlyssa Ross2022-05-151-3/+7
| | | | | | | | | | | | | | According to fstab(5), the last two fields are optional, but this wasn't accepted. After this change, only the first field is required, which matches glibc's behaviour. Using sscanf as before, it would have been impossible to differentiate between 0 fields and 4 fields, because sscanf would have returned 0 in both cases due to the use of assignment suppression and %n for the string fields (which is important to avoid copying any strings). So instead, before calling sscanf, initialize every string to the empty string, and then we can check which strings are empty afterwards to know how many fields were matched.
* use dynamic buffer for getmntentNatanael Copa2016-10-201-4/+13
| | | | | | | | | | overlayfs may have fairly long lines so we use getline to allocate a buffer dynamically. The buffer will be allocated on first use, expand as needed, but will never be free'ed. Downstream bug: http://bugs.alpinelinux.org/issues/5703 Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
* make endmntent function handle null argumentTimo Teräs2014-08-081-1/+1
| | | | | The function originates from SunOS 4.x in which the null argument is allowed. glibc also handles this case.
* cleanup src/linux and src/misc trees, etc.Rich Felker2012-09-071-0/+68
previously, it was pretty much random which one of these trees a given function appeared in. they have now been organized into: src/linux: non-POSIX linux syscalls (possibly shard with other nixen) src/legacy: various obsolete/legacy functions, mostly wrappers src/misc: still mostly uncategorized; some misc POSIX, some nonstd src/crypt: crypt hash functions further cleanup will be done later.