From: Andre Majorel <aym-xunil-Bi/FLWfhfolQFI55V6+gNQ@public.gmane.org>
To: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] Quarantine "gets.3" into its own "do not use" manpage
Date: Fri, 15 Nov 2013 19:54:55 +0100 [thread overview]
Message-ID: <20131115185455.GA20757@aym.net2.nerim.net> (raw)
In-Reply-To: <1384370434.15325.33.camel@surprise>
On 2013-11-13 14:20 -0500, David Malcolm wrote:
> Currently man3/gets.3 documents various safe I/O functions, along with
> the toxic "gets" function.
>
> At the risk of being melodramatic, this strikes me as akin to storing
> rat poison in a food cabinet, in the same style of packaging as the
> food, but with a post-it note on it saying "see warnings below".
>
> I think such "never use this" functions should be quarantined into their
> own manpages, rather than listing them alongside sane functions.
>
> The attached patch does this for "gets", moving the documentation of the
> good functions from man3/gets.3 into man3/fgetc.3, updating the SO links
> in the relevant functions to point at the latter.
>
> It then rewrites man3/gets.3 to spell out that "gets" is toxic and
> should never be used (with a link to CWE-242 for good measure).
>
> Thoughts?
For what my opinion's worth, I like this patch. it makes it
harder to miss the warnings.
Two objections :
1. Seems C89, C99 and POSIX.1-2001 have been dropped from the
CONFORMING TO section. If that is deliberate, I would like to
know the rationale behind this change.
2. Rather than
gets() is supposed to return s on success, and NULL on
error or when end of file occurs while no characters have
been read. However, given the lack of buffer overrun
checking, there can be no guarantees that the function will
even return.
how about
gets() returns s on success and NULL on error or when end
of file occurs while no characters have been read. Unless
the buffer is overrun, in which case there is no guarantee
that the function will even return.
The idea is to avoid "is supposed to", which feels out of
place in a reference document. Refreshingly sarcastic as it
may be. :->
The "For more information, see CWE-242" bit is in the BUGS
section, right ? Can't tell from the diff alone.
--
André Majorel http://www.teaser.fr/~amajorel/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-11-15 18:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-13 19:20 [PATCH] Quarantine "gets.3" into its own "do not use" manpage David Malcolm
2013-11-15 18:54 ` Andre Majorel [this message]
[not found] ` <20131115185455.GA20757-956IwFboN44acnK+F/IuxqxOck334EZe@public.gmane.org>
2013-12-31 9:35 ` Michael Kerrisk (man-pages)
2013-11-19 14:13 ` walter harms
2013-12-31 9:31 ` Michael Kerrisk (man-pages)
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=20131115185455.GA20757@aym.net2.nerim.net \
--to=aym-xunil-bi/flwfhfolqfi55v6+gnq@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.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).