Yes, I misspoke, unsigned( int) to int is conversion not so undefined wrt 0.
I was also thinking about what is actually a uint32_t to int conversion,
that may lead to truncation if sizeof(int) < 4, but I guess these archs
aren't supported by APR already, since there is no (assembly) code to rely
o
"defect"?
We support UDS in ProxyPass. We don't in mod_rewrite.
Nor do we claim to. I don't think that's a "defect".
If later on UDS support is *also* added to mod_rewrite,
then good. But not having it there isn't, IMO, any
reason to not include it where we say it is, and
where we see it works.
If a is unsigned int and its value is, say, 10, then
the conversion (int)a is allowed, since that value
(10) can be expressed both as a signed int or an
unsigned one.
However, if a is 4,294,967,200, then the behavior
of (int)a is undefined and implementation dependent,
since you can't express that
Undefined means that the specification does not define
what happens, and that people cannot expect anything,
since what happens is implementation dependent.
On Jan 9, 2014, at 8:49 AM, Mattias Engdegård wrote:
> 9 jan 2014 kl. 14.37 skrev Jim Jagielski:
>
>> However, if a is 4,294,967,200, then
On Thu, Jan 09, 2014 at 09:52:57AM -0500, Jim Jagielski wrote:
> Undefined means that the specification does not define
> what happens, and that people cannot expect anything,
> since what happens is implementation dependent.
As an example: Undefined means it could crash. Or, as the saying goes, t
And for the record, I am ignoring the verbal quibble that
implementation-define means it's defined or that something
which is implementation-dependent is or is not "defined".
This isn't a pedantic-C mailing list and the difference
between the 2 is moot in *this* discussion.
On Jan 9, 2014, at 9:52
sweet sassy molassy... what if the implementation defines that
behavior as spawning small gnomes? Then it's OK? That
would be defined and implementation-defined, but so what?
We are talking about end-result expectations! Geez.
On Jan 9, 2014, at 9:56 AM, Steinar H. Gunderson wrote:
> On Thu, Jan
On Thu, Jan 09, 2014 at 10:06:46AM -0500, Jim Jagielski wrote:
> sweet sassy molassy... what if the implementation defines that
> behavior as spawning small gnomes? Then it's OK? That
> would be defined and implementation-defined, but so what?
No, it needs to output an integer (without crashing or
you are missing the point by focusing on the pedantics of
language policing. Whatever.
On Jan 9, 2014, at 10:10 AM, Steinar H. Gunderson
wrote:
> On Thu, Jan 09, 2014 at 10:06:46AM -0500, Jim Jagielski wrote:
>> sweet sassy molassy... what if the implementation defines that
>> behavior as spawn
Hello Jim,
I would like to make a suggestion that is off topic from the last couple
of replies but pertinent to a T&R of 2.4.8.
If anyone is interested in having mod_remoteip work correctly in Apache
httpd 2.4.8,
then the following bug reports and patches might be worth considering:
- https
Thx! I'd like to have Bill look over these. :)
On Jan 9, 2014, at 10:38 AM, Mike Rumph wrote:
> Hello Jim,
>
> I would like to make a suggestion that is off topic from the last couple of
> replies but pertinent to a T&R of 2.4.8.
>
> If anyone is interested in having mod_remoteip work correct
On 09.01.2014 19:48, jaillet...@apache.org wrote:
> Author: jailletc36
> Date: Thu Jan 9 18:48:11 2014
> New Revision: 1556914
>
> URL: http://svn.apache.org/r1556914
> Log:
> Add missing break in 'dav_generic_do_refresh' to avoid useless computation.
>
> Modified:
> httpd/httpd/trunk/module
I can certainly apply and propose for back port the defect fixes, this week.
Those which change the configured behavior in an unexpected way are no
longer easy fits on 2.2 or 2.4, and need further discussion about their
urgency here on list. It would also be good to leave enhancements on
trunk/ f
Sure,
but I personally prefer to keep only one exit point in functions.
Just a matter of taste.
CJ
Le 09/01/2014 20:17, Rainer Jung a écrit :
On 09.01.2014 19:48, jaillet...@apache.org wrote:
Author: jailletc36
Date: Thu Jan 9 18:48:11 2014
New Revision: 1556914
URL: http://svn.apache.org/
On Thu, 2014-01-09 at 14:15 -0600, William A. Rowe Jr. wrote:
> I can certainly apply and propose for back port the defect fixes, this
> week.
>
> Those which change the configured behavior in an unexpected way are no
> longer easy fits on 2.2 or 2.4, and need further discussion about
> their
15 matches
Mail list logo