I've been working on making PHP build under more stringent error
checking, specifically -Wextra under GCC. This patch cleans up dozens
of struct initializations that are valid C, but could hide future
problems.
xoxo,
Andy
--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance
I've been working on making PHP build under more stringent error
checking, specifically -Wextra under GCC. This patch cleans up dozens
of struct initializations that are valid C, but could hide future
problems.
Doesn't C standard mandate filling up uninitialized fields with 0?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
a global struct is filled up with NULL/0's while a local struct is not
initialized at all. The patch simply provides more correct code and even
adds a few consts. I think we should apply this to 5.3 and HEAD. Meaning we
need it for both versions.
marcus
Tuesday, November 27, 2007, 9:53:12 AM, you wrote:
I've been working on making PHP build under more stringent error
checking, specifically -Wextra under GCC. This patch cleans up dozens
of struct initializations that are valid C, but could hide future
problems.
Doesn't C standard mandate filling up uninitialized fields with 0?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Best regards,
Marcus
I've been working on making PHP build under more stringent error
checking, specifically -Wextra under GCC. This patch cleans up
dozens
of struct initializations that are valid C, but could hide future
problems.Doesn't C standard mandate filling up uninitialized fields with 0?
Yes. My patch is for human benefit, not the compiler's.
--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance
IMHO {0} is sufficiently clear for human consumption.
I've been working on making PHP build under more stringent error
checking, specifically -Wextra under GCC. This patch cleans up
dozens
of struct initializations that are valid C, but could hide future
problems.Doesn't C standard mandate filling up uninitialized fields with 0?
Yes. My patch is for human benefit, not the compiler's.
--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance--
Ilia Alshanetsky
IMHO {0} is sufficiently clear for human consumption.
{NULL, 0, 0} brings real structure dimensions to the context, which is
good (less need to check "headers").
I've been working on making PHP build under more stringent error
checking, specifically -Wextra under GCC. This patch cleans up
dozens
of struct initializations that are valid C, but could hide future
problems.Doesn't C standard mandate filling up uninitialized fields with 0?
Yes. My patch is for human benefit, not the compiler's.
--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance--
Ilia Alshanetsky
--
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
IMHO {0} is sufficiently clear for human consumption.
{NULL, 0, 0} brings real structure dimensions to the context, which is
good (less need to check "headers").
It also means that you don't get compiler errors any more like you
would with {0}. Now, you can know that if there's a warning about the
number of initializers that it's something you should pay attention to.
The key for long-term maintenance is to clean up the slop so that the
compiler doesn't squawk about it at high levels of warnings. Then
when you do have real squawk-worthy problems, they don't get lost in
the noise of meaningless warnings.
--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance
GCC will spue a slew of warnings that can be safely ignored and in
some cases are bogus. The pedantic changes only make the code harder
to read and yield very little if any benefits in return. For larger,
more complex structs like zvals it'll only create a meaningless mess.
There is absolutely no reason that any half decent compiler will not
be able to understand {0} for any declared struct.
IMHO {0} is sufficiently clear for human consumption.
{NULL, 0, 0} brings real structure dimensions to the context, which
is
good (less need to check "headers").It also means that you don't get compiler errors any more like you
would with {0}. Now, you can know that if there's a warning about
the number of initializers that it's something you should pay
attention to.The key for long-term maintenance is to clean up the slop so that
the compiler doesn't squawk about it at high levels of warnings.
Then when you do have real squawk-worthy problems, they don't get
lost in the noise of meaningless warnings.--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance
Ilia Alshanetsky
GCC will spue a slew of warnings that can be safely ignored and in
some cases are bogus. The pedantic changes only make the code harder
to read and yield very little if any benefits in return. For larger,
more complex structs like zvals it'll only create a meaningless
mess. There is absolutely no reason that any half decent compiler
will not be able to understand {0} for any declared struct.
My goal here is to improve long-term maintainability of the code, by
letting compilers and tools like splint do their automated magic where
possible. If this is not useful to the PHP core team, then that's
fine, I'll walk away. Let me know either way.
xoa
--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance
Andy,
There is absolutely nothing wrong with trying to make the code more
maintainable, in fact I think everyone, myself included welcome any
work in that direction. But at the same time we need to keep in mind
that compiler is not always right and often will generate meaningless
warnings even when there is absolutely nothing wrong the code. Changes
for the sake of making the compiler happy with -Winsane-warnings ;-)
does not really help maintainability. In the case of {0} vs {NULL,
0,0}, my opinion is that the former is far more readable and
understandable.
GCC will spue a slew of warnings that can be safely ignored and in
some cases are bogus. The pedantic changes only make the code
harder to read and yield very little if any benefits in return. For
larger, more complex structs like zvals it'll only create a
meaningless mess. There is absolutely no reason that any half
decent compiler will not be able to understand {0} for any declared
struct.My goal here is to improve long-term maintainability of the code, by
letting compilers and tools like splint do their automated magic
where possible. If this is not useful to the PHP core team, then
that's fine, I'll walk away. Let me know either way.xoa
--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance
Ilia Alshanetsky
There is absolutely nothing wrong with trying to make the code more
maintainable, in fact I think everyone, myself included welcome any
work in that direction. But at the same time we need to keep in mind
that compiler is not always right and often will generate
meaningless warnings even when there is absolutely nothing wrong the
code. Changes for the sake of making the compiler happy with -
Winsane-warnings ;-) does not really help maintainability. In the
case of {0} vs {NULL,0,0}, my opinion is that the former is far more
readable and understandable.
I'm trying to look at the code with the eyes of a human, trying to use
the compiler as my ally, not something to be circumvented. GCC has
most of the features of a good lint, if we take advantage of it.
Think of it as compiler-enforced coding standards. My goal has been
to try to raise up the coding level of the code that I see, that I'm
using in my day-to-day work. The more seat belts the better, and
initializing structs is just one of them.
Adding consts and fixing signed/unsigned mismatches are on my list,
too, but there's just so much that's slop that I'm trying to get the
low-hanging fruit early.
xoa
--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance
My goal here is to improve long-term maintainability of the code, by
I don't see how unwrapping all structures in initializers improves
maintainability. If anything, it actually makes code harder to maintain
- now on any change you need to go over all the code and fix all the
initializers - a ton of completely meaningless work since a compiler can
do it for you and the standard specifically provides means to do it.
Now if there were non-zero initializers, that would be different, but
with zero inits I don't see any reason not to leave them be.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Doesn't C standard mandate filling up uninitialized fields with 0?
Yes. My patch is for human benefit, not the compiler's.
Not sure I see how it helps - suppose we add a field into structure,
does it mean one has to go over all the code that ever mentioned this
structure and add zeroes? How helpful is that?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Not sure I see how it helps - suppose we add a field into structure,
does it mean one has to go over all the code that ever mentioned this
structure and add zeroes? How helpful is that?
Makes sure you got them all, doesn't it?
xoa
--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance
Not sure I see how it helps - suppose we add a field into structure,
does it mean one has to go over all the code that ever mentioned this
structure and add zeroes? How helpful is that?Makes sure you got them all, doesn't it?
No, the compiler makes sure I got them all, and it does it with {0}.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
No, the compiler makes sure I got them all, and it does it with {0}.
I can tell where this is going. I'll back away now.
xoa
--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance