From: duerst@... Date: 2018-12-13T08:08:52+00:00 Subject: [ruby-core:90498] [Ruby trunk Misc#15347] Require C99 Issue #15347 has been updated by duerst (Martin D��rst). shyouhei (Shyouhei Urabe) wrote: > duerst (Martin D��rst) wrote: > > So what I'm proposing is to use an option that says that we are on C90, and gives a warning for `//` comments and for declarations after statements and so no. > > This effectively kills 64 bit integer capabilities because there was no such thing like a 64 bit integer back in 1990. I agree we don't want to do this. > This can be okay for CI but not a realistic usage nowadays. Please do not do this by default. Then what about by default activating options that warn for `//` comments or for declarations after statements one by one? The list of warnings e.g. in gcc is very long, but I just found `-Wdeclaration-after-statement`. So I would definitely suggest that this warning is switched on as long as we require commits to conform to this and check this in CI. This warning alone would have avoided problems in two of my recent commits (one of them https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/66034, which was the reason this thread started). Unfortunately, I haven't found a warning specifically for `//` comments. > So the whole idea of this issue is not to stick to that old standards. Everybody in this thread are agreeing to move forward. I would suggest just abandoning C90. I am as much as you for moving ahead. But as long as we stay on C90 (for certain parts of the syntax), I want to make it easy for committers, both those who occasionally forget to avoid declarations after statements (like me) and those who help with cleanup (such as ko1 and k0kubun). ---------------------------------------- Misc #15347: Require C99 https://bugs.ruby-lang.org/issues/15347#change-75655 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal * Assignee: ---------------------------------------- ## Problem We've spent a lot of time for supporting C90 https://github.com/ruby/ruby/search?o=desc&q=c99&s=committer-date&type=Commits. It is not only time-consuming but also sometimes sacrifices readability like r66034 (today's commit). ## Suggestion Ruby 3 is planned to be released around 2020. As 30th anniversary of C90, it may be a good time to re-consider dropping support of C90 on the major version upgrade. ## Known issues * Microsoft Visual Studio C++ * We don't know which VC++ version supports which feature of C99: https://twitter.com/unak/status/1025937122161618944 (Japanese tweet) * Solaris * Solaris Studio 12.4 uses C89 on Solaris 10 by default [Bug #14200] * Solaris 10's GCC uses C90 by default [Bug #14751] * We don't know how well C99 support is supported on Solaris 10 or 11 Please comment to this ticket if you know more. ### Possible approaches * Investigate C99 features supported by VC++, document allowed C99 features in https://bugs.ruby-lang.org/projects/ruby/wiki/DeveloperHowTo, and somehow prepare CI environment that monitors conformity of it on AppVeyor or Azure Pipelines. * Solaris seems to support C99 but it's disabled by default. We might be able to enable that on configure and some features we want to use could work. * Notable information: Solaris 10 Extended Support ends Jan 2021 http://www.oracle.com/us/support/library/lifetime-support-hardware-301321.pdf. If we assume (of course, not decided yet) Ruby 3 is released in Dec 2020, it'll be just 1-month earlier of it. * Print warnings for future breakage on Ruby 3 when building Ruby 2.6 or 2.7, for some EOL platforms. ## Disclaimer I'm NOT intending to disrupt users by this. I just want to make it easier to maintain Ruby interpreter by allowing to use some useful and portable C99 features if and only if almost all Ruby users can compile Ruby interpreter with it by our efforts on build system. I don't know if it's feasible or not. I want to collect information of it and possibly give up to have the hope for using C99 if it's turned out to be too difficult. -- https://bugs.ruby-lang.org/ Unsubscribe: