Hi,
On Mon, 2022-10-31 at 11:46 +0100, Jonathan Wakely wrote:
> Never ever do that. The __USE_xxx macros are internal, for glibc to
> use. You should not ever check them or define them.
right, right, it was only a hackish dirty quick attempt to make it
compile. I won't do it, if I knew
On Wed, 26 Oct 2022 at 13:24, Milan Crha wrote:
> Looking into the db.h file, it has there a comment that it can add the
> `u_int`, when the system doesn't provide it, but that related block is
> empty in Fedora. More interestingly, even when I add `#define
> __USE_MISC 1` at the very top of the
On Wed, Oct 26, 2022 at 09:33:34AM +0200, Jakub Jelinek wrote:
> On Wed, Oct 26, 2022 at 07:06:43AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > == User Experience ==
> > > User experience does not change.
> >
> > "The new default for C standard is -c99. Users who want to use
> > an older
Dne 27. 10. 22 v 6:57 Florian Weimer napsal(a):
* Kevin Fenzi:
On Wed, Oct 26, 2022 at 10:23:40AM +0200, Florian Weimer wrote:
* Zbigniew Jędrzejewski-Szmek:
More recently, I was explicitly told not to keep the compiler changes on
a branch in Fedora dist-git.
It is not really possible to
* Kevin Fenzi:
> On Wed, Oct 26, 2022 at 10:23:40AM +0200, Florian Weimer wrote:
>> * Zbigniew Jędrzejewski-Szmek:
>>
>> > On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:
>
> ...snip...
>
>> >> == How To Test ==
>> >
>> > As discussed by others, this needs to explain how to opt-in
On Wed, Oct 26, 2022 at 10:23:40AM +0200, Florian Weimer wrote:
> * Zbigniew Jędrzejewski-Szmek:
>
> > On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:
...snip...
> >> == How To Test ==
> >
> > As discussed by others, this needs to explain how to opt-in for early
> > testing, and
On Wed, 2022-10-26 at 13:59 +0100, Daniel P. Berrangé wrote:
> Note that in an earlier message in this thread replying to my
> question, Florian pointed out that using -std is not actually
> the way to test this.
Hi,
I see. I did read several messages in this thread, but definitely not
On 10/26/22 02:58, Florian Weimer wrote:
* Richard W. M. Jones:
On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:
Neither change is trivial to implement because introducing errors for
these constructs (as required by C99) alters the result of autoconf
configure checks. Quite a few
I frankly love this change. For along time I wanted a way to catch such
extensions and non stadard behaviour. For the long term, we could
create 3 macros, legacy for old unmainatined code (the -std=c89),
standard which will be the result of this porting and a future one with
some bonus flags.
On Wed, Oct 26, 2022 at 02:18:02PM +0200, Milan Crha wrote:
> When I try to compile this simple program:
>
> #include
> int main(void) { db_create(NULL, NULL, 0); return 0; }
>
> (which is part of the project's "can build" test to verify the thing is
> properly installed in the system)
On Wed, 2022-10-26 at 14:18 +0200, Milan Crha wrote:
> when I compile it as:
>
> gcc -std=c99 -Wall -Wextra test.c -o test -ldb
>
> I get an error:
>
> In file included from test.c:1:
> /usr/include/db.h:1098:9: error: unknown type name ‘u_int’
>
> and tons of related warning/error
On Wed, 2022-10-26 at 11:09 +0200, Florian Weimer wrote:
> There will be a few generic issues in build tools that when address
> fix multiple packages
Hi,
I've been interested in a check of a project I maintain and I stopped
very soon on Fedora 37 with
gcc-12.2.1-2.fc37.x86_64
* Alexander Sosedkin:
> On Tue, Oct 25, 2022 at 7:42 PM Florian Weimer wrote:
>>
>> * Alexander Sosedkin:
>>
>> > Since it's a build-time-only change,
>> > can it be rolled out under controlled pressure like this?
>> >
>> > 1. every package explicitly opts out (with some macro in specfile, IDK)
On 26. 10. 22 13:44, Miro Hrončok wrote:
On 26. 10. 22 11:09, Florian Weimer wrote:
There will be a few generic issues in build tools that when address fix
multiple packages, like the unfortunate has_function() implementation in
Python's setuptools/distutils.
Do you have details for this?
On 26. 10. 22 11:09, Florian Weimer wrote:
There will be a few generic issues in build tools that when address fix
multiple packages, like the unfortunate has_function() implementation in
Python's setuptools/distutils.
Do you have details for this?
--
Miro Hrončok
--
Phone: +420777974800
IRC:
* Vít Ondruch:
> So what is the current status? How many packages are going to be
> affected by this change? How are we going to track the progress?
I see an unaudited rebuild failure rate of about 10% for rebuilds of
source packages that produce arch-full binary packages. This number
does not
* Richard W. M. Jones:
> On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:
>> Neither change is trivial to implement because introducing errors for
>> these constructs (as required by C99) alters the result of autoconf
>> configure checks. Quite a few such checks use an implicitly
So what is the current status? How many packages are going to be
affected by this change? How are we going to track the progress?
Vít
Dne 25. 10. 22 v 16:05 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/PortingToModernC.
This document represents a proposed Change. As part of
* Stephen Gallagher:
> ...
>> > Concretely, as an upstream maintainer, what should they do to test
>> > the behaviour of their code ? Is there more to it than just
>> > setting CFLAGS="-std=gnu99", if they want to validate this in their
>> > upstream CI ahead of GCC 14 arriving ?
>>
>> It's
* Jakub Jelinek:
> -Werror=implicit -Werror=implicit-function-declaration
> -Werror=old-style-definition
> will reject these even now. Though, I think -Wold-style-definition warns
> even about the no argument case which in C2X is the same as in C++ - ()
> being equivalent to (void).
In
* Zbigniew Jędrzejewski-Szmek:
> On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/PortingToModernC.
>
> Line-by-line review:
>
>> == Summary ==
>> Back in 1999, a new revision of the C standard removed several
>> backwards compatibility
On Wed, Oct 26, 2022 at 07:06:43AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > == User Experience ==
> > User experience does not change.
>
> "The new default for C standard is -c99. Users who want to use
> an older standard need to specify something like -c89." (???)
It is -std=c89/-std=gnu89
On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/PortingToModernC.
Line-by-line review:
> == Summary ==
> Back in 1999, a new revision of the C standard removed several
> backwards compatibility features. However, GCC still accepts these
>
...
> > Concretely, as an upstream maintainer, what should they do to test
> > the behaviour of their code ? Is there more to it than just
> > setting CFLAGS="-std=gnu99", if they want to validate this in their
> > upstream CI ahead of GCC 14 arriving ?
>
> It's -Werror=implicit-int
On 25. 10. 22 16:05, Ben Cotton wrote:
== Summary ==
Back in 1999, a new revision of the C standard removed several
backwards compatibility features. However, GCC still accepts these
obsolete constructs by default. Support for these constructs is
confusing to programmers and potentially affect
On Tue, Oct 25, 2022 at 7:42 PM Florian Weimer wrote:
>
> * Alexander Sosedkin:
>
> > Since it's a build-time-only change,
> > can it be rolled out under controlled pressure like this?
> >
> > 1. every package explicitly opts out (with some macro in specfile, IDK)
> > 2. switch gets flipped,
* Alexander Sosedkin:
> Since it's a build-time-only change,
> can it be rolled out under controlled pressure like this?
>
> 1. every package explicitly opts out (with some macro in specfile, IDK)
> 2. switch gets flipped, nothing changes
> 3. bugs get filed to drop that macro and opt into new
On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:
> Neither change is trivial to implement because introducing errors for
> these constructs (as required by C99) alters the result of autoconf
> configure checks. Quite a few such checks use an implicitly declared
> `exit` function, for
* Ralf Corsépius:
> Am 25.10.22 um 16:05 schrieb Ben Cotton:
>> https://fedoraproject.org/wiki/Changes/PortingToModernC.
>> This document represents a proposed Change. As part of the Changes
>> process, proposals are publicly announced in order to receive
>> community feedback. This proposal will
On Tue, 2022-10-25 at 15:51 +0100, Daniel P. Berrangé wrote:
> I feel that this need to start on the prep work in F38/F39 is not
> very obvious from the F40 change proposal text.
I thought this was kinda very obviously implicit in the decision to
file an F40 Change proposal *now*.
--
Adam
On Tue, Oct 25, 2022 at 5:09 PM Daniel P. Berrangé wrote:
> So this change is talking about a new GCC landing in Fedora 40.
>
> To avoid massive disruption to Fedora though, we need to be doing
> work way earlier than the Fedora 40 dev cycle though.
>
> Identifying all the places where
Am 25.10.22 um 16:05 schrieb Ben Cotton:
https://fedoraproject.org/wiki/Changes/PortingToModernC.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if
Hi everyone,
Ben Cotton wrote:
Neither change is trivial to implement because introducing errors for
these constructs (as required by C99) alters the result of autoconf
configure checks. Quite a few such checks use an implicitly declared
`exit` function, for instance. These failures are not
* Neal Gompa:
> Why C99? Why not C18 instead? If we're going to go through this
> effort, we should ramp up like we did for C++ and bump all the way up
> to the latest published standard.
Getting past C99 is the hardest part because it's not possible (as far
as I can see) to do fully automated
* Daniel P. Berrangé:
> Good to see it mentions autoconf, as such tests were my immediate
> concern upon reading the intro.
>
> I presume the same problem will exist in other build systems that
> probe for features, both well known ones like cmake/meson/etc,
> but also home grown ones that are
* Ben Cotton:
> On Tue, Oct 25, 2022 at 10:05 AM Ben Cotton wrote:
>>
>> == Upgrade/compatibility impact ==
>> The change is expected to be transparent to those users who do not use
>> C compilers. No features are supposed to be added or removed as a
>> result. In fact, most of the porting
On Tue, Oct 25, 2022 at 10:51 AM Daniel P. Berrangé wrote:
>
> On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:
> > == Owner ==
> > * Name: [[User:fweimer| Florian Weimer]]
> > * Email: [mailto:fwei...@redhat.com| fwei...@redhat.com]
> >
> >
> > == Detailed Description ==
> > The most
On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:
> == Owner ==
> * Name: [[User:fweimer| Florian Weimer]]
> * Email: [mailto:fwei...@redhat.com| fwei...@redhat.com]
>
>
> == Detailed Description ==
> The most important change is the removal of implicit function
> declarations. This
On Tue, Oct 25, 2022 at 10:05 AM Ben Cotton wrote:
>
> == Upgrade/compatibility impact ==
> The change is expected to be transparent to those users who do not use
> C compilers. No features are supposed to be added or removed as a
> result. In fact, most of the porting effort focuses on avoiding
https://fedoraproject.org/wiki/Changes/PortingToModernC.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering
https://fedoraproject.org/wiki/Changes/PortingToModernC.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering
41 matches
Mail list logo
