public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Rainer Orth <ro@cebitec.uni-bielefeld.de>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] libssp: Fix gets-chk.c compilation on Solaris
Date: Thu, 7 Dec 2023 13:59:46 +0100	[thread overview]
Message-ID: <ZXHBwicI4BmSo7FP@tucnak> (raw)
In-Reply-To: <yddh6kys0zi.fsf@CeBiTec.Uni-Bielefeld.DE>

On Mon, Dec 04, 2023 at 11:42:09AM +0100, Rainer Orth wrote:
> The recent warning patches broke the libssp build on Solaris:
> 
> /vol/gcc/src/hg/master/local/libssp/gets-chk.c: In function '__gets_chk':
> /vol/gcc/src/hg/master/local/libssp/gets-chk.c:67:12: error: implicit declaration of function 'gets'; did you mean 'getw'? [-Wimplicit-function-declaration]
>    67 |     return gets (s);
>       |            ^~~~
>       |            getw 
> /vol/gcc/src/hg/master/local/libssp/gets-chk.c:67:12: error: returning 'int' from a function with return type 'char *' makes pointer from integer without a cast [-Wint-conversion]       
>    67 |     return gets (s);
>       |            ^~~~~~~~
> /vol/gcc/src/hg/master/local/libssp/gets-chk.c:74:12: error: returning 'int' from a function with return type 'char *' makes pointer from integer without a cast [-Wint-conversion]
>    74 |     return gets (s);
>       |            ^~~~~~~~
> 
> The guard around the gets declaration in gets-chk.c is
> 
> #if !(!defined __USE_ISOC11                             \
>       || (defined __cplusplus && __cplusplus <= 201103L))
> extern char *gets (char *);
> #endif
> 
> __USE_ISOC11 is a glibc-only thing, while Solaris <iso/stdio_iso.h>
> declares gets like
> 
> #if __STDC_VERSION__ < 201112L && __cplusplus < 201402L
> extern char     *gets(char *) __ATTR_DEPRECATED;
> #endif
> 
> If one needs to check __USE_ISO11 at all, one certainly needs to check
> __STDC_VERSION__ to avoid breaking every non-glibc target.  Besides, I
> don't see what's the use of checking __cplusplus when compiling a C-only
> source file.  On top of all that, the double negation makes the guard
> unnecessarily hard to understand.
> 
> I really don't know if it's useful/appropriate to check __USE_ISOC11 and
> __cplusplus here at all; still I've left both for now.
> 
> Here's what I've used to complete the Solaris bootstrap.
> 
> Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11,
> x86_64-pc-linux-gnu, and x86_64-apple-darwin23.1.0.
> 
> -- 
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
> 
> 
> 2023-12-03  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
> 
> 	libssp:
> 	* gets-chk.c (gets): Avoid double negation.
> 	Also check __STDC_VERSION__ >= 201112L.
> 

> # HG changeset patch
> # Parent  334015ab01f6c0e5af821c1e9bc83b8677cc0bfb
> libssp: Fix gets-chk.c compilation on Solaris
> 
> diff --git a/libssp/gets-chk.c b/libssp/gets-chk.c
> --- a/libssp/gets-chk.c
> +++ b/libssp/gets-chk.c
> @@ -51,8 +51,9 @@ see the files COPYING3 and COPYING.RUNTI
>  # include <string.h>
>  #endif
>  
> -#if !(!defined __USE_ISOC11				\
> -      || (defined __cplusplus && __cplusplus <= 201103L))
> +#if (defined __STDC_VERSION__ && __STDC_VERSION__ >= 201112L)	\
> +     || !defined __USE_ISOC11					\
> +     || (defined __cplusplus && __cplusplus >= 201402L)

The above isn't equivalent.  Avoiding double negation would mean
#if (defined __USE_ISOC11				\
     && !(defined __cplusplus && __cplusplus <= 201103L))
or
#if (defined __USE_ISOC11				\
     && (!defined __cplusplus || __cplusplus > 201103L))
No?
__USE_ISOC11 is defined as
/* This is to enable the ISO C11 extension.  */
#if (defined _ISOC11_SOURCE || defined _ISOC2X_SOURCE \
     || (defined __STDC_VERSION__ && __STDC_VERSION__ >= 201112L))
# define __USE_ISOC11   1
#endif
where _ISOC11_SOURCE or _ISOC2X_SOURCE are defined whenever _GNU_SOURCE
is or when user defines them, or __USE_ISOC11 is also defined for
if __cplusplus >= 201703L.

Obviously, if you add that
  (defined __STDC_VERSION__ && __STDC_VERSION__ >= 201112L)
it will mean it will be prototyped always (as I think we compile it without
any -std= flags).

What about using what we had for glibc (or even better, expect gets
to be declared for glibc < 2.16) and use what you add for other libraries?
The file is written and compiled as C, so we don't need to bother with C++
though.
So
#if (defined (__GLIBC_PREREQ)						\
     ? (__GLIBC_PREREQ (2, 16) && defined (__USE_ISOC11))		\
     : (defined __STDC_VERSION__ && __STDC_VERSION__ >= 201112L))
?

>  extern char *gets (char *);
>  #endif

	Jakub


  parent reply	other threads:[~2023-12-07 12:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-04 10:42 Rainer Orth
2023-12-07 12:25 ` Rainer Orth
2023-12-07 12:59 ` Jakub Jelinek [this message]
2024-02-06 10:33   ` Rainer Orth
2024-02-06 10:38     ` Jakub Jelinek

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=ZXHBwicI4BmSo7FP@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ro@cebitec.uni-bielefeld.de \
    /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).