Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Wu Zhou <woodzltc@cn.ibm.com>
Cc: gdb@sources.redhat.com, gdb-patches@sources.redhat.com,
	mark.kettenis@xs4all.nl
Subject: Re: about the usage of sprintf in gdb, specifically in gdb/remote.c
Date: Thu, 26 May 2005 01:41:00 -0000	[thread overview]
Message-ID: <u3bsbma8l.fsf@gnu.org> (raw)
In-Reply-To: <Pine.LNX.4.63.0505250645170.1089@plinuxt18.cn.ibm.com> (message from Wu Zhou on Wed, 25 May 2005 07:04:11 -0700 (PDT))

> Date: Wed, 25 May 2005 07:04:11 -0700 (PDT)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> cc: mark.kettenis@xs4all.nl, eliz@gnu.org
> 
> 1. Won't introduce overflow. And one can easily see this from the 
> context.  To name an example in function remote_thread_alive:
>  
>   int tid = PIDGET (ptid);
>   char buf[16];
> 
>   if (tid < 0)
>     sprintf (buf, "T-%08x", -tid);
>   else
>     sprintf (buf, "T%08x", tid); 
> 
> In this context, there is no possibility that buf get overflowed. 

That might be so today, but if some day someone changes either the
size of buf[] or the format string, things could become messy.

I'd say, if we leave sprintf here, let's at least use sizeof(buf) in
the call to sprintf instead of a literal 8 in the format string.

As for the other 2 examples, I'd use safer functions there.  It's
unreasonable to request that Joe Random Hacker who happens to read the
code should perform the amount of analysis you demonstrated to
convince him/herself that the code is safe.  Most programmers won't go
to such lengths.


  reply	other threads:[~2005-05-25 18:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-25 13:00 Wu Zhou
2005-05-26  1:41 ` Eli Zaretskii [this message]
2005-05-26  3:11   ` Wu Zhou
2005-05-26  3:47     ` Eli Zaretskii
2005-05-26  6:37       ` Wu Zhou

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=u3bsbma8l.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=mark.kettenis@xs4all.nl \
    --cc=woodzltc@cn.ibm.com \
    /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