[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 Fuhrmann <stefan2_at_apache.org>
Date: Sun, 1 Oct 2017 11:17:20 +0200

On 24.09.2017 23:03, Branko ─îibej wrote:
> 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.

I fully agree with Brane on this.

Another thing that has popped up in the past and that I, personally,
would love to see happening is supporting C++ inside our libs. I think
that would have it made easier to me, using wrapper classes / templates
with appropriate operator overloading, to migrate code from one API /
data structure to another.

However, that move too, would create all sorts of compatibility issues
with rules to address them and all for a limited increase in coding
convenience.

-- Stefan^2.
Received on 2017-10-01 11:17:25 CEST

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