On 11/28/07, Ezra Nugroho <[EMAIL PROTECTED]> wrote:
> In my mind, it is still unreliable...
> When I write my library, how can I enforce people who adopt it to enable
> ob?
>
> Furthermore, I think it's quite annoying that some functions may not
> work just because of an inclusion of a blank space
On Nov 28, 2007 12:38 AM, Ezra Nugroho <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-11-27 at 14:50 +1000, Rasmus Lerdorf wrote:
> > Ezra Nugroho wrote:
> > > Can I ask for the following support, at least to begin conversation
> > > about it if it hasn't been done before.
> > >
> > > Currently, the h
On Tue, 2007-11-27 at 14:50 +1000, Rasmus Lerdorf wrote:
> Ezra Nugroho wrote:
> > Can I ask for the following support, at least to begin conversation
> > about it if it hasn't been done before.
> >
> > Currently, the header() function still carries the following warning in
> > its online document
One word: transparency.
It is amazing how it helps to discuss things instead of acting like that.
--Pierre
On Nov 27, 2007 11:51 PM, Hannes Magnusson <[EMAIL PROTECTED]> wrote:
> > +^pdo-specs $CVSROOT/CVSROOT/loginfo.pl [EMAIL PROTECTED] $USER %{sVv}
>
> For consistency with the rest of the co
> +^pdo-specs $CVSROOT/CVSROOT/loginfo.pl [EMAIL PROTECTED] $USER %{sVv}
For consistency with the rest of the commit dedicated mailinglists,
should this list be named [EMAIL PROTECTED]
And out of curiosity (since the word is that Microsoft has a hand in
this), who will be the patent holder? ;)
Contributing to PDO, referred by wez.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
All will be revealed soon.
--Wez.
On Nov 27, 2007, at 2:56 PM, Antony Dovgal wrote:
Hello Wez.
Please explain what is this 'pdo-specs' thing and why CLA is needed
to commit there.
For some reason I thought we've agreed that CLA/NDA-protected or any
other restricted-access things should
PDO working group - Specs
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
Wez Furlong wrote:
> What purpose does this serve exactly?
PDO::FETCH_KEYS is supposed to be a "generalized" form of the existing
PDO::FETCH_KEY_PAIR. The latter is limited to two column results and
organises it into key=>value.
PDO::FETCH_2D is an IMHO better strategy than the existing
ATT
Hello Wez.
Please explain what is this 'pdo-specs' thing and why CLA is needed to commit
there.
For some reason I thought we've agreed that CLA/NDA-protected or any other
restricted-access things should not be placed into PHP CVS.
pdo_odbc and other "read-but-do-not-write" stuff have already d
What purpose does this serve exactly?
Why do we need to allocate an empty string for every database
connection?
Why do we need this in the core?
There's a lot of manipulation being done here that is better suited to
happen in PHP script land where it's safer and easier to maintain.
--Wez.
On Tue, Nov 27, 2007 at 10:30:35AM -0800, Stanislav Malyshev ([EMAIL
PROTECTED]) wrote:
> 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 => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
--
P
you are quoting c99…
and we are still using "c90" mode, as far as I remember
I couldn't find any c90 available online for free but anyway that's
long-standing practice that all compilers I know follow. gcc's own
manual says:
-Wmissing-field-initializers
Warn if a structure's initializer
Hoi!
Marcus Boerger wrote:
> can you add tests so we get a better idea?
> cvs add ; cvd di -N > patchfile.txt
I could... If I had a cvs account.
As I don't, please find attached an updated patch (I hope I got the zval
allocation right) as well as:
- pdo_034.phpt (updated in patch)
- pdo_035.
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
you are quoting c99…
and we are still using "c90" mode, as far as I remember
On 11/27/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > 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
>
> That
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
> 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 => [EMAIL PROTECTED] => www.petdance.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? Ho
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
That's not what I read in C standard - it says that if struct is
partially initialized, the rest is zeroed out:
Quoting http://c0x.coding-guideline
On Nov 27, 2007, at 9:57 AM, Ilia Alshanetsky wrote:
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 righ
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
On Nov 27, 2007, at 9:49 AM, Ilia Alshanetsky wrote:
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
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 absolut
On Nov 27, 2007, at 8:34 AM, Alexey Zakhlestin wrote:
On 11/27/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
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 tha
On 11/27/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> 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").
> On 27-Nov-07, at 8:49 AM, Andy Lester wrote:
>
> >
> > On Nov 27, 2007, at
IMHO {0} is sufficiently clear for human consumption.
On 27-Nov-07, at 8:49 AM, Andy Lester wrote:
On Nov 27, 2007, at 2:53 AM, Stanislav Malyshev wrote:
I've been working on making PHP build under more stringent error
checking, specifically -Wextra under GCC. This patch cleans up
dozens
On Nov 27, 2007, at 2:53 AM, Stanislav Malyshev 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 mand
-- Forwarded message --
From: nick loeve <[EMAIL PROTECTED]>
Date: Nov 27, 2007 11:39 AM
Subject: Re: Fwd: [PHP-DEV] Bug 42773 - WSDL error causes HTTP 500 Response
To: Rob Richards <[EMAIL PROTECTED]>
On Nov 27, 2007 11:33 AM, Rob Richards <[EMAIL PROTECTED]> wrote:
>
> nick loe
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, 2
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 Maly
31 matches
Mail list logo
