21 Nov
2019
21 Nov
'19
10:48 p.m.
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)