Re: Discussion about why GNU/Linux system upgrades cause old programs to break

Arsen Arsenović <[email protected]>
Newsgroups gmane.emacs.devel
Message-ID <[email protected]>
Richard Stallman <[email protected]> writes:

>     > In file included from ../src/config.h:1430,
>     >                  from sha256.c:23:
>     > ./stdio.h:1030:1: error: ‘gets’ undeclared here (not in a function); did you mean ‘fgets’?
>     >  1030 | _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
>
> It looks like this code was trying to do something entirely
> legitimate: warn if `gets' is called.  But now that GCC is trying to
> do the same thing, one warning warns about setting up the other.  Is
> that right?

No, the reason this fails is because 'gets' was pulled from C and POSIX
at some point (I think C11 and POSIX 2008, but I did not double check
the latter).

When compiling with -std=c11 or newer, or when compiling with
_GNU_SOURCE (as that enables the newest set of features despite the
dialect flag), the declaration is not provided, thus this fails.

The above is fine and useful to Emacs developers but, because this is a
case where Gnulib attempts to redeclare a standard identifier, it could
mean that it causes problems on compilers or libcs Gnulib wasn't tested
against.

Such a warning isn't very useful to Emacs users, just Emacs developer,
and relies on redeclaring a standard identifier - this is why I said it
maybe should've been gated off such that the risk involved with
redeclaring a standard identifier is not exposed to users (who are at no
risk of calling 'gets' as they're writing Elisp).

But, this didn't fail here because of the redeclaration, but because
'gets' was removed from C11 and _GNU_SOURCE.

There may be a case for re-enabling it if __STDC_VERSION__ is not >=
201111L (the value that constant is set in C11; newer dialects always
have an increasing value of this macro, see (cpp) Standard Predefined
Macros), even if _GNU_SOURCE is present.

That'd fix the above error in particular.

Especially as glibc already marks 'gets' as deprecated, and emits a
warning on use:

  ~$ gcc -std=c99 -x c -include stdio.h - <<<'int main () { char x[123]; gets (x); }'
  <stdin>: In function ‘main’:
  <stdin>:1:1: warning: ‘gets’ is deprecated [-Wdeprecated-declarations]
  In file included from <command-line>:
  /usr/include/stdio.h:671:14: note: declared here
    671 | extern char *gets (char *__s) __wur __attribute_deprecated__;
        |              ^~~~
  [COMMENT from me: the output below is from the linker rather than
   compiler, informed by the libc providing a warning for the 'gets'
   symbol]
  /usr/x86_64-pc-linux-gnu/binutils-bin/2.46.1/ld: /tmp/ccTPzuEV.o: in function `main':
  <stdin>:(.text+0x29): warning: the `gets' function is dangerous and should not be used.

I am not sure, but I have a feeling that the removal from C99 with
_GNU_SOURCE was likely not intended (at least, I don't see the use in
doing so personally).

> The warning message comes from compiling stdio.h.  Does that mean
> that this is a conflict between GCC and Glibc?

The _GL_... macro is part of Gnulib.

So, a conflict between the copy of Gnulib that Emacs has, and glibc.
-- 
Arsen Arsenović
signature.asc (application/pgp-signature, 418 B)
-----BEGIN PGP SIGNATURE-----

iQECBAEWCgCqFiEE/uKz0RP8AKMWLWBhUsKUMB6ixJMFAmqAuCEbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRUUyQjNEMTEzRkMwMEEzMTYyRDYw
NjE1MkMyOTQzMDFFQTJDNDkzEBxhcnNlbkBhYXJzZW4ubWUACgkQUsKUMB6ixJMT
6QD8DwLNL039bxfOCZM/PWK13ZEa4cZmZCam+xGFbYP3xWsA/1ZTp+4wxmCVwUf+
BTup4yh2D4b8lJwHZD0INbtmSFIH
=tAlH
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.