Hi
On 16/04/2018 14:16, Bram Moolenaar wrote:
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.
That is correct. Picking some code at random I added a declaration
after a statement ...
diff --git a/src/beval.c b/src/beval.c
--- a/src/beval.c
+++ b/src/beval.c
@@ -47,6 +47,8 @@ get_beval_info(
{
row = Y_2_ROW(beval->y);
col = X_2_COL(beval->x);
+ int j;
+ j=0;
}
#endif
wp = mouse_find_win(&row, &col);
... and built with VS2012, resulting in the following compiler errors
being reported:
beval.c(50) : error C2143: syntax error : missing ';' before 'type'
beval.c(51) : error C2065: 'j' : undeclared identifier
VS2015 compiled it without complaint. I don't have VS2008 to check
that. Perhaps support of C++ style language features moved in and out
of VC over various releases, I don't know.
Trying to identify a workable subset across language standards is a
painful process, hence my suggestion of setting a cut off date for older
versions of VC as being an easier solution.
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.
I don't know if you meant your change to main.c in path 1724. This
patch will only test some unix builds as the statements before it is
only present when using X11 with a clipboard.
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.
HTH - TTFN
Mike
--
If you're not part of the solution, be part of the problem!
--
--
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.
