Date: Sun, 26 Feb 2012 14:25:05 +0000 From: Alexander Best <arundel@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Dimitry Andric <dim@freebsd.org> Subject: Re: svn commit: r232074 - head/sys/cam/ctl Message-ID: <20120226142505.GA63828@freebsd.org> In-Reply-To: <20120225061506.C2626@besplex.bde.org> References: <201202232134.q1NLYEq5024067@svn.freebsd.org> <20120224093807.GA88853@freebsd.org> <4F476FEA.1090004@FreeBSD.org> <20120224112224.GA13109@freebsd.org> <20120225061506.C2626@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat Feb 25 12, Bruce Evans wrote:
> On Fri, 24 Feb 2012, Alexander Best wrote:
>
> >On Fri Feb 24 12, Dimitry Andric wrote:
> >>On 2012-02-24 10:38, Alexander Best wrote:
> >>>which will turn all -Wformat-invalid-specifier and -Wformat-extra-args
> >>>errors
> >>>into warnings (because clang tot doesn't support -fformat-extensions)?
> >>
> >>It would be better to push our format extensions upstream, I think.
> >>Though the option should probably be renamed to something else, e.g.
> >>-ffreebsd-extensions, or such.
>
> It is only for format extensions. The idea is that a C compiler that
> supports warning about unsupported printf formats must warn about
> uses of format extensions (no matter whose they are) unless instructed
> not to do so. It seems excessive to have separate flags
> -fbsd-format-extensions -ffreebsd-format-extensions
> -fotherbsd-format-extensions -fgnu-format-extensions
> -flinux-format-extensions ..., so I used a single flag. If
> -fbsd-format-extensions existed, then it would have only %b as an
> extension.
>
> Anyway, clang already supports -fformat-extensions. The following
> compiles with this, but fails messily without it:
>
> % #include <stdio.h>
> %
> % void
> % foo(void)
> % {
> % printf("0x%b\n", 1, "\1foo");
> % }
>
> gcc (FreeBSD-gcc) complains about %#b, but clang doesn't. I don't know
> if %#b is valid, but it should be.
>
> >i'm still confused regarding the actual politics regarding this change.
> >everytime this comes up i get a different answer. the last one was that
> >since
> >the special printf format is only used for kernel code, the
> >-fformat-extensions
> >code within clang base shouldn't be pushed upstream.
>
> Is it only the FreeBSD version of clang that has it? Does FreeBSD has any
> other significant local changes? The flag should be push upstream, but
> there are likely to always be OS-specific details. For example, if %#b
> is indeed invalid and someone fixes the kernel to support it, you don't
> want to have to wait for the upstream sources to be synchronized before
> using %#b.
yes. only the clang version that ships with the freebsd src has support for
-fformat-extensions, however i couldn't find any referrence to it in the
clang(1) manual page. so it seems the support was only hacked into the clang
source and the manual page wasn't updated.
getting these changes pushed upstream would be nice. it's very likely that
the clang folks will rename -fformat-extensions to something else, but it
shouldn't be a big problem handling the different flag names in some *.mk
file.
i don't know, if the freebsd of clang has any other major differences compared
to the vendor version. maybe the freebsd-clang wiki page has some details about
this matter (or will direct you to people who know the answer).
cheers.
alex
>
> Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120226142505.GA63828>