[Bug 69751] New: apr_uint64_t wrong on macos __LP64__

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=69751

            Bug ID: 69751
           Summary: apr_uint64_t wrong on macos __LP64__
           Product: APR
           Version: 1.7.6
          Hardware: PC
                OS: Mac OS X 10.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: APR
          Assignee: bugs@apr.apache.org
          Reporter: covener@gmail.com
  Target Milestone: ---

apr.h has:
/*
 * Darwin 10's default compiler (gcc42) builds for both 64 and
 * 32 bit architectures unless specifically told not to.
 * In those cases, we need to override types depending on how
 * we're being built at compile time.
 * NOTE: This is an ugly work-around for Darwin's
 * concept of universal binaries, a single package
 * (executable, lib, etc...) which contains both 32
 * and 64 bit versions. The issue is that if APR is
 * built universally, if something else is compiled
 * against it, some bit sizes will depend on whether
 * it is 32 or 64 bit. This is determined by the __LP64__
 * flag. Since we need to support both, we have to
 * handle OS X unqiuely.
 */
...

#ifdef __LP64__
 typedef  long            apr_int64_t;
 typedef  unsigned long   apr_uint64_t;

...
#else
 typedef  long long            apr_int64_t;
 typedef  unsigned long long   apr_uint64_t;


Which causes problems in httpd maintainer mode where an apr_uint64t is used
with a non-APR API using uint64_t:

ssl_engine_vars.c:976:36: error: incompatible pointer types passing
'apr_uint64_t *' (aka 'unsigned long *') to parameter of type 'uint64_t *' (aka
'unsigned long long *') [-Werror,-Wincompatible-pointer-types]
  976 |     if (SSL_get_handshake_rtt(ssl, &rtt) > 0)
/opt/homebrew/Cellar/openssl@3/3.5.1/include/openssl/ssl.h:2032:58: note:
passing argument to parameter 'rtt' here
 2032 | __owur int SSL_get_handshake_rtt(const SSL *s, uint64_t *rtt);
      |

-/-

This stanza is over my head, but IIUC it's contrasting configure-time with
compile-time, i.e. it seems to try to avoid using configure-time knowledge, but
the base case is just ` typedef  uint64_t          apr_uint64_t` which is
already compile time (if the system has/had two definitions for uint64_t based
on _LP64_ or not). Why do we statically pick one?

Should the typedefs be pulled out of this block?

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

[Bug 69751] apr_uint64_t wrong on macos __LP64__

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=69751

--- Comment #2 from Eric Covener <co...@gmail.com> ---
I guess not hard-coding these is only at the top of the issue, there are still
hard-coded _FMT macros that need to know (and maybe vary, or not)

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

[Bug 69751] apr_uint64_t wrong on macos __LP64__

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=69751

--- Comment #1 from Eric Covener <co...@gmail.com> ---
> Should the typedefs be pulled out of this block?

Not pulled out but removed, with the #else used unconditionally.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org