Hey !
Just a quick word to launch the debate.
Disclamer : This is not a C vs C++ talk, thank you :-)
We nowadays support C89 officially . It is very stable and well implemented
in almost every compiler nowadays, but it is old and lack some features we
could benefit from.
Why not take PHP-Next step to support a more recent version ?
Even C99 would be allright and C11 would be super cool (though pretty
recent).
I know we support lots of compilers (even if that's not really documented),
and some of them could fail at supporting some C versions.
However, as PHP-Next is a big step in modernizing PHP, why not have a
discussion about the C versions our souce code base should support ?
Just to say, perhaps it's a dead and debate because of a big blocker point.
Julien.Pauli
Hey !
Just a quick word to launch the debate.
Disclamer : This is not a C vs C++ talk, thank you :-)We nowadays support C89 officially . It is very stable and well implemented
in almost every compiler nowadays, but it is old and lack some features we
could benefit from.Why not take PHP-Next step to support a more recent version ?
Even C99 would be allright and C11 would be super cool (though pretty
recent).I know we support lots of compilers (even if that's not really documented),
and some of them could fail at supporting some C versions.However, as PHP-Next is a big step in modernizing PHP, why not have a
discussion about the C versions our souce code base should support ?Just to say, perhaps it's a dead and debate because of a big blocker point.
I think the main question here is whether MSVC will have good C99 support
by the time PHP-Next is released. The other major compilers (GCC, Clang,
Intel) may not support all of C99 (esp stuff like FP pragmas), but have a
reasonable degree of support.
If we can, I'd be very much in favor of using C99. In particular mixed
code+declarations is a major code quality improvement to me.
Nikita
I think the main question here is whether MSVC will have good C99 support
by the time PHP-Next is released. The other major compilers (GCC, Clang,
Intel) may not support all of C99 (esp stuff like FP pragmas), but have a
reasonable degree of support.If we can, I'd be very much in favor of using C99. In particular mixed
code+declarations is a major code quality improvement to me.
Well, we don’t need to allow all of C99. We can simply allow using features that are widely supported and actually useful. For example, declarations between statements, and C++-style line comments with //.
Though for consistency with the rest of the codebase, perhaps we should stick to C-style /* */ comments.
--
Andrea Faulds
http://ajf.me/
I think the main question here is whether MSVC will have good C99 support
by the time PHP-Next is released. The other major compilers (GCC, Clang,
Intel) may not support all of C99 (esp stuff like FP pragmas), but have a
reasonable degree of support.If we can, I'd be very much in favor of using C99. In particular mixed
code+declarations is a major code quality improvement to me.Well, we don’t need to allow all of C99. We can simply allow using features that are widely supported and actually useful. For example, declarations between statements, and C++-style line comments with //.
Though for consistency with the rest of the codebase, perhaps we should stick to C-style /* */ comments.
It is hard to judge what "widely supported" means. PHP is so widespread
that people run it on embedded systems, 10+ year old servers (see old
masters.php.net) and compile them with compiler most of us have never
touched (suncc, pcc).
I think we have to come up with good arguments for C99 support that we just
can't do with C89 in order to potentially keep out people.
tl;dr: I believe unless we have strong arguments we should acknowkledge that PHP
is so widespread that changing compiler can make some users unhappy and if we
don't have really good reasons we shouldn't.
IMP, C89 is simple enough and reliable. Though it is old. it is wildly supported.
I think the main question here is whether MSVC will have good C99 support
by the time PHP-Next is released. The other major compilers (GCC, Clang,
Intel) may not support all of C99 (esp stuff like FP pragmas), but have a
reasonable degree of support.If we can, I'd be very much in favor of using C99. In particular mixed
code+declarations is a major code quality improvement to me.Well, we don’t need to allow all of C99. We can simply allow using features that are widely supported and actually useful. For example, declarations between statements, and C++-style line comments with //.
Though for consistency with the rest of the codebase, perhaps we should stick to C-style /* */ comments.
It is hard to judge what "widely supported" means. PHP is so widespread
that people run it on embedded systems, 10+ year old servers (see old
masters.php.net) and compile them with compiler most of us have never
touched (suncc, pcc).I think we have to come up with good arguments for C99 support that we just
can't do with C89 in order to potentially keep out people.tl;dr: I believe unless we have strong arguments we should acknowkledge that PHP
is so widespread that changing compiler can make some users unhappy and if we
don't have really good reasons we shouldn't.
IMP, C89 is simple enough and reliable. Though it is old. it is wildly supported.
It is simple, reliable and widely-supported, sure, but it lacks certain features that could be useful. In 2014, while not all compilers support all of C99, most support it at least partially, and we don’t need the whole thing.
For an example of something C99 has that C89 lacks, it is a pain to have to redefine isnan() and isfinite() (the latter being particularly difficult) when doing floating-point math.
--
Andrea Faulds
http://ajf.me/
It is hard to judge what "widely supported" means. PHP is so widespread
that people run it on embedded systems, 10+ year old servers (see old
masters.php.net) and compile them with compiler most of us have never
touched (suncc, pcc).
Both suncc and pcc support C99. Are you aware of any other compilers
we should check for compatibility?
I think the main question here is whether MSVC will have good C99 support
by the time PHP-Next is released. The other major compilers (GCC, Clang,
Intel) may not support all of C99 (esp stuff like FP pragmas), but have a
reasonable degree of support.If we can, I'd be very much in favor of using C99. In particular mixed
code+declarations is a major code quality improvement to me.Well, we don’t need to allow all of C99. We can simply allow using
features that are widely supported and actually useful. For example,
declarations between statements,
I think that makes code a lot less readable, so I would not be in favour
allowing this in our coding guidelines.
cheers,
Derick
Well, we don’t need to allow all of C99. We can simply allow using
features that are widely supported and actually useful. For example,
declarations between statements,I think that makes code a lot less readable, so I would not be in favour
allowing this in our coding guidelines.
Really? I’ve found that declaring everything in advance makes for hard-to-read code. To take an example from code I’ve written (admittedly not C code - GML if anyone’s curious - but it might as well be), the first line of a function looked like this:
var list, hashList, text, i, pluginname, pluginhash, realhash, url, handle, filesize, progress, tempfile, tempdir, failed, lastContact, isCached, env;
Even broken onto multiple lines, declaring everything at once isn’t nice. For large functions (and some functions have to be large necessarily), declaring everything at the start just means a long list of variables and I would argue impairs code readability.
You should declare variables when and where you need them. If everything is done at the top, you have to scroll up to check the type of a variable. It also means that now-unused variables are less obvious as the declarations are far away from the usage, so you probably won’t spot that it’s useless unless you look at your compiler warnings.
Actually, a similar issue popped up in the code where that example was from. The language it was written in had some unfortunate properties, one of which was that variables not explicitly declared would instead be treated as properties of the current object. Because all the variables were declared at the start of the function, it was easy to miss the fact that some variables being used had not actually been declared. Of course this specific issue doesn’t exist in C, but it is an example of why having to declare all your variables at the start of a function isn’t really a good thing.
If nothing else, I think we should use C99’s ability to declare variables between statements. It makes it more likely mistakes will be spotted, eases reading code, and as far as I am aware, is widely supported.
--
Andrea Faulds
http://ajf.me/
发自我的 iPad
在 2014年7月28日，22:20，Andrea Faulds ajf@ajf.me 写道：
Well, we don’t need to allow all of C99. We can simply allow using
features that are widely supported and actually useful. For example,
declarations between statements,I think that makes code a lot less readable, so I would not be in favour
allowing this in our coding guidelines.Really? I’ve found that declaring everything in advance makes for hard-to-read code. To take an example from code I’ve written (admittedly not C code - GML if anyone’s curious - but it might as well be), the first line of a function looked like this:
var list, hashList, text, i, pluginname, pluginhash, realhash, url, handle, filesize, progress, tempfile, tempdir, failed, lastContact, isCached, env;
Even broken onto multiple lines, declaring everything at once isn’t nice. For large functions (and some functions have to be large necessarily), declaring everything at the start just means a long list of variables and I would argue impairs code readability.
You should declare variables when and where you need them. If everything is done at the top, you have to scroll up to check the type of a variable. It also means that now-unused variables are less obvious as the declarations are far away from the usage, so you probably won’t spot that it’s useless unless you look at your compiler warnings.
Actually, a similar issue popped up in the code where that example was from. The language it was written in had some unfortunate properties, one of which was that variables not explicitly declared would instead be treated as properties of the current object. Because all the variables were declared at the start of the function, it was easy to miss the fact that some variables being used had not actually been declared. Of course this specific issue doesn’t exist in C, but it is an example of why having to declare all your variables at the start of a function isn’t really a good thing.
If nothing else, I think we should use C99’s ability to declare variables between statements. It makes it more likely mistakes will be spotted, eases reading code, and as far as I am aware, is widely supported.
I really hate this.
Thanks--
Andrea Faulds
http://ajf.me/
发自我的 iPad
在 2014年7月28日，22:20，Andrea Faulds <ajf@ajf.me (mailto:ajf@ajf.me)> 写道：
Well, we don’t need to allow all of C99. We can simply allow using
features that are widely supported and actually useful. For example,
declarations between statements,I think that makes code a lot less readable, so I would not be in favour
allowing this in our coding guidelines.Really? I’ve found that declaring everything in advance makes for hard-to-read code. To take an example from code I’ve written (admittedly not C code - GML if anyone’s curious - but it might as well be), the first line of a function looked like this:
var list, hashList, text, i, pluginname, pluginhash, realhash, url, handle, filesize, progress, tempfile, tempdir, failed, lastContact, isCached, env;
Even broken onto multiple lines, declaring everything at once isn’t nice. For large functions (and some functions have to be large necessarily), declaring everything at the start just means a long list of variables and I would argue impairs code readability.
You should declare variables when and where you need them. If everything is done at the top, you have to scroll up to check the type of a variable. It also means that now-unused variables are less obvious as the declarations are far away from the usage, so you probably won’t spot that it’s useless unless you look at your compiler warnings.
Actually, a similar issue popped up in the code where that example was from. The language it was written in had some unfortunate properties, one of which was that variables not explicitly declared would instead be treated as properties of the current object. Because all the variables were declared at the start of the function, it was easy to miss the fact that some variables being used had not actually been declared. Of course this specific issue doesn’t exist in C, but it is an example of why having to declare all your variables at the start of a function isn’t really a good thing.
If nothing else, I think we should use C99’s ability to declare variables between statements. It makes it more likely mistakes will be spotted, eases reading code, and as far as I am aware, is widely supported.
I really hate this.
Thanks
+1, can’t agree more.
Thanks,
Wei Dai
--
Andrea Faulds
http://ajf.me/
I think opinions about readability are subjective.
The real problem, that it'll break compatibility with old uncommon
compilers.
I'm not sure if new MSVC versions support it, but the one I use - does not.
Breaking something without a real reason is not a good move.
Thanks. Dmitry.
Well, we don’t need to allow all of C99. We can simply allow using
features that are widely supported and actually useful. For example,
declarations between statements,I think that makes code a lot less readable, so I would not be in favour
allowing this in our coding guidelines.Really? I’ve found that declaring everything in advance makes for
hard-to-read code. To take an example from code I’ve written (admittedly
not C code - GML if anyone’s curious - but it might as well be), the first
line of a function looked like this:var list, hashList, text, i, pluginname, pluginhash, realhash, url,handle, filesize, progress, tempfile, tempdir, failed, lastContact,
isCached, env;Even broken onto multiple lines, declaring everything at once isn’t nice.
For large functions (and some functions have to be large necessarily),
declaring everything at the start just means a long list of variables and I
would argue impairs code readability.You should declare variables when and where you need them. If everything
is done at the top, you have to scroll up to check the type of a variable.
It also means that now-unused variables are less obvious as the
declarations are far away from the usage, so you probably won’t spot that
it’s useless unless you look at your compiler warnings.Actually, a similar issue popped up in the code where that example was
from. The language it was written in had some unfortunate properties, one
of which was that variables not explicitly declared would instead be
treated as properties of the current object. Because all the variables were
declared at the start of the function, it was easy to miss the fact that
some variables being used had not actually been declared. Of course this
specific issue doesn’t exist in C, but it is an example of why having to
declare all your variables at the start of a function isn’t really a good
thing.If nothing else, I think we should use C99’s ability to declare variables
between statements. It makes it more likely mistakes will be spotted, eases
reading code, and as far as I am aware, is widely supported.--
Andrea Faulds
http://ajf.me/
I think opinions about readability are subjective.
The real problem, that it'll break compatibility with old uncommon
compilers.
I'm not sure if new MSVC versions support it, but the one I use - does
not.
We are working with the vc team to test the c99 (c++11/14 as well) with
many oss softwares, php included (non core ext).
It could be possible to use c99 from a vc pov but not if we decide to
release php-next next year. However with the yearly vc release, we could
make it for Q4/2015.
Breaking something without a real reason is not a good move.
I agree with you here.
I think opinions about readability are subjective.
The real problem, that it'll break compatibility with old uncommon
compilers.
I'm not sure if new MSVC versions support it, but the one I use - does
not.We are working with the vc team to test the c99 (c++11/14 as well) with
many oss softwares, php included (non core ext).It could be possible to use c99 from a vc pov but not if we decide to
release php-next next year. However with the yearly vc release, we could
make it for Q4/2015.
Could you please provide an update on the current situation regarding C99
support in MSVC? It seems that VS 2013 supports the most important C99
features 1. What's our current minimum required vc version?
I think opinions about readability are subjective.
The real problem, that it'll break compatibility with old uncommon
compilers.
I'm not sure if new MSVC versions support it, but the one I use - does
not.We are working with the vc team to test the c99 (c++11/14 as well) with
many oss softwares, php included (non core ext).It could be possible to use c99 from a vc pov but not if we decide to
release php-next next year. However with the yearly vc release, we could
make it for Q4/2015.Could you please provide an update on the current situation regarding C99
support in MSVC? It seems that VS 2013 supports the most important C99
features 1. What's our current minimum required vc version?
Today I explored what it would take to compile with -std=c90 and
-std=c99. We're actually very close to being valid C99 – we just need
to remove uint and u_char and define _XOPEN_SOURCE for glibc to
expose some POSIX/UNIX stuff. Those same things have to be done for
C90 compatibility and remove // style comments.c.
The function strtoll doesn't exist until C90 and we use it; this means
for C90 we have to use _XOPEN_SOURCE=600 for glibc to give it to us,
but I am unsure how portable this is.
Aside from strtoll we already use several features of C99 such as
inline, <stdint.h>.
In summary: I think we should move to C99 and compile with the
-std=c99 flag. There are also features of C99 that would allow us to
use zend_string* in internal functions instead of char*; this would be
a big win for cleanup since user functions use zend_string* and there
is forked logic because of this.
This is, of course, dependent on the whether the compilers we intend
to support will work with C99. I know that gcc, clang, icc and MS VS
2013 will all work with the basic features of C99 that we use now and
expect to use in the future if we move to C99. Are there any other
known compilers out there that we should check?
Nikita Popov wrote:
[...] What's our current minimum required vc version?
As of PHP 5.5 at least VC11 (Visual Studio 2012) is required for Windows
builds. The currently available snapshots of master are also built with
VC11[1].
[1] http://windows.php.net/snapshots/
--
Christoph M. Becker
Nikita Popov wrote:
[...] What's our current minimum required vc version?
As of PHP 5.5 at least VC11 (Visual Studio 2012) is required for Windows
builds. The currently available snapshots of master are also built with
VC11[1].
We are in the process of testing latest or better said the upcoming next
version of VC.
However it is a long process. We use a couple of libs to test c99 support.
What could be amazingly helpful, not only for VC, is some sample codes
using what we are most likely to use intensively from c99. It will allow is
to valid them against various compilers as well as clearly define what we
can support in the CS, all compilers we are likely to support for 7,
including VC, ICC or older GCC.
Cheers,
Nikita Popov wrote:
[...] What's our current minimum required vc version?
As of PHP 5.5 at least VC11 (Visual Studio 2012) is required for Windows
builds. The currently available snapshots of master are also built with
VC11[1].We are in the process of testing latest or better said the upcoming next
version of VC.However it is a long process. We use a couple of libs to test c99 support.
What could be amazingly helpful, not only for VC, is some sample codes
using what we are most likely to use intensively from c99. It will allow is
to valid them against various compilers as well as clearly define what we
can support in the CS, all compilers we are likely to support for 7,
including VC, ICC or older GCC.Cheers,
I am quite sure we would use these features:
- compound literals (this would allow for zend_string* at compile time)
- designated initializers
I'll work on some code examples later today if someone hasn't beaten
me to it by then.
Nikita Popov wrote:
[...] What's our current minimum required vc version?
As of PHP 5.5 at least VC11 (Visual Studio 2012) is required for Windows
builds. The currently available snapshots of master are also built with
VC11[1].We are in the process of testing latest or better said the upcoming next
version of VC.However it is a long process. We use a couple of libs to test c99 support.
What could be amazingly helpful, not only for VC, is some sample codes
using what we are most likely to use intensively from c99. It will allow is
to valid them against various compilers as well as clearly define what we
can support in the CS, all compilers we are likely to support for 7,
including VC, ICC or older GCC.Cheers,
I am quite sure we would use these features:
- compound literals (this would allow for zend_string* at compile time)
- designated initializers
I'll work on some code examples later today if someone hasn't beaten
me to it by then.
Here is a self-contained example of designated initializers:
struct Point {
int x;
int y;
};
int main(void) {
struct Point p = {
.y = 2,
.x = 1,
};
return !(p.x == 1 && p.y == 2);
}
And here is compound literals:
#include <stddef.h>
struct sstring {
size_t len;
char *val;
};
static struct sstring str;
int main(void) {
str = (struct sstring) {
sizeof("hello, world") - 1,
"hello, world"
};
return !(str.len == sizeof("hello, world") - 1);
}
I expect in some cases we may even use them together. This particular
example doesn't really show why, but sometimes we have two uint32_t's
in a row and initializing them with a name helps make the code more
understandable:
#include <stddef.h>
struct sstring {
size_t len;
char *val;
};
static struct sstring str;
int main(void) {
str = (struct sstring) {
.len = sizeof("hello, world") - 1,
.val = "hello, world",
};
return !(str.len == sizeof("hello, world") - 1);
}
Hi!
Thanks!
Maybe we can create a repo on github to share them?
I can create one, yes I prefer github than PHP's git, much easier to
manage, issues, etc
Cheers,
Pierre
On Fri, May 8, 2015 at 5:01 AM, Pierre Joye pierre.php@gmail.com
wrote:Nikita Popov wrote:
[...] What's our current minimum required vc version?
As of PHP 5.5 at least VC11 (Visual Studio 2012) is required for
Windows
builds. The currently available snapshots of master are also built
with
VC11[1].We are in the process of testing latest or better said the upcoming next
version of VC.However it is a long process. We use a couple of libs to test c99
support.What could be amazingly helpful, not only for VC, is some sample codes
using what we are most likely to use intensively from c99. It will
allow is
to valid them against various compilers as well as clearly define what
we
can support in the CS, all compilers we are likely to support for 7,
including VC, ICC or older GCC.Cheers,
I am quite sure we would use these features:
- compound literals (this would allow for zend_string* at compile time)
- designated initializers
I'll work on some code examples later today if someone hasn't beaten
me to it by then.Here is a self-contained example of designated initializers:
struct Point {
int x;
int y;
};int main(void) {
struct Point p = {
.y = 2,
.x = 1,
};
return !(p.x == 1 && p.y == 2);
}And here is compound literals:
#include <stddef.h>
struct sstring {
size_t len;
char *val;
};static struct sstring str;
int main(void) {
str = (struct sstring) {
sizeof("hello, world") - 1,
"hello, world"
};
return !(str.len == sizeof("hello, world") - 1);
}I expect in some cases we may even use them together. This particular
example doesn't really show why, but sometimes we have two uint32_t's
in a row and initializing them with a name helps make the code more
understandable:#include <stddef.h>
struct sstring {
size_t len;
char *val;
};static struct sstring str;
int main(void) {
str = (struct sstring) {
.len = sizeof("hello, world") - 1,
.val = "hello, world",
};
return !(str.len == sizeof("hello, world") - 1);
}
Maybe we can create a repo on github to share them?
I can create one, yes I prefer github than PHP's git, much easier to
manage, issues, etc
I say go for it, since you're our liason to the MSVC team.
For me, I agree with what Nikita said last July. Mixed
code+declarations. So much better quality of life than having to put
all declarations at the top.
-Sara
A feature of C11 that would be useful is anonymous unions:
struct zval {
union {
long lval;
double dval;
};
enum {
IS_LONG,
IS_DOUBLE
} type;
};
int main(void) {
struct zval zv;
zv.lval = 1;
zv.type = IS_LONG;
return 0;
}
Again, this is a C11 feature. It is supported by clang, gcc and MSVC.
Also note that if you use designated initializers from C99 you can
directly initialize it like so:
int main(void) {
struct zval zv = {
.lval = 1,
.type = IS_LONG
};
return !(zv.lval == 1);
}
If we are going to have a repository of features this is definitely
one I'd like to test since the biggest three compilers all support it
and I'd like to see how far the support reaches.
Similarly anonymous structs would be useful as well. One specific
place I am aware of is the _zend_function union that has a struct
named common. If you make this struct anonymous then you can directly
access the struct's properties just like you can with
_zend_internal_function and _zend_op_array. This makes the polymorphic
nature of these structures a bit easier to deal with.
Again, this is a C11 feature. It is supported by clang, gcc and MSVC.
To clarify this a bit: they permit anonymous unions in C89 and C99
code (meaning you do not need to pass flags like -std=c11 to enable
it).
Hi,
Again, this is a C11 feature. It is supported by clang, gcc and MSVC.
To clarify this a bit: they permit anonymous unions in C89 and C99
code (meaning you do not need to pass flags like -std=c11 to enable it).
particularly regarding VS2013/VS2015RC more is readable here
http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx
. One should keep in mind that it's C++ oriended, therefore C99 is just a
partial side effect by luck. Not even talking about C11 or newer which
might be far more incomplete than C99.
Another factor is dependencies handling, as well as C++. So far ICU isn't
good playing with C++11 for example. So while C99 were clamed to be
supported and were nice, still many things need to be carefully checked.
Also besides syntax, there might be some breaking platform API changes.
Is there already some repo one can compile? It might have sense to compile
that repo with any possible compilers on any possible platforms of
interest, and then make an informed decision about C99 when having that
data (in RFC?). It could be also defined not as C99, but as C89 with some
extended features, to be more precise (but would be a question of
definition when there's more data). Once we have that repo, we could ask
people to do test compilations on different platforms and supply the
results.
Regards
Anatol
hi Levi!
Again, this is a C11 feature. It is supported by clang, gcc and MSVC.
To clarify this a bit: they permit anonymous unions in C89 and C99
code (meaning you do not need to pass flags like -std=c11 to enable
it).
https://github.com/FriendsOfPHP/phpnextctest
Feel free to provide PRs or your handle.
Simple makefiles should do it (win+unix) or configure + makefiles for
windows. The sooner is way easer to manage for now :)
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi Levi,
Again, this is a C11 feature. It is supported by clang, gcc and MSVC.
To clarify this a bit: they permit anonymous unions in C89 and C99
code (meaning you do not need to pass flags like -std=c11 to enable it).
I've added makefiles for gcc and VC and your C99 code to
https://github.com/FriendsOfPHP/phpnextctest . Yet as is, but they still
could be extended so it would look like a list with "Feature X: pass/fail"
lines, but that they do compile an run is already encouraging :) So
catching the cases would make sense to continue. Other makefiles can be
added for different compilers/platforms.
To run just checkout and type
nmake /f makefile.vc run_all
or
make -f makefile.gcc run_all
IMO we should ignore C11 for this, otherwise the mix will get unpredictable.
Regards
Anatol
Hi all,
----- Original Message -----
From: "Levi Morrison"
Sent: Sunday, May 10, 2015
Again, this is a C11 feature. It is supported by clang, gcc and MSVC.
To clarify this a bit: they permit anonymous unions in C89 and C99
code (meaning you do not need to pass flags like -std=c11 to enable
it).
What's the status on compiler requirements? Are they, or will they be,
higher?
I'm going to take advantage of variadic macros (VA_ARGS) for better code
generation with the parameter parsing implementation I'm finishing up, and
it would be nice to not have to make two versions with a compiler check.
e.g. for MSVC or GCC >= 3, but I don't know what else...
Thanks,
Matt
Hi Matt
2015-07-08 17:00 GMT+02:00 Matt Wilmas php_lists@realplain.com:
Hi all,
----- Original Message -----
From: "Levi Morrison"
Sent: Sunday, May 10, 2015Again, this is a C11 feature. It is supported by clang, gcc and MSVC.
To clarify this a bit: they permit anonymous unions in C89 and C99
code (meaning you do not need to pass flags like -std=c11 to enable
it).What's the status on compiler requirements? Are they, or will they be,
higher?I'm going to take advantage of variadic macros (VA_ARGS) for better code
generation with the parameter parsing implementation I'm finishing up, and
it would be nice to not have to make two versions with a compiler check.
e.g. for MSVC or GCC >= 3, but I don't know what else...
For 7.0, we are gonna focus on MSVC 2015 (VC14), although VC11 is also
known to work, we will do the 7.0+ releases with VC14 (that is
releasing later this month)
--
regards,
Kalle Sommer Nielsen
kalle@php.net
The real problem, that it'll break compatibility with old uncommon compilers.
I'm not sure if new MSVC versions support it, but the one I use - does not.Breaking something without a real reason is not a good move.
While C99 itself would, I would again argue that we don’t need to use the whole thing. Are there any compilers out there which people use to compile PHP that do not support declarations between statements?
Andrea Faulds
http://ajf.me/
The real problem, that it'll break compatibility with old uncommon
compilers.
I'm not sure if new MSVC versions support it, but the one I use - does
not.Breaking something without a real reason is not a good move.
While C99 itself would, I would again argue that we don’t need to use the
whole thing. Are there any compilers out there which people use to compile
PHP that do not support declarations between statements?
VC is one, except latest RC. And if gcc would follow c89 std without tricks
too. Why we should use the c89 strict option.
Why not take PHP-Next step to support a more recent version ?
Even C99 would be allright and C11 would be super cool (though pretty
recent).
I'd stop with C99 for now. One of PHP's strengths is that it builds /anywhere/. I'd hate to lose that over a few pieces of syntactic sugar. (I say this as someone who's come to adore C++11)
-Sara
Why not take PHP-Next step to support a more recent version ?
Even C99 would be allright and C11 would be super cool (though pretty
recent).I'd stop with C99 for now. One of PHP's strengths is that it builds
/anywhere/. I'd hate to lose that over a few pieces of syntactic sugar. (I
say this as someone who's come to adore C++11)
Makes sense, even if I haven't met myself that many different platforms and
compilers fancies.
Julien.P
I support the move to C99... but not yet. We definitely need a longer
period for Visual Studio support; I suspect over time more compilers
will support C99 now that VC does.
More importantly I'd like to see any standard adherence to be more
strict so we can compile with -pedantic. Some of the big offenders are
fixed in the 64 bit int patch and PHPNG; I've been waiting for these
to land in master before continuing to investigate the other
non-strict usages.
We nowadays support C89 officially . It is very stable and well implemented
in almost every compiler nowadays, but it is old and lack some features we
could benefit from.
Isn't it interesting that on one hand we have a continual complaint that
PHP is getting too old and has to evolve with the time, yet the primary
development language is 25+ years old and the suggestion to move it on
10 years raises objections.
On one hand if it's not broken ... on the other software must be changed
every year ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk