Mike Williams wrote:

> On 16/04/2018 01:34, James McCoy wrote:
> > On Sun, Apr 15, 2018 at 02:32:14PM +0200, Dominique Pellé wrote:
> >> Bram Moolenaar <b...@moolenaar.net> wrote:
> >>
> >>> Hello Vimmers,
> >>>
> >>> For a long time Vim code was made to be compiled with ANSI C (also known
> >>> as C89 and ISO C90).  This means it can also be compiled on very old
> >>> systems.  And since it wasn't too much work to support it, that was the
> >>> choice.
> >>>
> >>> Now that we are adding checks for C89 compliance, it turns out that we
> >>> already are using some C99 features, such as the "long long" type.
> >>> Also, many libraries produce warnings when enforcing C89.  That means
> >>> using C89 is starting to become a hassle.  So, the question comes up: is
> >>> it still worth it?
> >>>
> >>> If you CANNOT build Vim with a C99 compiler, please speak up!
> >>> If I don't hear about such cases, I think we are better off using C99 as
> >>> the standard.
> >>>
> >>> Note that if we go with C99, we still need to decide what features we
> >>> will actually use, since C99 compliance was lacking for quite a while
> >>> (esp. in MS-Visual C).  That's not going to make this easier.
> >>
> >> I would welcome C99.
> >>
> >> gcc-4.5 has full support of C99, but many C99 features
> >> were supported much earlier than that, see [1].
> >>
> >> It's less clear to me when C99 features were introduced
> >> in Visual studio. C99 support was lagging in Visual Studio.
> > 
> > Visual Studio doesn't fully support C99.  It supports the subset of C99
> > that overlaps with C++, as well as changes that could be implemented in
> > the standard library (i.e., didn't require compiler changes).
> > https://stackoverflow.com/q/9610747/198244 is a useful reference.
> > 
> > That will probably be enough for what Vim (and its dependencies) need.
> 
> My experience with a transition period moving to Visual Studio 2015 from 
> earlier versions is that the biggest issue is allowing variable 
> declarations to be declared anywhere within a block - it is very easy to 
> do.  If anyone is still using older versions this could become a regular 
> bump in the development road like not casting the result of STRLEN() to 
> an int where needed.

Are you saying that VS 2008 (the oldest that could still be used) did not
support a declaration after a statement?  If that is so we should not
allow it (at least for a while).  I don't think this is an important
restriction, putting declarations at the start of the block is always
possible.  Only including libvterm was a bit of a problem because of
this.

I just tried using VS 2008, and it seemed not to have a problem with
moving a declaration to halfway a block.  MSVC may not support C99 very
well, but this is probably a C++ feature, which they do support.

> Designated initializers and very large arrays are concious changes in 
> developer habits so will be less likely if they are to be precluded for 
> backward MSVC support.
> 
> Perhaps the release of 8.2/9.0 could be a red flag event to only support 
> VS2015 and later.
> 
> My 2ps worth to the debate.

-- 
Some of the well known MS-Windows errors:
        EHUH            Unexpected error
        EUSER           User error, not our fault!
        EGOD            Horrible problem, god knows what has happened
        EERR            Errornous error: nothing wrong

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui