I am curious why we are not finally doing the switch to C99 with VC14
finally supporting most of C99. I mean, I know that GCC and VC14 do no
fully support C99 but the most common features are implemented:
--
Richard "Fleshgrinder" Fussenegger
I am curious why we are not finally doing the switch to C99 with VC14
finally supporting most of C99. I mean, I know that GCC and VC14 do no
fully support C99 but the most common features are implemented:
Hi,
It's time to bring this up again. I recently noticed that nowadays only
Kalle fixes Windows build issues due to C99 declarations-after-code, while
Anatol doesn't. Am I correct in the assumption that Anatol is using an MSVC
version that supports the necessary subset of C99, while Kalle uses an
older version that doesn't support this yet? If so, is it viable for us to
drop support for these older MSVC versions for master? I'd really like to
be able to use certain C99 functionality (okay, I'm only really interested
in declarations mixed with code).
Thanks,
Nikita
2016-11-12 11:57 GMT+01:00 Nikita Popov nikita.ppv@gmail.com:
It's time to bring this up again. I recently noticed that nowadays only
Kalle fixes Windows build issues due to C99 declarations-after-code, while
Anatol doesn't. Am I correct in the assumption that Anatol is using an MSVC
version that supports the necessary subset of C99, while Kalle uses an
older version that doesn't support this yet? If so, is it viable for us to
drop support for these older MSVC versions for master? I'd really like to
be able to use certain C99 functionality (okay, I'm only really interested
in declarations mixed with code).
I use VC11, which is the compiler used for 5.6 builds, technically its
on our list to drop support for in 7.2+ I think was the plan, while
Anatol uses VC14+ mainly, which is the compiler used for 7.0+ builds.
So technically I shouldn't really be using VC11 for 7.0+, but on my
current small setup, I have only configured VC11, but I plan on fully
upgrading to VC14 only soon, as 5.6 does not have much active
development that cannot be done on VC14.
According to Wikipedia:
Visual C++ 2012 and earlier did not support C99.
Visual C++ 2013 implements a limited subset of C99 required to compile
popular open-source projects.
Visual C++ 2015 implements the C99 standard library, with the
exception of any library features that depend on compiler features not
yet supported by the compiler (for example, <tgmath.h> is not
implemented).
And ofcourse the version mapping:
VC11 - Visual C++ 2012
VC12 - Visual C++ 2013
VC14 - Visual C++ 2015
So as long as future developments are compatible with VC14, its fine with me
--
regards,
Kalle Sommer Nielsen
kalle@php.net
2016-11-12 11:57 GMT+01:00 Nikita Popov nikita.ppv@gmail.com:
<snip> According to Wikipedia: Visual C++ 2012 and earlier did not support C99. Visual C++ 2013 implements a limited subset of C99 required to compile popular open-source projects. Visual C++ 2015 implements the C99 standard library, with the exception of any library features that depend on compiler features not yet supported by the compiler (for example, <tgmath.h> is not implemented).It's time to bring this up again. I recently noticed that nowadays only
Kalle fixes Windows build issues due to C99 declarations-after-code, while
Anatol doesn't. Am I correct in the assumption that Anatol is using an MSVC
version that supports the necessary subset of C99, while Kalle uses an
older version that doesn't support this yet?
I will run a build test on a Solaris 10 server with Oracle Studio 12.4
as well as 12.5 using the very strict c99 compiler with option -Xc and
define -D_XOPEN_SOURCE 600. This will enforce compliance rules as well
as feature test macros for The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition. Where we get into deep trouble is the
use of extensions which may be purely gnuisms or gccisms. These all
become very evident once a strict compiler set of options are used. I
will get it a run through and see what I see.
Dennis Clarke
I am curious why we are not finally doing the switch to C99 with VC14
finally supporting most of C99. I mean, I know that GCC and VC14 do no
fully support C99 but the most common features are implemented:It's time to bring this up again. I recently noticed that nowadays
only Kalle fixes Windows build issues due to C99
declarations-after-code, while Anatol doesn't. Am I correct in the
assumption that Anatol is using an MSVC version that supports the
necessary subset of C99, while Kalle uses an older version that
doesn't support this yet? If so, is it viable for us to drop support
for these older MSVC versions for master? I'd really like to be able
to use certain C99 functionality (okay, I'm only really interested in
declarations mixed with code).
I would want to write down in our coding guidelines that we should NOT
do declarations after code, as you will no longer have an overview of
all the types in one place anymore.
cheers,
Derick
Hi Derick,
Derick Rethans wrote:
I would want to write down in our coding guidelines that we should NOT
do declarations after code, as you will no longer have an overview of
all the types in one place anymore.
That's your preference. Personally, I would really appreciate the
ability to declare variables later in code.
The main reason for this is that it allows me to minimise the number of
variables left uninitialised. If you have to declare variables at the
top of the function, then many of them will be unitialised for some or
all of the lifetime of the function, or initialised to dummy values.
This can lead to errors with variables being used before they contain a
meaningful value (and undefined behaviour), which is the cause of a lot
of bugs in C code (and indeed in PHP's). It's also easier to end up with
unused variables this way (whose compiler warnings often get buried or
ignored), because you would tend to assume that an unitialised variable
is going to be used later.
There are other benefits, too. For one, it makes the top of a function
less cluttered: you can define variables where you use them, rather than
having to list all of them at once. This can make code easier to
understand, because you only have to worry about variables which are
currently in use, rather than being distracted by variables which might
only be initialised or used much later in the function. Plus, because
this way more variables are initialised at the point of declaration, it
can make it clearer what a variable's purpose is, because you get both
the type and the initial value on the same line, rather than possibly on
different screens. This makes it easier to spot incorrect types and
initial values, too, which is important given C's, hmm, rather weak type
system.
If you need to find the type of a previously-declared variable, vim's ?
command is always at your disposal. But with C99's declarations in the
function body, now you might actually know what the variable contains
when you use that command.
Thanks!
--
Andrea Faulds
https://ajf.me/
Hi Nikita,
-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Saturday, November 12, 2016 11:58 AM
To: PHP internals internals@lists.php.net; Anatol Belski
anatol.php@belski.net
Subject: Re: [PHP-DEV] C89 vs. C99On Sun, Jun 12, 2016 at 11:08 AM, Fleshgrinder <php@fleshgrinder.com
mailto:php@fleshgrinder.com > wrote:I am curious why we are not finally doing the switch to C99 with VC14
finally supporting most of C99. I mean, I know that GCC and VC14 do no
fully support C99 but the most common features are implemented:- https://en.wikipedia.org/wiki/C99#Implementations
https://en.wikipedia.org/wiki/C99#Implementations
- https://gcc.gnu.org/c99status.html
https://gcc.gnu.org/c99status.htmlHi,
It's time to bring this up again. I recently noticed that nowadays only Kalle fixes
Windows build issues due to C99 declarations-after-code, while Anatol doesn't.
Am I correct in the assumption that Anatol is using an MSVC version that
supports the necessary subset of C99, while Kalle uses an older version that
doesn't support this yet? If so, is it viable for us to drop support for these older
MSVC versions for master? I'd really like to be able to use certain C99
functionality (okay, I'm only really interested in declarations mixed with code).
That's a good spot. Indeed, VC++14 implements the C99 features in big extent, as announced here
https://msdn.microsoft.com/en-us/library/hh409293.aspx#BK_CRT
VC++11 is only usable with 7.x, because there was no case yet, forcing to use a compiler feature that would require VC++14 only. Once this moment came, VC11 is out with fire. I use VC11 only for PHP-5.6, as that's what we stick to for the standard builds.
A less extensive C99 support was already present in VC++12. We produce the standard 7.x builds with VC++14, not only for PHP but also for the dependency libraries and PECL. Practically, VC++14 is already used for over a year, started even with a pre release version, and it only shows good results. With C libraries, there was several issues, but they all was solvable in favor of VC14. Otherwise, while the old code feels fine with the newer compiler, the new horizons open themselves. It was already possible, to get some extensions to support Windows build for 7.0 for this exact reason. Either because the devs didn't care about C89 anymore (fe ext/amqp) or because the dependency library expected a C99 compiler (fe librdkafka).
In many cases, I haven't checked the exact C99 features libraries use, but just went to compile them with VC++14, and there was almost no disappointment. Well, it could be, but it's then not related to C99 anymore, but more is about some unportable platform features.
Thus, based on my current experiences now over one year, I can tell that in regard to VS and C99 features it looks quite optimistic. We de facto use C99 compilers nowadays, and we have several cases in the core that would profit from this. I can at least recall some cases in math functions, but there should be more not necessarily related to the C99 specific syntax changes.
Regarding the syntax caveats - well, the code esthetics is something that we need to agree on. As for me, some cases using inline declarations are still useful, fe "for (int k = 0, ....);" where the scope is guaranteed to be local to the loop. Or the case to partially initialize some struct members. Indeed, enabling C99 would mean, the course should be in first place to accept the features. We can then extend our coding style to make the specific project preferences clear. But in general, there is much more than just mixing code and declarations or any other syntactic sugar. Take for example the bool and other new datatypes, array to pointer conversion, variable lenth arrays, comments with // and other even more intrusive features. At some point, one might not recognize the PHP source how we know it today, once C99 is indeed used in full extent :) C99 indeed is full of other features, but the coding style agreement is indeed the only way to solve the esthetic issues. And the less we would exclude with the coding style - the easier it would be to contribute.
IMHO, if we decide to move to C99, we should do it the strict way, unlike we do now with C89. VC++ enables C99 the way it can't be turned off, but some parts are still missing. In case of GCC and other compilers, the -std=c99 should be enforced. A quick check shows, at least gcc 4.9.2 with -std=c99 fails to compile PHP. Currently, while holding on C89 in general, compilers provide a mess of things like partial availability of headers, datatype definitions, etc. If we don't do it a strict way, we risk to have even more inconsistent source codes following the standard only partially. VC still lacks on some features, I'm not sure how strict/complete the C99 implementation in GCC/Clang is. Of course, after all, there will be still some compiler dependent difference. But in general - enforcing the switch will at least ensure the required standard is provided.
Probably, if the work on this should be started, it'd be good to do it soon so we're in time with 7.2. For the Windows side - there's currently an effort of a new binary tools implementation
https://github.com/OSTC/php-sdk-binary-tools/tree/new_binary_tools
It aims to support newer tools and better operation, but also there's no plan to support the environments for compilers older than VC14. If everything goes well, and that's actually the plan, the SDK will replace the old one for the standard builds. It could be, and actually would make sense, to require the new SDK for 7.2, which will automatically make VC11 unsupported for it. This would comply well, if a decision to require a C99 compiler for the whole project were taken. If we do that, we'd better get started soon, so we have enough time for fixes and QA, and so the new coding style guide lines can be worked out and agreed. And so we have enough time to turn back, if there are unsolvable issues.
Regards
Anatol
At risk of sounding bitter there really is no other way other than
"compliant" or "non-compliant" with very little grey area.
unlike we do now with C89. VC++ enables C99 the way it can't be
turned off, but some parts are still missing.
This is the case with gcc also.
see https://gcc.gnu.org/c99status.html
However one can attempt to use -std=iso9899:1999 with -pedantic-errors
as well but you need to know that assumptions are being made for " a
recent version of the GNU C Library" being in use. This is a poor
assumption.
This may explain why I still prefer to use the obscenely strict and
compliant Oracle Studio compilers on a Solaris system where the level
of SUSv3 and POSIX rules are assured.
In case of GCC and other compilers, the -std=c99 should be enforced.
Along with -D_POSIX_PTHREAD_SEMANTICS and -D_XOPEN_SOURCE=600 where with
a very crisp c99 compiler. Most of these tools exist no where but on a
classic UNIX commercial grade implementation. Sadly.
Dennis Clarke
IMHO, if we decide to move to C99, we should do it the strict way
I forgot to add that GNU GCC allows a lot of non-standard extensions to
slip right through. Unless some CFLAGS are set to warn or error on them.
https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/C-Extensions.html#C-Extensions
Dennis
IMHO, if we decide to move to C99, we should do it the strict way
I forgot to add that GNU GCC allows a lot of non-standard extensions to
slip right through. Unless some CFLAGS are set to warn or error on them.https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/C-Extensions.html#C-Extensions
Dennis
--
We are actually much closer to C99 than we are to C90. As proof of
this try compiling with GCC with -std=c90 -pedantic-errors and then
try it with -std=c99 -pedantic-errors. You have to make
significantly fewer changes to get the C99 version working (or at
least this was the case when it was last brought up). Also, ISO C90
and ANSI (C89) are essentially the same thing in case anyone is not
aware.
Hi,
-----Original Message-----
From: morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] On Behalf
Of Levi Morrison
Sent: Saturday, November 12, 2016 9:47 PM
To: Dennis Clarke dclarke@blastwave.org
Cc: internals internals@lists.php.net
Subject: Re: [PHP-DEV] C89 vs. C99On Sat, Nov 12, 2016 at 1:37 PM, Dennis Clarke dclarke@blastwave.org
wrote:IMHO, if we decide to move to C99, we should do it the strict way
I forgot to add that GNU GCC allows a lot of non-standard extensions
to slip right through. Unless some CFLAGS are set to warn or error on them.https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/C-Extensions.html#C-Exten
sionsDennis
--
To unsubscribe,
visit: http://www.php.net/unsub.phpWe are actually much closer to C99 than we are to C90. As proof of this try
compiling with GCC with-std=c90 -pedantic-errorsand then try it with- std=c99 -pedantic-errors. You have to make significantly fewer changes to get
the C99 version working (or at least this was the case when it was last brought
up). Also, ISO C90 and ANSI (C89) are essentially the same thing in case anyone is
not aware.
Even without that - we already use inline, datatypes and macros, other things that don't belong to C89. We also use _declspec(thread) aka __thread which is not standardized at all. The GNU extensions, or VS features, or any other compiler specifics, are same as before. What matters, is the core C99 standard, or at least the part implemented in any known compiler, as some #ifdefs for platform/compiler specific non C99 features will always exist. While at the start, it'll probably be only to make the current source to rock with C99 compilers and to be able to use some syntax/semantic sugar, later contributions indeed using any possible other C99 features will appear. That's the point I actually wanted to make - moving to C99, we enable a set of new features not available with the ANSI C, that we need to internalize and accept.
Regards
Anatol
moving to C99, we enable a set of new features not available with
the ANSI C, that we need to internalize and accept.
Just following up here.
Perhaps it was not a good idea to fire a bug report at 7.0.14RC1 but
what is done is done. It can always be marked "not a bug" or "yes we
know" at this time. For now I will drop down to using cc and a set of
more permissive CFLAGS which allow for some extensions and transitive
code elements. The configure stage seems fine thus far and a compile is
running.
Merely as a side note, I know that the folks inside Oracle are slowly
dropping support for their own operating system Solaris 10. This is
evidence in the fact that Oracle won't release MySQL 5.7 or the MySQL
cluster software for Solaris 10 at all. Despite the fact that Sol 10
is well supported for many more years to come and most of their
customer base is on it still. However, the sources of major software
elements such as PHP should compile clean within such a POSIX
environment using the tools provided.
I am a big big fan of GCC also. Have been for 20 years. It just isn't a
really tightly conforming compiler ( yet ) and the optimization within
the sparc servers is still best done with Oracle Studio tools.
Dennis Clarke
I am curious why we are not finally doing the switch to C99 with VC14
finally supporting most of C99. I mean, I know that GCC and VC14 do no
fully support C99 but the most common features are implemented:
What about other compilers such as Solaris Studio and XL C?
--
Christoph M. Becker
Morning,
okay, I'm only really interested in declarations mixed with code
Not sure if serious ... but I will harass you to change code that is mixi
[1].
I think actually disallowing mixing lends some readability and uniformity
to the code in php-src, that I would hate to see disappear ...
Cheers
Joe
[1] https://en.wikipedia.org/wiki/Myxomatosis?
On Sat, Nov 12, 2016 at 11:27 AM, Christoph M. Becker cmbecker69@gmx.de
wrote:
I am curious why we are not finally doing the switch to C99 with VC14
finally supporting most of C99. I mean, I know that GCC and VC14 do no
fully support C99 but the most common features are implemented:What about other compilers such as Solaris Studio and XL C?
--
Christoph M. Becker
Morning,
okay, I'm only really interested in declarations mixed with code
Not sure if serious ... but I will harass you to change code that is mixi
[1].I think actually disallowing mixing lends some readability and uniformity
to the code in php-src, that I would hate to see disappear ...Cheers
Joe
Depends on the situation.
Very commonly this arbitrary restriction requires me to rewrite code into a
way that is objectively worse, just to avoid repeating initializations.
Typical example: C99 allows me to write nice code like this:
void foo(foo_t arg) {
if (!foo_valid(arg)) {
return;
}
bar_t bar = get_bar(arg);
if (!bar_valid(bar)) {
return;
}
// Lots of variables here for internal computation
type1 a = ...;
type2 b = ...;
type3 c = ...;
type4 d = ...;
}
The important part is that I can easily do an early-return. C89 instead
forces me to do either this:
void foo(foo_t arg1, bar_t arg2) {
bar_t bar;
type1;
type2;
type3;
type4;
if (!foo_valid(arg)) {
return;
}
bar = get_bar(arg);
if (!bar_valid(bar)) {
return;
}
// Lots of variables here for internal computation
a = ...;
b = ...;
c = ...;
d = ...;
}
Which I find incredibly ugly, as its repetitive and declarations are far
removed from their source.
Alternatively what I can write is this:
void foo(foo_t arg) {
if (foo_valid(arg)) {
bar_t bar = get_bar(arg);
if (bar_valid(bar)) {
// Lots of variables here for internal computation
type1 a = ...;
type2 b = ...;
type3 c = ...;
type4 d = ...;
}
}
}
This is also ugly, because it creates deeply nested code. To avoid code
that nests many levels deep, what we often do instead (I'm sure you've seen
this often enough in the php-src codebase) is to instead create huge if
conditions. You know, the kind where the condition has 6 lines and contains
assignments on lines 3 and 5. This is part of the reason.
That's one half of the problem. C89 makes early-returns ugly, while I think
it is nowadays universally recognized that early-returns are preferable
over deeply nested code.
The other half of the problem is that, as a rule, the lifetime of a
variable should be minimal to avoid misuse. If you have code like this
type var;
if (xyz) {
// ...
} else {
var = 123;
use(var);
}
then nothing prevents you from using "var" in the "if" branch, where this
variable is not initialized. If instead you write
if (xyz) {
// ...
} else {
type var = 123;
use(var);
}
this mistake fundamentally cannot happen -- the compiler prevents you from
making it.
Both of these examples are fine under C89, but the same point also holds
within a single block. You want to limit where a certain identifier is
valid, so you don't use it outside the valid scope.
That's my 2c. The problem with the early returns is something I run into
All. The. Time. I find it really annoying that I constantly have to rewrite
nice linear code into a deeply nested structure just to work around this
limitation.
Nikita
Morning Nikita,
All good points, that it's hard to refute.
However, right now, I know where all variables that are going to be used
are declared, no matter the size of the function or it's complexity. If not
at the very top, eyes get good at scanning for blocks.
What I don't want is to have to scan already complicated code to find out
when a variable was declared.
We need to have rules of thumb, and unless someone can defend their use
rigorously, I would say the rule of thumb that code shouldn't be mixi ought
to be followed. At least it ought to be followed in the top layer of PHP
(anything inside a PHP|ZEND_FUNCTION and such).
A defence of elegance is legitimate, so long as their use does genuinely
increase elegance. Such examples exist, but I think more examples of mixi
code being harder to follow exist ...
Cheers
Joe
On Sat, Nov 12, 2016 at 1:40 PM, Joe Watkins pthreads@pthreads.org
wrote:Morning,
okay, I'm only really interested in declarations mixed with code
Not sure if serious ... but I will harass you to change code that is mixi
[1].I think actually disallowing mixing lends some readability and uniformity
to the code in php-src, that I would hate to see disappear ...Cheers
JoeDepends on the situation.
Very commonly this arbitrary restriction requires me to rewrite code into
a way that is objectively worse, just to avoid repeating initializations.
Typical example: C99 allows me to write nice code like this:void foo(foo_t arg) {
if (!foo_valid(arg)) {
return;
}bar_t bar = get_bar(arg); if (!bar_valid(bar)) { return; } // Lots of variables here for internal computation type1 a = ...; type2 b = ...; type3 c = ...; type4 d = ...;}
The important part is that I can easily do an early-return. C89 instead
forces me to do either this:void foo(foo_t arg1, bar_t arg2) {
bar_t bar;
type1;
type2;
type3;
type4;if (!foo_valid(arg)) { return; } bar = get_bar(arg); if (!bar_valid(bar)) { return; } // Lots of variables here for internal computation a = ...; b = ...; c = ...; d = ...;}
Which I find incredibly ugly, as its repetitive and declarations are far
removed from their source.Alternatively what I can write is this:
void foo(foo_t arg) {
if (foo_valid(arg)) {
bar_t bar = get_bar(arg);
if (bar_valid(bar)) {
// Lots of variables here for internal computation
type1 a = ...;
type2 b = ...;
type3 c = ...;
type4 d = ...;
}
}
}This is also ugly, because it creates deeply nested code. To avoid code
that nests many levels deep, what we often do instead (I'm sure you've seen
this often enough in the php-src codebase) is to instead create huge if
conditions. You know, the kind where the condition has 6 lines and contains
assignments on lines 3 and 5. This is part of the reason.That's one half of the problem. C89 makes early-returns ugly, while I
think it is nowadays universally recognized that early-returns are
preferable over deeply nested code.The other half of the problem is that, as a rule, the lifetime of a
variable should be minimal to avoid misuse. If you have code like thistype var;
if (xyz) {
// ...
} else {
var = 123;
use(var);
}then nothing prevents you from using "var" in the "if" branch, where this
variable is not initialized. If instead you writeif (xyz) {
// ...
} else {
type var = 123;
use(var);
}this mistake fundamentally cannot happen -- the compiler prevents you from
making it.Both of these examples are fine under C89, but the same point also holds
within a single block. You want to limit where a certain identifier is
valid, so you don't use it outside the valid scope.That's my 2c. The problem with the early returns is something I run into
All. The. Time. I find it really annoying that I constantly have to rewrite
nice linear code into a deeply nested structure just to work around this
limitation.Nikita
Morning Nikita,
All good points, that it's hard to refute.
However, right now, I know where all variables that are going to be used
are declared, no matter the size of the function or it's complexity. If not
at the very top, eyes get good at scanning for blocks.What I don't want is to have to scan already complicated code to find out
when a variable was declared.We need to have rules of thumb, and unless someone can defend their use
rigorously, I would say the rule of thumb that code shouldn't be mixi ought
to be followed. At least it ought to be followed in the top layer of PHP
(anything inside a PHP|ZEND_FUNCTION and such).A defence of elegance is legitimate, so long as their use does genuinely
increase elegance. Such examples exist, but I think more examples of mixi
code being harder to follow exist ...Cheers
Joe
I have the feeling that we both sort-of agree, but are really talking about
different things.
There are two ways in which you can have code mixed with declarations. The
first one is within a single "basic block", like this:
int a = ...;
b = ...;
int c = ...;
a = ...;
float d = ...;
// ...
I can totally see how some many people might find this kind of code to be
objectionable.
However, the use-case that I have in mind is different -- it's the case
where declarations are at the top of a block -- but its the top of a
basic block in terms of control flow, not a block in terms of C syntax. To
clarify what I mean by that: For a compiler (and arguably, a programmer),
the control flow of
if (...) {
return;
}
// Basic block starts here, but not C block
type var = ...;
and of
if (...) {
return;
} else {
// Basic block starts here, and C block
type var = ...;
}
is the same. The declaration in both cases is at the top of a control-flow
block. It just doesn't happen to coincide with a syntactic C block.
This is the case I'm interested in.
Anyway, I'll just leave this gem from our codebase here:
https://github.com/php/php-src/blob/master/ext/standard/http_fopen_wrapper.c#L114
(Some of those variables have 500 lines of code between declaration and
first use)
Thanks,
Nikita
Morning Nikita,
It is actually the first kind I'm rebelling against.
I think the second kind might lead people to think we would accept the
first kind, and I think an extreme version of the second kind could also
harm readability.
How about we adopt the rule of thumb that "declarations should be grouped
for clarity" (as sort of suggested by you)
This means you can write the kind of code you want to write, and I can
refuse to merge the kind of code I don't want to merge ?
Cheers
Joe
On Sat, Nov 12, 2016 at 2:21 PM, Joe Watkins pthreads@pthreads.org
wrote:Morning Nikita,
All good points, that it's hard to refute.
However, right now, I know where all variables that are going to be used
are declared, no matter the size of the function or it's complexity. If not
at the very top, eyes get good at scanning for blocks.What I don't want is to have to scan already complicated code to find out
when a variable was declared.We need to have rules of thumb, and unless someone can defend their use
rigorously, I would say the rule of thumb that code shouldn't be mixi ought
to be followed. At least it ought to be followed in the top layer of PHP
(anything inside a PHP|ZEND_FUNCTION and such).A defence of elegance is legitimate, so long as their use does genuinely
increase elegance. Such examples exist, but I think more examples of mixi
code being harder to follow exist ...Cheers
JoeI have the feeling that we both sort-of agree, but are really talking
about different things.There are two ways in which you can have code mixed with declarations. The
first one is within a single "basic block", like this:int a = ...; b = ...; int c = ...; a = ...; float d = ...; // ...I can totally see how some many people might find this kind of code to be
objectionable.However, the use-case that I have in mind is different -- it's the case
where declarations are at the top of a block -- but its the top of a
basic block in terms of control flow, not a block in terms of C syntax. To
clarify what I mean by that: For a compiler (and arguably, a programmer),
the control flow ofif (...) { return; } // Basic block starts here, but not C block type var = ...;and of
if (...) { return; } else { // Basic block starts here, and C block type var = ...; }is the same. The declaration in both cases is at the top of a control-flow
block. It just doesn't happen to coincide with a syntactic C block.This is the case I'm interested in.
Anyway, I'll just leave this gem from our codebase here:
https://github.com/php/php-src/blob/master/ext/standard/
http_fopen_wrapper.c#L114 (Some of those variables have 500 lines of code
between declaration and first use)Thanks,
Nikita
There are two ways in which you can have code mixed with declarations. The
first one is within a single "basic block", like this:int a = ...; b = ...; int c = ...; a = ...; float d = ...; // ...I can totally see how some many people might find this kind of code to be
objectionable.However, the use-case that I have in mind is different -- it's the case
where declarations are at the top of a block -- but its the top of a
basic block in terms of control flow, not a block in terms of C syntax. To
clarify what I mean by that: For a compiler (and arguably, a programmer),
the control flow ofif (...) { return; } // Basic block starts here, but not C block type var = ...;and of
if (...) { return; } else { // Basic block starts here, and C block type var = ...; }is the same. The declaration in both cases is at the top of a control-flow
block. It just doesn't happen to coincide with a syntactic C block.This is the case I'm interested in.
Anyway, I'll just leave this gem from our codebase here:
https://github.com/php/php-src/blob/master/ext/standard/http_fopen_wrapper.c#L114
(Some of those variables have 500 lines of code between declaration and
first use)
In my humble opinion, inline declarations wouldn't make this code
understandable – there are simply way too many variables and the
function is way too large generally, and as such should be broken up.
--
Christoph M. Becker
I am curious why we are not finally doing the switch to C99 with VC14
finally supporting most of C99. I mean, I know that GCC and VC14 do no
fully support C99 but the most common features are implemented:What about other compilers such as Solaris Studio and XL C?
--
Christoph M. Becker--
Last time this came up some of us started putting together test cases
for people to check compilers with. See
https://github.com/FriendsOfPHP/phpnextctest
If you have access to any of these compilers we care about please
test. If you would like to see more kinds of tests please add them.
I am curious why we are not finally doing the switch to C99 with VC14
finally supporting most of C99. I mean, I know that GCC and VC14 do no
fully support C99 but the most common features are implemented:What about other compilers such as Solaris Studio and XL C?
Last time this came up some of us started putting together test cases
for people to check compilers with. See
https://github.com/FriendsOfPHP/phpnextctest
Thanks, Levi.
If you have access to any of these compilers we care about please
test. If you would like to see more kinds of tests please add them.
No, I don't have access to those compilers – I just remember that these
compilers have been mentioned in somewhat recent bug reports, so I
wanted to bring up this issue.
--
Christoph M. Becker
I am curious why we are not finally doing the switch to C99 with VC14
finally supporting most of C99. I mean, I know that GCC and VC14 do no
fully support C99 but the most common features are implemented:What about other compilers such as Solaris Studio and XL C?
Oracle Studio compiler tools are fully compliant with C99 and has been
for a very very long time. I would also note that php7.x does not
compile out of the box, yet. However I am looking into why.
Dennis Clarke
I am curious why we are not finally doing the switch to C99 with VC14
finally supporting most of C99. I mean, I know that GCC and VC14 do no
fully support C99 but the most common features are implemented:What about other compilers such as Solaris Studio and XL C?
Oracle Studio compiler tools are fully compliant with C99 and has been
for a very very long time.
Thanks for the info!
I would also note that php7.x does not
compile out of the box, yet. However I am looking into why.
I remember that there has been an issue with line endings (CRLF) in the
generated parsers/scanners, which had been brought up on the general(?)
mailing list some time ago. Not sure, if that has been resolved.
--
Christoph M. Becker
What about other compilers such as Solaris Studio and XL C?
Oracle Studio compiler tools are fully compliant with C99 and has been
for a very very long time.Thanks for the info!
I would also note that php7.x does not
compile out of the box, yet. However I am looking into why.I remember that there has been an issue with line endings (CRLF) in the
generated parsers/scanners, which had been brought up on the general(?)
mailing list some time ago. Not sure, if that has been resolved.
I don't think that CRLF chars are the issue at all. However, I will
give the source a good run through and be sure to report what I see. I
have had no major issues at all with php 5.5.x and 5.6.x releases but
never see 7.x get past basic configure and build steps. I will look into
why.
Dennis Clarke