The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Dave Horsfall <dave@horsfall.org>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] buffer overflow (Re:  Happy birthday Morris worm
Date: Thu, 21 Nov 2019 22:48:44 +0100	[thread overview]
Message-ID: <20191121214844.hQIAt%steffen@sdaoden.eu> (raw)
In-Reply-To: <alpine.BSF.2.21.9999.1911220658250.33542@aneurin.horsfall.org>

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)

  parent reply	other threads:[~2019-11-21 21:49 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-12 20:56 [TUHS] " Norman Wilson
2019-11-12 22:00 ` Dave Horsfall
2019-11-12 22:10 ` [TUHS] buffer overflow (Re: " Bakul Shah
2019-11-12 22:14   ` Larry McVoy
2019-11-12 22:41     ` Robert Clausecker
2019-11-12 22:49       ` Arthur Krewat
2019-11-12 23:45       ` Jon Steinhart
2019-11-13  0:38         ` Warren Toomey
2019-11-13  1:09         ` Arthur Krewat
2019-11-13  0:24       ` Larry McVoy
2019-11-12 22:54   ` Dave Horsfall
2019-11-12 23:22     ` Warner Losh
2019-11-12 23:27       ` Arthur Krewat
     [not found]     ` <alpine.DEB.2.20.1911191443530.10845@grey.csi.cam.ac.uk>
2019-11-21 20:02       ` Dave Horsfall
2019-11-21 20:38         ` Warner Losh
2019-11-21 21:04           ` Clem Cole
2019-11-21 22:06           ` Dave Horsfall
2019-11-21 21:48         ` Steffen Nurpmeso [this message]
2019-11-13  7:35 ` [TUHS] " arnold
2019-11-13 18:02   ` [TUHS] Happy birthday Morris worm [ really programming education ] Jon Steinhart
2019-11-13 18:49     ` Tyler Adams
2019-11-13 19:15     ` [TUHS] #defines and enums ron
2019-11-13 21:11       ` Warner Losh
2019-11-13 21:22     ` [TUHS] Happy birthday Morris worm [ really programming education ] Chet Ramey
2019-11-15 22:49     ` Adam Thornton
2019-11-15 23:59       ` Theodore Y. Ts'o
2019-11-12 22:39 [TUHS] buffer overflow (Re: Happy birthday Morris worm Norman Wilson
2019-11-13  1:43 ` John P. Linderman
2019-11-21 13:10   ` William Cheswick
2019-11-21 18:04     ` Steve Johnson
2019-11-21 21:51       ` John P. Linderman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191121214844.hQIAt%steffen@sdaoden.eu \
    --to=steffen@sdaoden.eu \
    --cc=dave@horsfall.org \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).