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

[Stefan Fuhrmann <st...@apache.org>]

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.

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

[Greg Stein <gs...@gmail.com>]

On Sun, Oct 1, 2017 at 4:17 AM, Stefan Fuhrmann <st...@apache.org> wrote:

>
>
> 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:
>>>
>> >...

> *for*-scope variable declarations, that'd make some sense. But talking
>>>> about just "C90 + //" is, IMO, a waste of time.
>>>>
>>>
Right. "Change the accepted set of compiles so we can use // comments" ...
Wat?


> 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.
>>>
>>
Seems like the real question is related to utf8proc, rather than comment
style.

>...

> 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.
>

Concur.


> 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.
>

Yeah. It would be great to start using some C++ within include/private/,
and the implementing modules.

It is difficult to see how we could place any C++ into our public API,
however. And yeah, I know you didn't mention that. :-)


> 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.
>

Right. Like /*..*/ comments versus //

Cheers,
-g