This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] c/66516 - missing diagnostic on taking the address of a builtin function
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Marek Polacek <polacek at redhat dot com>
- Cc: Martin Sebor <msebor at gmail dot com>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 23 Jun 2015 12:29:09 +0200
- Subject: Re: [PATCH] c/66516 - missing diagnostic on taking the address of a builtin function
- Authentication-results: sourceware.org; auth=none
- References: <5587432A dot 9000602 at redhat dot com> <20150622144010 dot GK10139 at redhat dot com> <5588BD78 dot 4030607 at gmail dot com> <20150623101829 dot GQ10139 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jun 23, 2015 at 12:18:30PM +0200, Marek Polacek wrote:
> > Is it intended that programs be able to take the address of
> > the builtins that correspond to libc functions and make calls
> > to the underlying libc functions via such pointers? (If so,
> > the patch will need some tweaking.)
>
> I don't think so, at least clang doesn't allow e.g.
> size_t (*fp) (const char *) = __builtin_strlen;
Well, clang is irrelevant here, __builtin_strlen etc. is a GNU
extension, so it matters what we decide about it. As this used to work
for decades (if the builtin function has a libc fallback), suddenly
rejecting it could break various programs that e.g. just
#define strlen __builtin_strlen
or similar. Can't we really reject it just for the functions
that don't have a unique fallback?
Jakub