[PATCH] Use int64 and int32 types with GCC atomics

[Maxim Dounin]

Hello!

On Fri, Sep 16, 2016 at 02:44:38PM +0100, Alessandro Ghedini wrote:

> # HG changeset patch
> # User Alessandro Ghedini <alessandro at ghedini.me>
> # Date 1474033303 -3600
> #      Fri Sep 16 14:41:43 2016 +0100
> # Node ID 64afed0e819b9af65e7afa89baad3313f1db18d4
> # Parent  e83540f825cd8c936f4f7f1e0336279d66446606
> Use int64 and int32 types with GCC atomics
> 
> It's not quite clear if this was done on purpose, but it seems a good
> idea to use appropriately sized types when GCC atomics are used.

The "long" is expected to be one of the most native types 
available, and I see no problem with using it as long as it is 
understood by builtins used (it is).  It is also in line with the 
configure test we use to find it out if GCC atomic ops are 
present:

    ngx_feature_test="long  n = 0;
                      if (!__sync_bool_compare_and_swap(&n, 0, 1))
                          return 1;
                      if (__sync_fetch_and_add(&n, 1) != 1)
                          return 1;
                      if (n != 2)
                          return 1;
                      __sync_synchronize();"

Changing the code to diverge from the test as your patch doesn't 
looks like a good idea, and I would rather preserve this as 
is unless there are better reasons than "seems a good idea".

Note well that we anyway use the long for ngx_atomic*_t when using 
libatomic where this is the only option available.  That is, 
atomic types may not match pointer sizes, and nginx is expected to 
deal with this anyway.

-- 
Maxim Dounin
http://nginx.org/