Deprecation of C89?

Deprecation of C89?

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 888 bytes --]

Hi!

I was just wondering if there are any plans to drop support of C89 (and
gnu89) at any point in the future.  I didn't find any such discussion in
the mailing list.

That change would probably break very ancient code (implicit int, implicit
function declarations, ...), but such code is very likely to have been
updated in the last several decades to be at least compatible with C99, so
I don't expect that much breakage.

Most big projects have already migrated, with only a few still resisting
(curl comes to mind).  But again, I think they use a subset that would
compile under C99 with little or no modification.

I guess supporting C89 keeps a lot of extra complexity in GCC's source code
itself, and maybe even hinders some optimizations.

Cheers,
Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Deprecation of C89?

[Ian Lance Taylor]

On Thu, Jun 1, 2023 at 3:52 PM Alejandro Colomar via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> I was just wondering if there are any plans to drop support of C89 (and
> gnu89) at any point in the future.  I didn't find any such discussion in
> the mailing list.
>
> That change would probably break very ancient code (implicit int, implicit
> function declarations, ...), but such code is very likely to have been
> updated in the last several decades to be at least compatible with C99, so
> I don't expect that much breakage.
>
> Most big projects have already migrated, with only a few still resisting
> (curl comes to mind).  But again, I think they use a subset that would
> compile under C99 with little or no modification.
>
> I guess supporting C89 keeps a lot of extra complexity in GCC's source code
> itself, and maybe even hinders some optimizations.

We just had a long thread in which several people objected strongly to
just making the use of certain old C constructs an error by default
(https://gcc.gnu.org/pipermail/gcc/2023-May/241264.html).  If there
are strong objections to making these constructs into errors, I think
there would be even stronger objections to removing support for C89
entirely.

Ian

Re: Deprecation of C89?

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 4997 bytes --]

Hi Ian, Florian, Sam,

On 6/2/23 02:26, Ian Lance Taylor wrote:
> On Thu, Jun 1, 2023 at 3:52 PM Alejandro Colomar via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
>>
>> I was just wondering if there are any plans to drop support of C89 (and
>> gnu89) at any point in the future.  I didn't find any such discussion in
>> the mailing list.
>>
>> That change would probably break very ancient code (implicit int, implicit
>> function declarations, ...), but such code is very likely to have been
>> updated in the last several decades to be at least compatible with C99, so
>> I don't expect that much breakage.
>>
>> Most big projects have already migrated, with only a few still resisting
>> (curl comes to mind).  But again, I think they use a subset that would
>> compile under C99 with little or no modification.
>>
>> I guess supporting C89 keeps a lot of extra complexity in GCC's source code
>> itself, and maybe even hinders some optimizations.
> 
> We just had a long thread in which several people objected strongly to
> just making the use of certain old C constructs an error by default
> (https://gcc.gnu.org/pipermail/gcc/2023-May/241264.html).  If there
> are strong objections to making these constructs into errors, I think
> there would be even stronger objections to removing support for C89
> entirely.

Thanks for pointing to that.  I'll +1 to Florian's proposal, and add
something.

C89 is basically C99 with added broken stuff such as implicit int,
implicit functions, and no stdint.  Not much more than that.  gnu89
also includes the "other" inline.  I would be happy with adding an
optable-out error for those as a first step, and one or two releases
later completely kill C89.

About doing something in the distros if upstream GCC doesn't do it:
I believe breaking a package in Fedora, Debian, and Gentoo will be
enough that most upstream projects will fix their bugs.  I don't
think packagers will have to do it themselves.  I believe that
patching distro's GCC to enable -Werror=... would already be a great
step.

I've have to deal with programmers that lived in a cave for the last
30 years, and believe that there's no issue with having a pointer 2
past the end of an array, as long as you "restore" it by subtracting
2 afterwards, and worse stuff, because it just works.  As was said in
that other thread, if GCC generates "working" code, they'll defend
that code.  Having an error by default for the most broken stuff
would probably help them see the light.

The only issue which can't be solved is compiling unmaintained
software that was written 30 years ago.  But if one is doing that,
they probably also have a system with a compiler written 30 years
ago.  I don't see why anyone would want to compile K&R code in
bleeding edge systems.  A VM is always available.  They can even
get an old GCC version.

Another point is that since this year, companies are already
stopping using C because of being unsafe.  I don't believe C being
unsafe, but C89 definitely *is*.  I don't think keeping it around is
doing anyone a favor.  In my job, they're requiring Rust for newly
written programs.  I hope we help prevent continuing down that road.

Florian, Sam, may I suggest that you patch/configure your GCC to have
those few -Werror=... enabled by default?  After one release with
that in Fedora and Gentoo, I guess it will be easier to merge it into
upstream GCC.  And a similar thing but a year later could be done
with C89.

I already ported shadow[1] from pre-C89 code to require C11 and
POSIX.1-2008, and it was relatively easy.  I am now porting zlib[2]
from pre-C89 code to require C89 (I wish I could raise that at least
to C99, but I'm not sure how much receptive the maintainer will be
without the compiler setting on fire).

[1]: <https://github.com/shadow-maint/shadow/issues/600>
     <https://github.com/shadow-maint/shadow/pull/477>
     <https://github.com/shadow-maint/shadow/pull/479>
     <https://github.com/shadow-maint/shadow/pull/480>
     <https://github.com/shadow-maint/shadow/pull/481>
     <https://github.com/shadow-maint/shadow/pull/489>
     <https://github.com/shadow-maint/shadow/pull/574>
     <https://github.com/shadow-maint/shadow/pull/601>
     <https://github.com/shadow-maint/shadow/pull/602>
     <https://github.com/shadow-maint/shadow/pull/615>
     <https://github.com/shadow-maint/shadow/pull/616>
     <https://github.com/shadow-maint/shadow/pull/617>

     POSIX.1-2008 was a bit more complex, but C99 should be trivial.

     The result was a much cleaner code base, with a lot less cpp(1),
     and a net removal of thousands of lines of code.  While cleaning
     up the code, several hidden bugs were made shallow, and thus
     fixed.

[2]: <https://github.com/madler/zlib/pull/817>

Thanks!
Alex

> 
> Ian

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Deprecation of C89?

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 5297 bytes --]

Hi Alex,

Alejandro Colomar via Gcc-help <gcc-help@gcc.gnu.org> writes:

> Thanks for pointing to that.  I'll +1 to Florian's proposal, and add
> something.
>
> C89 is basically C99 with added broken stuff such as implicit int,
> implicit functions, and no stdint.  Not much more than that.  gnu89
> also includes the "other" inline.  I would be happy with adding an
> optable-out error for those as a first step, and one or two releases
> later completely kill C89.

I don't think killing C89 is very useful.  As you said, it's not too
different to C99; however, we shouldn't be promoting its deficiencies
into newer language standards (but you've seen the thread on that :-) ).

> About doing something in the distros if upstream GCC doesn't do it:
> I believe breaking a package in Fedora, Debian, and Gentoo will be
> enough that most upstream projects will fix their bugs.  I don't
> think packagers will have to do it themselves.  I believe that
> patching distro's GCC to enable -Werror=... would already be a great
> step.

I'm not sure it's a good idea to change behavior away from upstream
decisions in our downstream.  Keep in mind, though, that we (Gentoo)
have CI infrastructure and developers already testing with stricter
flags.

> I've have to deal with programmers that lived in a cave for the last
> 30 years, and believe that there's no issue with having a pointer 2
> past the end of an array, as long as you "restore" it by subtracting
> 2 afterwards, and worse stuff, because it just works.  As was said in
> that other thread, if GCC generates "working" code, they'll defend
> that code.  Having an error by default for the most broken stuff
> would probably help them see the light.

C89 (similar to GNU C 89) doesn't prevent writing correct code, though,
even if it lacks some facilities.

> The only issue which can't be solved is compiling unmaintained
> software that was written 30 years ago.  But if one is doing that,
> they probably also have a system with a compiler written 30 years
> ago.  I don't see why anyone would want to compile K&R code in
> bleeding edge systems.  A VM is always available.  They can even
> get an old GCC version.

Sadly, some modern codebases are C89 (libvp8 comes to mind.. don't ask,
because I don't know why either ;) ).

But, old codebases can be written in a way which is correct, so I don't
see why removing C89 would help there.

> Another point is that since this year, companies are already
> stopping using C because of being unsafe.  I don't believe C being
> unsafe, but C89 definitely *is*.  I don't think keeping it around is
> doing anyone a favor.  In my job, they're requiring Rust for newly
> written programs.  I hope we help prevent continuing down that road.

I'm afraid this won't convince folks.  People treat C++ the same as
pre-standard C, even though it's quite easy to write code that prevents
errors in C++ in a way similar to Rust.

I also don't see a significant difference between C89 (and some -Werror
flags) and C99 in this regard.

> Florian, Sam, may I suggest that you patch/configure your GCC to have
> those few -Werror=... enabled by default?  After one release with
> that in Fedora and Gentoo, I guess it will be easier to merge it into
> upstream GCC.  And a similar thing but a year later could be done
> with C89.

We'd like to do this in GCC 14 anyway (in 99+).

> I already ported shadow[1] from pre-C89 code to require C11 and
> POSIX.1-2008, and it was relatively easy.  I am now porting zlib[2]
> from pre-C89 code to require C89 (I wish I could raise that at least
> to C99, but I'm not sure how much receptive the maintainer will be
> without the compiler setting on fire).
>
> [1]: <https://github.com/shadow-maint/shadow/issues/600>
>      <https://github.com/shadow-maint/shadow/pull/477>
>      <https://github.com/shadow-maint/shadow/pull/479>
>      <https://github.com/shadow-maint/shadow/pull/480>
>      <https://github.com/shadow-maint/shadow/pull/481>
>      <https://github.com/shadow-maint/shadow/pull/489>
>      <https://github.com/shadow-maint/shadow/pull/574>
>      <https://github.com/shadow-maint/shadow/pull/601>
>      <https://github.com/shadow-maint/shadow/pull/602>
>      <https://github.com/shadow-maint/shadow/pull/615>
>      <https://github.com/shadow-maint/shadow/pull/616>
>      <https://github.com/shadow-maint/shadow/pull/617>

Thank you!  This work is quite valuable.  I do suspect a more
conservative response from zlib, though.

>      POSIX.1-2008 was a bit more complex, but C99 should be trivial.
>
>      The result was a much cleaner code base, with a lot less cpp(1),
>      and a net removal of thousands of lines of code.  While cleaning
>      up the code, several hidden bugs were made shallow, and thus
>      fixed.
>
> [2]: <https://github.com/madler/zlib/pull/817>
>
> Thanks!
> Alex

I'd like to note that I'm not advocating for the prolonged use of C89,
just for keeping compatibility where the cost is low (and I strongly
oppose forward-porting the messy parts of C89 into C99+ as GCC has done
so far).

(PS: this topic is likely more appropriate for gcc@gcc.gnu.org)

Have a lovely day :)
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Deprecation of C89?

[David Brown]

On 02/06/2023 00:50, Alejandro Colomar via Gcc-help wrote:
> Hi!
> 
> I was just wondering if there are any plans to drop support of C89 (and
> gnu89) at any point in the future.  I didn't find any such discussion in
> the mailing list.
> 
> That change would probably break very ancient code (implicit int, implicit
> function declarations, ...), but such code is very likely to have been
> updated in the last several decades to be at least compatible with C99, so
> I don't expect that much breakage.
> 
> Most big projects have already migrated, with only a few still resisting
> (curl comes to mind).  But again, I think they use a subset that would
> compile under C99 with little or no modification.
> 
> I guess supporting C89 keeps a lot of extra complexity in GCC's source code
> itself, and maybe even hinders some optimizations.
> 
> Cheers,
> Alex
> 

The majority of the C89/C90 -> C99 changes were additions to the 
language, so that code which was valid C89/C90 would be equally valid 
and have the same semantics when viewed as C99.  Some things, such as 
implicit int, were already deprecated (or obsolescent - I forget which) 
in C89/C90 and removed in C99.  But there are other things that changed, 
such as the type of some constants.  And the addition of new identifiers 
to some of the standard headers could conflict with user code.

It is rare that code which compiles with "-std=c90" would not also 
compile with "-std=c99" and have identical semantics, but it definitely 
can happen.  And backwards compatibility with existing code is a very 
strong argument for any decision about C tools.

And in some fields, C89/C90 (or "ANSI C", as it is often called, 
somewhat inaccurately) is still the standard.  People working with such 
code want to use "-std=c90 -Wpedantic" to be as sure as they can be that 
the code will be usable with every C compiler, even old or obscure ones.

David

Re: Deprecation of C89?

[Segher Boessenkool]

Hi!

On Fri, Jun 02, 2023 at 08:37:30AM +0200, Arsen Arsenović via Gcc-help wrote:
> Alejandro Colomar via Gcc-help <gcc-help@gcc.gnu.org> writes:
> > C89 is basically C99 with added broken stuff such as implicit int,
> > implicit functions, and no stdint.

Not "added" of course.  This kind of misrepresentation hurts your
arguments.

> I don't think killing C89 is very useful.  As you said, it's not too
> different to C99; however, we shouldn't be promoting its deficiencies
> into newer language standards (but you've seen the thread on that :-) ).

We would first have to kill off support for K&R C.  Which isn't going to
happen any time soon either: it is there, maintenance cost is minimal,
removing it would not buy us much at all (because we need to keep most
of what you hope we might remove for supporting other languages).

> > About doing something in the distros if upstream GCC doesn't do it:
> > I believe breaking a package in Fedora, Debian, and Gentoo will be
> > enough that most upstream projects will fix their bugs.  I don't
> > think packagers will have to do it themselves.  I believe that
> > patching distro's GCC to enable -Werror=... would already be a great
> > step.
> 
> I'm not sure it's a good idea to change behavior away from upstream
> decisions in our downstream.  Keep in mind, though, that we (Gentoo)
> have CI infrastructure and developers already testing with stricter
> flags.

It already is painful that some distros ship severely patched GCC and
their users complain to us.  Changing defaults is WRONG: if people do
not just ignore you after that lunacy everyone else can not rely on the
default anymore, and has to specify the choice every time.

> > Another point is that since this year, companies are already
> > stopping using C because of being unsafe.

That is just a fad.  All computer languages are "unsafe", some are
easier to make mistakes in than others, but experience and habit and
yes, *good taste* of the programmer matter hundreds of times more.

>>  I don't believe C being
> > unsafe, but C89 definitely *is*.  I don't think keeping it around is
> > doing anyone a favor.  In my job, they're requiring Rust for newly
> > written programs.  I hope we help prevent continuing down that road.
> 
> I'm afraid this won't convince folks.  People treat C++ the same as
> pre-standard C,

It has as many sharp edges, yes!

> I also don't see a significant difference between C89 (and some -Werror
> flags) and C99 in this regard.

-Werror is always *WRONG*.  The compiler should not refuse to compile
perfectly valid code.  It only makes people annoyed and use "-w" more.

People not reading the compiler warnings is a people problem.  Solve
that the usual way you do that in your organisation: gentle nudging,
public shaming, whatever you do -- but do not punish innocent
bystanders.

(It is fine to change GCC to do an error instead of a warning when it
has detected an actual problem, but not when it isn't sure, and never
using -Werror.)

> I'd like to note that I'm not advocating for the prolonged use of C89,
> just for keeping compatibility where the cost is low (and I strongly
> oppose forward-porting the messy parts of C89 into C99+ as GCC has done
> so far).

Yup.  The cost (to users, including ourselves) from removing C90 far
outweighs its benefits (mostly to GCC developers, and those benefits are
extremely minor anyway).

It is *normal* to deal with code twenty or thirty or more years old.
Useful code has a long lifetime.

</rant>

:-)


Segher

Re: Deprecation of C89?

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 4781 bytes --]

Hi Segher,

Segher Boessenkool <segher@kernel.crashing.org> writes:

> Hi!
>
> On Fri, Jun 02, 2023 at 08:37:30AM +0200, Arsen Arsenović via Gcc-help wrote:
>> Alejandro Colomar via Gcc-help <gcc-help@gcc.gnu.org> writes:
>> > C89 is basically C99 with added broken stuff such as implicit int,
>> > implicit functions, and no stdint.
>
> Not "added" of course.  This kind of misrepresentation hurts your
> arguments.
>
>> I don't think killing C89 is very useful.  As you said, it's not too
>> different to C99; however, we shouldn't be promoting its deficiencies
>> into newer language standards (but you've seen the thread on that :-) ).
>
> We would first have to kill off support for K&R C.  Which isn't going to
> happen any time soon either: it is there, maintenance cost is minimal,
> removing it would not buy us much at all (because we need to keep most
> of what you hope we might remove for supporting other languages).

I agree.  Defaults can hurt, explicitly requested legacy support
doesn't (notwithstanding maintenance overhead and such).

>> > About doing something in the distros if upstream GCC doesn't do it:
>> > I believe breaking a package in Fedora, Debian, and Gentoo will be
>> > enough that most upstream projects will fix their bugs.  I don't
>> > think packagers will have to do it themselves.  I believe that
>> > patching distro's GCC to enable -Werror=... would already be a great
>> > step.
>> 
>> I'm not sure it's a good idea to change behavior away from upstream
>> decisions in our downstream.  Keep in mind, though, that we (Gentoo)
>> have CI infrastructure and developers already testing with stricter
>> flags.
>
> It already is painful that some distros ship severely patched GCC and
> their users complain to us.  Changing defaults is WRONG: if people do
> not just ignore you after that lunacy everyone else can not rely on the
> default anymore, and has to specify the choice every time.
>
>> > Another point is that since this year, companies are already
>> > stopping using C because of being unsafe.
>
> That is just a fad.  All computer languages are "unsafe", some are
> easier to make mistakes in than others, but experience and habit and
> yes, *good taste* of the programmer matter hundreds of times more.
>
>>>  I don't believe C being
>> > unsafe, but C89 definitely *is*.  I don't think keeping it around is
>> > doing anyone a favor.  In my job, they're requiring Rust for newly
>> > written programs.  I hope we help prevent continuing down that road.
>> 
>> I'm afraid this won't convince folks.  People treat C++ the same as
>> pre-standard C,
>
> It has as many sharp edges, yes!

... but some extra rubber feet in the box ;)  (and a better type system)

>> I also don't see a significant difference between C89 (and some -Werror
>> flags) and C99 in this regard.
>
> -Werror is always *WRONG*.  The compiler should not refuse to compile
> perfectly valid code.  It only makes people annoyed and use "-w" more.

I was referring to -Werror=implicit-function-declaration,
-Werror=implicit-int, -Werror=incompatible-function-pointer-types, and
-Werror=strict-prototypes, which don't share the usual problems of
-Werror (by being explicit, not something that's likely to change, and
reasonable practice IMO :-) ).

But, at any rate, the thing I was getting at here is that C89 is not
very fundamentally different to C99 (in the ways in which C++ *can* be).

> People not reading the compiler warnings is a people problem.  Solve
> that the usual way you do that in your organisation: gentle nudging,
> public shaming, whatever you do -- but do not punish innocent
> bystanders.

I agree.  We have a tree-wide policy of disabling -Werror for that
reason.

> (It is fine to change GCC to do an error instead of a warning when it
> has detected an actual problem, but not when it isn't sure, and never
> using -Werror.)

I believe that qualifies the above as fine :-), perhaps the only one
which might pose an actual problem (rather than diagnosing one) is
-Wincompatible-function-pointer-types, when some FP punting is involved.

>> I'd like to note that I'm not advocating for the prolonged use of C89,
>> just for keeping compatibility where the cost is low (and I strongly
>> oppose forward-porting the messy parts of C89 into C99+ as GCC has done
>> so far).
>
> Yup.  The cost (to users, including ourselves) from removing C90 far
> outweighs its benefits (mostly to GCC developers, and those benefits are
> extremely minor anyway).
>
> It is *normal* to deal with code twenty or thirty or more years old.
> Useful code has a long lifetime.
>
> </rant>
>
> :-)

:-)

Have a lovely day!
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Deprecation of C89?

[Xi Ruoyao]

On Fri, 2023-06-02 at 20:52 +0200, Arsen Arsenović via Gcc-help wrote:
> I was referring to -Werror=implicit-function-declaration,
> -Werror=implicit-int, -Werror=incompatible-function-pointer-types, and
> -Werror=strict-prototypes, which don't share the usual problems of
> -Werror (by being explicit, not something that's likely to change, and
> reasonable practice IMO :-) ).

-Werror=strict-prototypes is too strict IMO.  It will even break:

int test() { return 0; }

But the entire point of the C2X change about the prototype w/o a
parameter list is to make such thing reasonable, isn't it?

I guess we actually want a new warning option, like:

extern int f();             // ok
int g() { return f(); }     // ok
int h() { return f(1, 2); } // { dg-warning "the usage of non-strict prototype will be rejected by C2x" }

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: Deprecation of C89?

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]


Xi Ruoyao <xry111@xry111.site> writes:

> On Fri, 2023-06-02 at 20:52 +0200, Arsen Arsenović via Gcc-help wrote:
>> I was referring to -Werror=implicit-function-declaration,
>> -Werror=implicit-int, -Werror=incompatible-function-pointer-types, and
>> -Werror=strict-prototypes, which don't share the usual problems of
>> -Werror (by being explicit, not something that's likely to change, and
>> reasonable practice IMO :-) ).
>
> -Werror=strict-prototypes is too strict IMO.  It will even break:
>
> int test() { return 0; }

Indeed, but I tend not to mind this in my code (falling into the latter
clause in parentheses above).

> But the entire point of the C2X change about the prototype w/o a
> parameter list is to make such thing reasonable, isn't it?
>
> I guess we actually want a new warning option, like:
>
> extern int f();             // ok
> int g() { return f(); }     // ok
> int h() { return f(1, 2); } // { dg-warning "the usage of non-strict prototype will be rejected by C2x" }

There might be relevant discussion on https://gcc.gnu.org/PR108694.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]