From patchwork Wed Feb 18 12:04:30 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Polacek X-Patchwork-Id: 440949 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 67B05140079 for ; Wed, 18 Feb 2015 23:04:50 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; q=dns; s= default; b=i4aWWVnkYAZjmjWqzRk27wYWpKao1YcnSH2b4YWdRAcE8oe/nw860 hd7xDMSxEvy6hDh8y1nu6ut06RO2Z4J/D0FKchqxVIuYY8v3dC8ju7eh0o32gKkp r4anv2pcEdy+Awa9/+E6BIfanqfE6BBLw1lMQQ4knbXZur3d9M765Q= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; s= default; bh=gakGEECywV3X298EOhQjL69w8yw=; b=eNKYuOc5ghMkYKXBpr2C ZIDlrE7yVS0ryD0J70wrAYPZtHYwzc378prdq93fUxOrOhgW3orhlqR19aiV5SSB D9MKX4u/VzJF0tXe3gGmMTcqfr7kTTF9N6ePRyktjWVL/LVcRA6bvQK5hXr3QvJs 1atDyf9H1uNE14mdRldxfzY= Received: (qmail 31492 invoked by alias); 18 Feb 2015 12:04:42 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 31480 invoked by uid 89); 18 Feb 2015 12:04:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 18 Feb 2015 12:04:36 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1IC4Y0v031958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 18 Feb 2015 07:04:34 -0500 Received: from redhat.com ([10.40.204.30]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1IC4VoV014314 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 18 Feb 2015 07:04:34 -0500 Date: Wed, 18 Feb 2015 13:04:30 +0100 From: Marek Polacek To: GCC Patches Subject: [wwwdocs] Porting to again Message-ID: <20150218120430.GX23138@redhat.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) This is a revised version. I reworded the paragraph dealing with __STDC_VERSION__, made some clarifications wrt %a, and added some text wrt cpp -P issue. Ok? Marek Index: porting_to.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/porting_to.html,v retrieving revision 1.3 diff -u -r1.3 porting_to.html --- porting_to.html 10 Feb 2015 11:12:20 -0000 1.3 +++ porting_to.html 18 Feb 2015 12:01:50 -0000 @@ -24,6 +24,17 @@ manner. Additions and suggestions for improvement are welcome.

+

Preprocessor issues

+ +

The preprocessor started to emit line markers to properly distinguish +whether a macro token comes from a system header, or from a normal header +(see PR60723). +These new markers can cause intriguing problems, if the packages aren't ready +to handle them. To stop the preprocessor from generating the #line +directives, use the -P option, documented +here. +

+

C language issues

Default standard is now GNU11

@@ -251,6 +262,105 @@ ^ +

__STDC_VERSION__ macro

+ +

As the default mode changed to C11, the __STDC_VERSION__ +standard macro, introduced in C95, is now defined by default, and has +the value 201112L. + +Typically, this macro is used as in the following:

+ +

+  #if !defined __STDC_VERSION__ || __STDC_VERSION__ < 199901L
+    /* ... */
+  #else
+  # include <stdint.h>
+  #endif
+
+ +

You can check the macro using gcc -dM -E -std=gnu11 - < /dev/null | grep STDC_VER.

+ +

Different meaning of the %a *scanf conversion specification

+ +

In C89, the GNU C library supports dynamic allocation via the %as, +%aS, and %a[...] conversion specification; see + +this for more info. +But in C99, the a conversion specifier is a synonym for f +(float), so the compiler expects an argument of type float *. Different +meaning of %a is a change in semantics, and in combination with the +-Wformat warning option the compiler may emit additional warnings:

+ +

+  #include <stdio.h>
+
+  int
+  main (void)
+  {
+    char *s;
+    scanf ("%as", &s);
+  }
+
+ +
+q.c:7:10: warning: format '%a' expects argument of type 'float *', but argument 2 has type 'char **' [-Wformat=]
+  scanf ("%as", &s);
+         ^
+
+ +

To use the dynamic allocation conversion specifier in C99 and C11, specify +m as a length modifier, specified by POSIX.1-2008. That is, use +%ms or %m[...].

+ +

New warnings

+ +

Several new warnings have been added to the C front end. One of the new +warnings is that GCC now warns about non-standard predefined identifiers with +the -Wpedantic option. For instance:

+ +

+  void
+  foo (void)
+  {
+    const char *s = __FUNCTION__;
+  }
+
+ +
+q.c:4:19: warning: ISO C does not support '__FUNCTION__' predefined identifier [-Wpedantic]
+  const char *s = __FUNCTION__;
+                  ^
+
+ +

The fix is either to use the standard predefined identifier __func__ +(since C99), or to use the __extension__ keyword:

+ +


+  const char *s = __extension__ __FUNCTION__;
+
+ +

C++ language issues

+ +

Converting std::nullptr_t to bool

+ +

Converting std::nullptr_t to bool in the C++11 +mode now requires direct-initialization. This has been changed in +DR 1423. +As a consequence, the following is invalid:

+ +

+  bool b = nullptr;
+
+ +

but the following is valid:

+ +

+  bool b(nullptr);
+
+ +It is recommended to use true, resp. false keywords +in such cases. +

Links