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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Julian Foad-5
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.

WDYT?

- Julian
Reply | Threaded
Open this post in threaded view
|

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

Julian Foad-6
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...

:-(

- Julian
Reply | Threaded
Open this post in threaded view
|

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

Branko Čibej
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
Reply | Threaded
Open this post in threaded view
|

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

Nathan Hartman
In reply to this post by Julian Foad-5

> On Sep 22, 2017, at 7:04 AM, Julian Foad <[hidden email]> wrote:
>
> 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.
>

Looks like this isn't going to happen but
FWIW and just for others' reference, we
compile an internal C99 library and its test
suite on MSVC2008 among other platforms
and compilers. The purpose is to run the test
suite as many different ways as possible. It
compiles, runs, and all tests pass 100%. The
trick is to configure all the project's C files to
compile as C++ despite their .c extension.
This is because the C++ standard supported
by MSVC contains the features (or at least
the ones that affect us) that had been
"backported" from C++ to C to form C99.
There is also a project-wide global header
that tests for various compilers and fixes
things so they work. For example we had to
define a macro that becomes "inline" under
some compilers and __inline under MSVC,
and I believe typedef the fixed-size int types
(uint32_t and friends), among other things.
But the point is that with some headache it
can be made to work.


Reply | Threaded
Open this post in threaded view
|

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

Stefan
In reply to this post by Branko Čibej
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
- 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.

As far as I see it, one of the main restrictions we regularly face is
the use of //-comment styles (especially when talking here integrated
external libraries/code). This is something which has long been
supported even in VS.

The wikipedia page also provides quite a summary of C99-support in
different compilers [1].

Regards,
Stefan

[1] https://en.wikipedia.org/wiki/C99#Implementations

Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
Stefan wrote on Sun, 24 Sep 2017 11:36 +0200:
> As far as I see it, one of the main restrictions we regularly face is
> the use of //-comment styles (especially when talking here integrated
> external libraries/code). This is something which has long been
> supported even in VS.

Just thinking out loud: suppose we wanted to switch from C89 to "C89 +
//-comments" --- without any other C99 features --- what are our options
to do that?
Reply | Threaded
Open this post in threaded view
|

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

Branko Čibej
On 24.09.2017 13:23, Daniel Shahaf wrote:
> Stefan wrote on Sun, 24 Sep 2017 11:36 +0200:
>> As far as I see it, one of the main restrictions we regularly face is
>> the use of //-comment styles (especially when talking here integrated
>> external libraries/code). This is something which has long been
>> supported even in VS.
> Just thinking out loud: suppose we wanted to switch from C89 to "C89 +
> //-comments" --- without any other C99 features --- what are our options
> to do that?

We couldn't do that with GCC so it's a non-starter.

-- Brane
Reply | Threaded
Open this post in threaded view
|

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

Branko Čibej
In reply to this post by Stefan
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.

> - 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
Reply | Threaded
Open this post in threaded view
|

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

Stefan
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?

Regards,
Stefan
Reply | Threaded
Open this post in threaded view
|

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

Branko Čibej
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

Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
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.

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

Cheers,

Daniel
Reply | Threaded
Open this post in threaded view
|

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

Branko Čibej
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
Reply | Threaded
Open this post in threaded view
|

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

Stefan
In reply to this post by Daniel Shahaf-2
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.
> [...]
>
> 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>.
>
This was exactly my thinking as well - i.e. to make a step towards using
more C99-features. As you, brane, rightfully pointed out there would
hardly have been a point to discuss the matter, if it was just for the
sake of the //-comment-usage.

But I see that there's some reluctance to make this step, and while I'd
certainly would appreciate us moving ahead, I personally also don't see
that much an urge to use C99-features atm. Hence, I'll leave the idea
rested now.

Regards,
Stefan



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Stefan Fuhrmann
In reply to this post by Branko Čibej


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.
Reply | Threaded
Open this post in threaded view
|

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

Greg Stein-4


On Sun, Oct 1, 2017 at 4:17 AM, Stefan Fuhrmann <[hidden email]> wrote:


On <a href="tel:24.09.2017%2023" value="+12409201723" target="_blank">24.09.2017 23:03, Branko Čibej wrote:
On <a href="tel:24.09.2017%2022" value="+12409201722" target="_blank">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