Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Cc: Martin Sebor <msebor@redhat.com>
Cc: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Files moved from .txt to .rst.
Also, drop / prefix from kernel source tree references.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The main point I was driving at with this patch was to fix
"Microsoft Window's FAT filesystems" (i.e., FAT filesystems which
belong to Microsoft Windows, which is decidedly wrong).
FAT32 first shipped with MS-DOS 7.1, as part of Windows 95 OSR2,
but it's a (relatively) simple logical extension of the previous
FATx filesystems (16 and 12 as we know and love them today, I
don't think the PC ever saw 8), hence the "VFAT" driver name ‒
calling FAT-anything a Windows filesystem would be a flat-out lie,
calling it a Microsoft filesystem would be, uh, facetious.
NTFS (as part of Windows NT), on the other hand, is wholly
different WRT the scope and feature-set (it does borrow some
layouting from FAT, but reading NTFS as FAT doesn't get you very
far, or much).
The replacing bit is also questionable, especially in a.d. 2020:
while it is true that you cannot install NT on FAT (after a
certain point? my memory ain't what it used to be), and must
therefore replace your existing FAT partitions with NTFS during
upgrades; Windows NT 4.0, the last product to be NT-branded came
out in 1996, i.e. you could not install Windows on FAT (and,
therefore, upgrade it to NTFS, replacing it) during my entire
lifetime.
Indeed, in $(date +%Y) we live in a post-NTFS world ‒ putting NTFS
in the same class as FAT beyond "is a filesystem" is a joke.
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Relevant Linux commits:
* moved to staging in 1bb8155080c652c4853e6228f8f0d262b3049699
(describe: v4.15-rc1-129-g1bb8155080c6) in Nov 2017,
described as "broken" and "obsolete"
* purged in bd32895c750bcd2b511bf93917bf7ae723e3d0b6
(describe: v4.17-rc3-1010-gbd32895c750b) in Jun 2018,
"since no one has complained or even noticed it was gone"
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since Linux kernel 3.12, tcp_syncookies can have the value 2,
which sends out cookies unconditionally.
Related kernel commits:
5ad37d5deee1ff7150a2d0602370101de158ad86
d8513df2598e5142f8a5c4724f28411936e1dfc7
Reported-by: Philip Rowlands <linux-kernel@dimebar.com>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Quoting Heinrich:
The strnlen.3 manpage has the following sentence:
"In doing this, strnlen() looks only at the first maxlen
characters in the string pointed to by s and never beyond
s+maxlen."
This sentence is self-contradictory:
The last visited character implied by "first maxlen
characters" is s[maxlen-1].
Given that "beyond a" does not include "a", the last visited
character implied by "never beyond s+maxlen" is s[maxlen].
A consistent sentence would be
"In doing this, strnlen() looks only at the first maxlen
characters in the string pointed to by s and never beyond
s+maxlen-1."
I would prefer
"In doing this, strnlen() looks only at the first maxlen
characters in the string pointed to by s and never beyond
s[maxlen-1]"
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The Linux kernel uses 'int' instead of 'long' for the return type.
As glibc provides no wrapper, use the same type the kernel uses.
......
$ grep -n wrapper man-pages/man2/subpage_prot.2
40:There is no glibc wrapper for this system call; see NOTES.
99:Glibc does not provide a wrapper for this system call; call it using
$ grep -rn SYSCALL_DEFINE.*subpage_prot linux/;
linux/arch/powerpc/mm/book3s64/subpage_prot.c:190:
SYSCALL_DEFINE3(subpage_prot, unsigned long, addr,
$ sed -n /SYSCALL.*subpage_prot/,/^}/p \
linux/arch/powerpc/mm/book3s64/subpage_prot.c \
|grep return;
return -ENOENT;
return -EINVAL;
return -EINVAL;
return 0;
return -EFAULT;
return -EFAULT;
return err;
$ sed -n /SYSCALL.*subpage_prot/,/^}/p \
linux/arch/powerpc/mm/book3s64/subpage_prot.c \
|grep '\<err\>';
int err;
err = -ENOMEM;
err = -ENOMEM;
err = 0;
return err;
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This paragraph is a little bit hidden at the end of DESCRIPTION;
make it a little more prominent.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk