From: Ed Schouten <ed@nuxi.nl>
To: gdb-patches@sourceware.org
Subject: Likely incorrect patch: remove the faulty basename() prototype from libiberty
Date: Sun, 29 May 2016 14:58:00 -0000 [thread overview]
Message-ID: <CABh_MKn1yUfKjtZO4nZ+XyvVXHUgtD7QE-hAM-AP6FNH=zKooQ@mail.gmail.com> (raw)
Hi there,
Libiberty has the prototype of basename() declared in its libiberty.h.
Unfortunately, it has it declared with a different prototype as
standardized by POSIX. POSIX requires that its argument is of type
"char *', while the one in libiberty.h uses "char *". Normally this
problem is not exposed at all, because none of the GDB code includes
the header file with the actual prototype (libgen.h).
I'm currently working on patching up FreeBSD to also use the prototype
as standardized by POSIX, as opposed to the BSD-specific one that has
"const char *'. In FreeBSD we have some utilities built against GDB
(e.g., our kernel debugger kgdb) that ends up including both
libiberty.h and libgen.h. meaning we get compiler errors due to
different declarations for the same function.
For now I'm solving this by simply patching up libiberty to pull in
the declaration from libgen.h. This seems to make everything build
again.
diff --git a/include/libiberty.h b/include/libiberty.h
index 8e096a0..403e690 100644
--- a/include/libiberty.h
+++ b/include/libiberty.h
@@ -109,7 +109,7 @@ extern int countargv (char**);
|| defined (__FreeBSD__) || defined (__OpenBSD__) || defined (__NetBSD__) \
|| defined (__CYGWIN__) || defined (__CYGWIN32__) || defined (__MINGW32__) \
|| defined (__DragonFly__) || defined (HAVE_DECL_BASENAME)
-extern char *basename (const char *) ATTRIBUTE_RETURNS_NONNULL
ATTRIBUTE_NONNULL(1);
+#include <libgen.h>
#else
/* Do not allow basename to be used if there is no prototype seen. We
either need to use the above prototype or have one from
I guess that this is not the right way of solving this. I'd guess that
we should just remove all of the basename() specific bits from all of
libiberty and just include libgen.h in the source files that actually
need it.
What do you folks think?
--
Ed Schouten <ed@nuxi.nl>
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
next reply other threads:[~2016-05-29 14:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-29 14:58 Ed Schouten [this message]
2016-05-29 16:32 ` DJ Delorie
2016-05-29 16:36 ` Ed Schouten
2016-05-29 17:06 ` DJ Delorie
2016-05-29 17:24 ` Ed Schouten
2016-05-29 17:35 ` DJ Delorie
2016-06-02 21:27 ` Joseph Myers
2016-06-03 9:37 ` Ed Schouten
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='CABh_MKn1yUfKjtZO4nZ+XyvVXHUgtD7QE-hAM-AP6FNH=zKooQ@mail.gmail.com' \
--to=ed@nuxi.nl \
--cc=gdb-patches@sourceware.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