From owner-cvs-all  Sun Aug  8  5:14:39 1999
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2330114EC7; Sun,  8 Aug 1999 05:14:37 -0700 (PDT)
	(envelope-from bde@FreeBSD.org)
Received: (from bde@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id FAA57788;
	Sun, 8 Aug 1999 05:10:16 -0700 (PDT)
	(envelope-from bde@FreeBSD.org)
Message-Id: <199908081210.FAA57788@freefall.freebsd.org>
From: Bruce Evans <bde@FreeBSD.org>
Date: Sun, 8 Aug 1999 05:10:16 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/contrib/egcs/gcc c-common.c
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

bde         1999/08/08 05:10:16 PDT

  Modified files:
    contrib/egcs/gcc     c-common.c 
  Log:
  Don't accept %q length specifiers in the kernel (more precisely,
  if compiling with -fformat-extensions). Gcc's format checker never
  actually supported %q length specifiers.  It treats %q as an alias
  for %ll, which is correct if quad_t is long long (e.g., on i386's)
  and broken otherwise (e.g., on alphas).
  
  quad_t's currently should be printed in the same way that they
  already need to be printed to avoid compiler warnings on all
  supported systems: cast them to a standard type that is at least
  as large (long or long long) and use the length specifier for that
  (%l or %ll).  This is problematic since long long isn't standard
  yet.  C9x's intmax_t should be implemented soon.
  
  Don't accept %L length specifiers in the kernel either.  The only
  legitimate ones are for long doubles, but the kernel doesn't even
  support plain doubles.  (gcc bogusly accepts %Ld as an alias for
  %lld, and it sometimes prints "q" in error messages about "ll" and
  "L" length specifiers, becauses it represents all these specifiers
  as 'q'.)
  
  Revision  Changes    Path
                       



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message