libchop: fix builds with glibc 2.16+
This commit is contained in:
parent
84d5defb75
commit
b6452df939
pkgs/development/libraries/libchop
@ -9,6 +9,8 @@ stdenv.mkDerivation rec {
|
|||||||
sha256 = "0fpdyxww41ba52d98blvnf543xvirq1v9xz1i3x1gm9lzlzpmc2g";
|
sha256 = "0fpdyxww41ba52d98blvnf543xvirq1v9xz1i3x1gm9lzlzpmc2g";
|
||||||
};
|
};
|
||||||
|
|
||||||
|
patches = [ ./gets-undeclared.patch ];
|
||||||
|
|
||||||
buildNativeInputs = [ pkgconfig gperf ];
|
buildNativeInputs = [ pkgconfig gperf ];
|
||||||
buildInputs =
|
buildInputs =
|
||||||
[ zlib bzip2 lzo
|
[ zlib bzip2 lzo
|
||||||
|
71
pkgs/development/libraries/libchop/gets-undeclared.patch
Normal file
71
pkgs/development/libraries/libchop/gets-undeclared.patch
Normal file
@ -0,0 +1,71 @@
|
|||||||
|
This patch is needed to allow builds with newer versions of
|
||||||
|
the GNU libc (2.16+).
|
||||||
|
|
||||||
|
|
||||||
|
commit 66712c23388e93e5c518ebc8515140fa0c807348
|
||||||
|
Author: Eric Blake <eblake@redhat.com>
|
||||||
|
Date: Thu Mar 29 13:30:41 2012 -0600
|
||||||
|
|
||||||
|
stdio: don't assume gets any more
|
||||||
|
|
||||||
|
Gnulib intentionally does not have a gets module, and now that C11
|
||||||
|
and glibc have dropped it, we should be more proactive about warning
|
||||||
|
any user on a platform that still has a declaration of this dangerous
|
||||||
|
interface.
|
||||||
|
|
||||||
|
* m4/stdio_h.m4 (gl_STDIO_H, gl_STDIO_H_DEFAULTS): Drop gets
|
||||||
|
support.
|
||||||
|
* modules/stdio (Makefile.am): Likewise.
|
||||||
|
* lib/stdio-read.c (gets): Likewise.
|
||||||
|
* tests/test-stdio-c++.cc: Likewise.
|
||||||
|
* m4/warn-on-use.m4 (gl_WARN_ON_USE_PREPARE): Fix comment.
|
||||||
|
* lib/stdio.in.h (gets): Make warning occur in more places.
|
||||||
|
* doc/posix-functions/gets.texi (gets): Update documentation.
|
||||||
|
Reported by Christer Solskogen.
|
||||||
|
|
||||||
|
Signed-off-by: Eric Blake <eblake@redhat.com>
|
||||||
|
|
||||||
|
diff --git a/lib/stdio.in.h b/lib/stdio.in.h
|
||||||
|
index aa7b599..c377b6e 100644
|
||||||
|
--- a/lib/stdio.in.h
|
||||||
|
+++ b/lib/stdio.in.h
|
||||||
|
@@ -698,22 +698,11 @@ _GL_WARN_ON_USE (getline, "getline is unportable - "
|
||||||
|
# endif
|
||||||
|
#endif
|
||||||
|
|
||||||
|
-#if @GNULIB_GETS@
|
||||||
|
-# if @REPLACE_STDIO_READ_FUNCS@ && @GNULIB_STDIO_H_NONBLOCKING@
|
||||||
|
-# if !(defined __cplusplus && defined GNULIB_NAMESPACE)
|
||||||
|
-# undef gets
|
||||||
|
-# define gets rpl_gets
|
||||||
|
-# endif
|
||||||
|
-_GL_FUNCDECL_RPL (gets, char *, (char *s) _GL_ARG_NONNULL ((1)));
|
||||||
|
-_GL_CXXALIAS_RPL (gets, char *, (char *s));
|
||||||
|
-# else
|
||||||
|
-_GL_CXXALIAS_SYS (gets, char *, (char *s));
|
||||||
|
-# undef gets
|
||||||
|
-# endif
|
||||||
|
-_GL_CXXALIASWARN (gets);
|
||||||
|
/* It is very rare that the developer ever has full control of stdin,
|
||||||
|
- so any use of gets warrants an unconditional warning. Assume it is
|
||||||
|
- always declared, since it is required by C89. */
|
||||||
|
+ so any use of gets warrants an unconditional warning; besides, C11
|
||||||
|
+ removed it. */
|
||||||
|
+#undef gets
|
||||||
|
+#if HAVE_RAW_DECL_GETS
|
||||||
|
_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
|
||||||
|
#endif
|
||||||
|
|
||||||
|
@@ -1053,9 +1042,9 @@ _GL_WARN_ON_USE (snprintf, "snprintf is unportable - "
|
||||||
|
# endif
|
||||||
|
#endif
|
||||||
|
|
||||||
|
-/* Some people would argue that sprintf should be handled like gets
|
||||||
|
- (for example, OpenBSD issues a link warning for both functions),
|
||||||
|
- since both can cause security holes due to buffer overruns.
|
||||||
|
+/* Some people would argue that all sprintf uses should be warned about
|
||||||
|
+ (for example, OpenBSD issues a link warning for it),
|
||||||
|
+ since it can cause security holes due to buffer overruns.
|
||||||
|
However, we believe that sprintf can be used safely, and is more
|
||||||
|
efficient than snprintf in those safe cases; and as proof of our
|
||||||
|
belief, we use sprintf in several gnulib modules. So this header
|
Loading…
Reference in New Issue
Block a user