[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] Upgrade to C'90 as our minimum C language

From: Stefan <luke1410_at_posteo.de>
Date: Sun, 24 Sep 2017 20:58:41 +0200

On 24/09/2017 19:55, Branko Čibej wrote:
> On 24.09.2017 11:36, Stefan wrote:
>> On 22/09/2017 13:29, Branko Čibej wrote:
>>> On 22.09.2017 13:18, Julian Foad wrote:
>>>> Julian Foad wrote:
>>>>> When we released Subversion 1.0 in 2004, we were still thinking we had
>>>>> better not use C'90 because it was only 14 years old and, you know,
>>>>> people need to be able to compile svn on systems of a reasonable age.
>>>>> So we had a "strict C'89" policy. No "//" comments, for example.
>>>>> Now C'99 is 18 years old and C'90 is, ahem, 27 years old. Does anybody
>>>>> else feel like we're trapped in the dark ages? The only reason not to
>>>>> upgrade is our personal fear of "rocking the boat", it seems to me.
>>>>> Let's just do it?
>>>>> I know there is a problem with Microsoft not supporting C'99. C'90
>>>>> should be fine though, and some of C'99 if we want to.
>>>> Oops, I misremembered that C89==C90, while C99 is the one that brings new features.
>>>> And Brane is pointing out on IRC lots of difficulties...
>>>> :-(
>>> Yes, we've had this discussion before, and the difficulties remain. :)
>>> -- Brane
>> Maybe we'd consider changing our view on this topic a bit and rather
>> than increment the source compatibility from C89/C90 to C99 change the
>> project to state compatibility based on a chosen compiler set plus all
>> compilers which are full C99 aware?
>> I.e. we'd declare project compatibility to support:
>> - any fully C99 compliant compiler
>> - VS: 2010-2017
> MSVC does not support C99. In C mode, it implements a subset of some
> things that look like C99 features but IIRC the semantics are subtly
> different in certain cases. That's a good way to grow subtle bugs.
Just to make clear what I meant here (pls be aware that I'm *not*
objecting to your point of staying with C89):
I'm aware that the MSVC C compiler is not supporting C99 and that the
C++ compiler is not supporting the full subset of C99 and I also read of
these subtle changes in certain edge cases.
The list I gave above was meant to suggest that we support any compiler
which is fully C99-compliant PLUS a subset of compilers where we know
which don't support the full C99-subset but support the standard "good
enough" so they'll just work fine with SVN.

The point here is that IMHO either we are changing our view on this
part, or accept the fact that we'll be stuck with C89 for the
foreseeable future.
>> - GCC: 2.7-7.2
>> - Clang: xxx-xxx
>> -xxxxxx
>> We then basically limit ourselves to the feature set which is supported
>> by our chosen compiler set.
> We don't even know how many different compilers are used to build
> Subverison, and we certainly don't have access to all of them. That's
> why programming languages get standardized in the first place: so you
> don't have to build your code with 50 different compilers just to make a
> list of what works.
> -- Brane

I understand your point. Just to get my point through a bit better:
We don't have to build our code with 50 different compilers. The sole
idea is that any C99-compliant compiler will work. In addition to this
we'll make exceptions here to still support compilers which are not
fully C99-complient (like VS 2010). Effectively this means that we'll
use a subset of C99 (for starters: C89 + //-comments). The code base is
then still fully C99-compliant and the subset of the C99-standard we use
is basically defined by the set of C99-features our "chosen compiler
suite" supports.

Yes, this is then breaking things for compilers which don't support C99
and are not in our "chosen compiler suite". To limit the practical
impact to downstream users, we should certainly do a quick survey to get
an idea which compilers are used out there in practice with SVN.

TBH: I'm also not sure if all the compilers which SVN is build with also
support the full C89 standard without any
limitations/restrictions/edge-case-quirks either; still this doesn't
seem to be an issue for us - so what makes the limitation in
C99-compliance for compilers different?

But maybe, we are really having this discussion a bit prematurely... It
sounds crazy and ironic writing this (given that C99 is 18 years old)
--- however looking at the table of supported C99-standard features in
compilers, none of the big compilers (Intel, GCC, MSVC, Clang, etc.) has
fully adapted the whole standard. (rhetoric question) On the other side:
if none of these compiler vendors adapted the full feature set just
after 18 years, would I honestly consider that things are (ever) going
to change?

Received on 2017-09-24 20:58:59 CEST

This is an archived mail posted to the Subversion Dev mailing list.