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
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
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
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
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
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
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
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
If the unsigned quantity can be expressed as a signed
quantity, then all is well. The only undefined behavior
(implementation specific) is if it can't be. However,
the conversion from a non-0 quantity to a 0 would
be extremely unlikely. You'd get an unexpected signed
value, but I can't imagine any
From: Yann Ylavic
Sent: Mittwoch, 8. Januar 2014 16:57
To: httpd; apr
Subject: Re: Event and atomics, round II
On Wed, Jan 8, 2014 at 2:03 PM, Jim Jagielski
mailto:j...@jagunet.com>> wrote:
On Jan 7, 2014, at 3:15 PM, Jeff Trawick
mailto:traw...@gmail.com>> wrote:
>
> +1 f
On Wed, Jan 8, 2014 at 2:03 PM, Jim Jagielski wrote:
>
> On Jan 7, 2014, at 3:15 PM, Jeff Trawick wrote:
> >
> > +1 for APR trunk, +0.9 for future APR 1.6.x, -0.9 for APR 1.5.x...
> >
> > alternate opinions?
> >
>
> As far as I know, C guarantees that
>
> if (a)
>
> is the same as
>
>
> -Original Message-
> From: Jim Jagielski
> Sent: Mittwoch, 8. Januar 2014 14:03
> To: Jeff Trawick
> Cc: Apache HTTP Server Development List; apr
> Subject: Re: Event and atomics, round II
>
>
> On Jan 7, 2014, at 3:15 PM, Jeff Trawick wrote:
> &g
On Jan 7, 2014, at 3:15 PM, Jeff Trawick wrote:
>
> +1 for APR trunk, +0.9 for future APR 1.6.x, -0.9 for APR 1.5.x...
>
> alternate opinions?
>
As far as I know, C guarantees that
if (a)
is the same as
if (a != 0)
So I'm unsure of the need for this patch.
On Tue, Jan 7, 2014 at 12:38 PM, Yann Ylavic wrote:
> Hi,
>
> I cc to APR's dev list so to propose a patch regarding
> apr_atomic_dec32()platform dependent return
> values.
>
> On Mon, Jan 6, 2014 at 5:27 PM, Yann Ylavic wrote:
>
>>
>> On Mon, Dec 16, 2013 at 4:25 PM, Jim Jagielski wrote:
>>
>
Hi,
I cc to APR's dev list so to propose a patch regarding
apr_atomic_dec32()platform dependent return
values.
On Mon, Jan 6, 2014 at 5:27 PM, Yann Ylavic wrote:
>
> On Mon, Dec 16, 2013 at 4:25 PM, Jim Jagielski wrote:
>
>> Now that 2.4.7 has been out for awhile, I would have assumed
>> that
On Mon, Dec 16, 2013 at 4:25 PM, Jim Jagielski wrote:
> Now that 2.4.7 has been out for awhile, I would have assumed
> that if people were hitting the "atomics not working as
> expected" error (using unsigned as signed), we would have
> started hearing about it... But, afaik, we haven't.
>
Since
Yes, it is complete.
On Dec 31, 2013, at 7:26 AM, Falco Schwarz wrote:
> Our company would have run into the problem, though I knew it beforehand and
> avoided the problem on affected servers by switching back to prefork. We have
> setup our servers to build all shared mpms anyways, so this wa
Our company would have run into the problem, though I knew it beforehand and
avoided the problem on affected servers by switching back to prefork. We have
setup our servers to build all shared mpms anyways, so this wasn’t a big
problem.
All the affected systems were in fact 32bit SLES (10 and 1
Now that 2.4.7 has been out for awhile, I would have assumed
that if people were hitting the "atomics not working as
expected" error (using unsigned as signed), we would have
started hearing about it... But, afaik, we haven't.
So this leads me to the following discussion: should we stay
with the "
19 matches
Mail list logo
