On 24.09.2017 20:58, Stefan wrote:
> 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.
Just to make sure there are no misunderstandings; C99 is not a subset of
/any/ version of C++.
> 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.
What /I/ don't understand is why we're even having a discussion about
using // comments. Is it really that hard to type two extra chars per
comment, especially since any sane programming editor will add the
delimiters in for you anyway?
If the discussion were about more interesting features such as
*restrict*ed pointers or mixed statements and variable declaration or
*for*-scope variable declarations, that'd make some sense. But talking
about just "C90 + //" is, IMO, a waste of time.
> 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;
They do.
> 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.
AFAIK the only thing GCC and clang don't support are the standard
pragmas. Library issues are a different matter.
-- Brane
Received on 2017-09-24 21:56:45 CEST