public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Xi Ruoyao <xry111@xry111.site>
To: Rajeev Bansal <connectrajeev@gmail.com>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: Warning for unsafe/insecure functions
Date: Sun, 02 Apr 2023 02:50:21 +0800	[thread overview]
Message-ID: <1f13d81fd5b026e75254f2988f9296875e4aa0f2.camel@xry111.site> (raw)
In-Reply-To: <CAM05QofhDr=LUx6mdbKeHGcE02Er6Pv_ov=pUa5T86fKYtgWmA@mail.gmail.com>

On Sat, 2023-04-01 at 22:41 +0530, Rajeev Bansal via Gcc-help wrote:
>  Hi All,
> 
>   I am looking for if gcc has the capability to report unsafe/insecure
> functions used in a C Or CPP program? For example : if strcpy(), strcat(),
> alloca(), atoi() etc. are used in a program then gcc should raise a
> warning.

If most people believe they are dangerous, they will be marked with
__attribute__((deprecated)) in libc headers.  Then GCC will emit a
warning with -Wdeprecated (enabled by default).

But libc is not a part of GCC.  And before you start to wonder: no, a
patch deprecating these function will be rejected, please do not send
such a patch to libc-alpha.

There are still many valid uses of these functions and you cannot
deprecate them just because your will.  "I think it's dangerous" is
different from "the function is inherently dangerous" or "most people
think it's dangerous".

If you don't want those functions in your project, you can create some
wrappers like:

__attribute__((deprecated)) static inline char *
_strcpy_do_not_use (char *dest, const char *src)
{
  return strcpy (dest, src);
}

#define strcpy _strcpy_do_not_use

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

  reply	other threads:[~2023-04-01 18:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-31 21:54 __attribute__ error ("message") Jonny Grant
2023-03-31 21:57 ` Jonathan Wakely
2023-03-31 21:58 ` Xi Ruoyao
2023-03-31 22:12   ` Jonny Grant
2023-03-31 22:13     ` Xi Ruoyao
2023-04-01 16:57       ` Jonny Grant
2023-04-01 23:00         ` Jonathan Wakely
2023-04-10 23:06           ` Jonny Grant
2023-04-01 17:11 ` Warning for unsafe/insecure functions Rajeev Bansal
2023-04-01 18:50   ` Xi Ruoyao [this message]
2023-04-02  2:12     ` Rajeev Bansal

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=1f13d81fd5b026e75254f2988f9296875e4aa0f2.camel@xry111.site \
    --to=xry111@xry111.site \
    --cc=connectrajeev@gmail.com \
    --cc=gcc-help@gcc.gnu.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 read-only IMAP folder(s) and NNTP newsgroup(s).