Dave Horsfall wrote in <alpine.BSF.2.21.9999.1911220658250.33542@aneurin\ .horsfall.org>: |On Tue, 19 Nov 2019, Tony Finch wrote: |> Amusingly POSIX says the C standard takes precedence wrt the details of |> gets() (and other library functions) and C18 abolished gets(). I'm |> slightly surprised that the POSIX committee didn't see that coming and |> include the change in the 2018 edition... This week (on the 19th, to be exact) Geoff Clare made official the desire to align a forthcoming POSIX Issue 8 with ISO C17. Current POSIX (1003.1(2016)/Issue7+TC2) still aligns with C99. And, compared to C99, the POSIX wording causes sympathy d37021 APPLICATION USAGE 37022 Reading a line that overflows the array pointed to by s results in undefined behavior. The use of 37023 fgets( ) is recommended. 37024 Since the user cannot specify the length of the buffer passed to gets( ), use of this function is 37025 discouraged. The length of the string read is unlimited. It is possible to overflow this buffer in 37026 such a way as to cause applications to fail, or possible system security violations. 37027 Applications should use the fgets( ) function instead of the obsolescent gets( ) function. 37028 RATIONALE 37029 The standard developers decided to mark the gets( ) function as obsolescent even though it is in 37030 the ISO C standard due to the possibility of buffer overflow. 37031 FUTURE DIRECTIONS 37032 The gets( ) function may be removed in a future version. |Didn't know that gets() had finally been abolished; it's possibly the most |unsafe function (OK, macro) on the planet. I've long been tempted to |remove gets() and see what breaks... It seems to have been removed in C 2011, except get_s(), which is still present in the C 2017 draft that i have. (I have never used any of the _s() functions.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)