[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: Branko Čibej <brane_at_apache.org>
Date: Sun, 24 Sep 2017 23:03:16 +0200

On 24.09.2017 22:05, Daniel Shahaf wrote:
> Branko Čibej wrote on Sun, 24 Sep 2017 21:56 +0200:
>> 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.
> About //-comments specifically, my thinking was that if we supported such
> comments we wouldn't run into "//-comments v. /**/-comments" conflicts
> when updating our embedded utf8proc.

Given what that merge looked like, the // comments were a minor issue :D
The whole discussion grew out of all proportion because I thought I
could leave the comments in and instead tell compilers to be smart about
them.

> But to your wider point, I agree, //-comments aren't _the_ most
> pressing C99 feature we might wish to adopt. I was just trying to take
> a "one step at a time" approach. So, can we switch from C89 to C89 +
> any single C99 feature? E.g., C89 + <one of the features you just named>.

The problem with the feature cherry-picking approach is that we don't
have a reliable way for compilers to warn about when /other/ features
except the blessed ones appear in the code.

If we want to take the Great Leap Forward, I'd prefer to just move to
C99 lock, stock and barrel instead. That would likely cause problems to
some of our downstream users, however.

-- Brane
Received on 2017-09-24 23:03:20 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.