Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD
On Thu, Jan 17, 2019 at 2:18 PM Stefan Sperling wrote: > > I would appreciate if someone could commit my configure.in patch > which adds overrides for OpenBSD specifically. That would fix my > immediate problem. And perhaps a better fix could be devised later? > I'd prefer we not glue around this quirk, and simply move forward with autoconf tests for successful use of %d %ld %lld %I64d in that order of preference prior to any subsequent APR releases. This isn't horribly complicated autoconf logic. I have no cycles today, but should have cycles over the long weekend unless someone beats me to it.
Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD
On Thu, Jan 17, 2019 at 03:40:26PM +0100, Stefan Eissing wrote: > I had the issue in one of my configure.ac that the extra CPPFLAGS were not > added, as from > > > apxs -q EXTRA_CPPFLAGS > > and it all compiled, except APR_OFF_T_FMT was ld instead of lld on MacOS. > > Maybe this is the same effect? The situation on MacOS is slightly different. There are specific overrides related to apr_off_t and other such types under #ifdef DARWIN_10 in apr.h: [[[ /* * Ensure we work with universal binaries on Darwin */ #ifdef DARWIN_10 #undef APR_HAS_LARGE_FILES #undef APR_SIZEOF_VOIDP #undef APR_INT64_T_FMT #undef APR_UINT64_T_FMT #undef APR_UINT64_T_HEX_FMT #ifdef __LP64__ #define APR_HAS_LARGE_FILES 0 #define APR_SIZEOF_VOIDP 8 #define APR_INT64_T_FMT "ld" #define APR_UINT64_T_FMT "lu" #define APR_UINT64_T_HEX_FMT "lx" #else #define APR_HAS_LARGE_FILES 1 #define APR_SIZEOF_VOIDP 4 #define APR_INT64_T_FMT "lld" #define APR_UINT64_T_FMT "llu" #define APR_UINT64_T_HEX_FMT "llx" #endif #undef APR_IS_BIGENDIAN #ifdef __BIG_ENDIAN__ #define APR_IS_BIGENDIAN 1 #else #define APR_IS_BIGENDIAN 0 #endif #undef APR_OFF_T_FMT #define APR_OFF_T_FMT "lld" #endif /* DARWIN_10 */ ]]]
Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD
On Thu, Jan 17, 2019 at 03:24:41PM +0100, Branko Čibej wrote:
> On 17.01.2019 13:28, Stefan Sperling wrote:
> > On Thu, Jan 10, 2019 at 01:17:40AM +0100, Branko Čibej wrote:
> >> I get that part, my question was related to APR's configure setting the
> >> type of apr_off_t and its format specifier correctly on Linux but
> >> incorrectly on OpenBSD, even though they're equivalent.
> > It seems to be wrong on Linux as well.
> >
> > This is on a Debian 8.11 / amd64 system:
> >
> > $ cat test.c
> > #include
> > #include
> > #include
> > int main()
> > {
> > printf("sizeof(off_t)=%zd\n", sizeof(off_t));
> > printf("sizeof(long)=%zd\n", sizeof(long));
> > printf("sizeof(long long)=%zd\n", sizeof(long long));
> > printf("APR_OFF_T_FMT=" APR_OFF_T_FMT "\n");
> > return 0;
> > }
> > $ cc -o test test.c
> > $ ./test
> > sizeof(off_t)=8
> > sizeof(long)=8
> > sizeof(long long)=8
> > APR_OFF_T_FMT=ld
>
> That doesn't tell me anything the question is, what is the typedef
> for apr_off_t on linux? if it's 'long' there but 'long long' on OpenBSD,
> then *something* is being done specially there.
>
> FWIW: All these types (apr_off_t, apr_size_t, apr_ssize_t) should be set
> to their OS/ABI underlying types where those are available. But they're
> not as far as I know.
You are right. The definition seems to be fine on Linux.
>From apr.h on that system:
typedef size_t apr_size_t;
typedef ssize_t apr_ssize_t;
typedef off_t apr_off_t;
So apr_off_t is off_t, which per above test program is 8 bytes long.
If I followed the maze of header files correctly it boils down to 'long int':
unistd.h:
# ifndef __off_t_defined
# ifndef __USE_FILE_OFFSET64
typedef __off_t off_t;
# else
typedef __off64_t off_t;
# endif
x86_64-linux-gnu/bits/typesizes.h:
#define __OFF_T_TYPE__SYSCALL_SLONG_TYPE
# define __SYSCALL_SLONG_TYPE __SLONGWORD_TYPE
x86_64-linux-gnu/bits/types.h
#define __SLONGWORD_TYPElong int
Note that these definitions differ for the 32 bit emulation ABI where
off_t instead boils down to 'long long int', via the _quad_t type.
I suppose a 32 bit APR library running on 64 bit would require "lld",
and this should work because APR's configure script should see
sizeof(long) == 4 in this case.
Whereas on OpenBSD, off_t is a 'long long' on all platforms, and
there is no 32 bit emulation which could change sizes of such types.
I would appreciate if someone could commit my configure.in patch
which adds overrides for OpenBSD specifically. That would fix my
immediate problem. And perhaps a better fix could be devised later?
Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD
I had the issue in one of my configure.ac that the extra CPPFLAGS were not
added, as from
> apxs -q EXTRA_CPPFLAGS
and it all compiled, except APR_OFF_T_FMT was ld instead of lld on MacOS.
Maybe this is the same effect?
Cheers, Stefan
> Am 17.01.2019 um 15:24 schrieb Branko Čibej :
>
> On 17.01.2019 13:28, Stefan Sperling wrote:
>> On Thu, Jan 10, 2019 at 01:17:40AM +0100, Branko Čibej wrote:
>>> I get that part, my question was related to APR's configure setting the
>>> type of apr_off_t and its format specifier correctly on Linux but
>>> incorrectly on OpenBSD, even though they're equivalent.
>> It seems to be wrong on Linux as well.
>>
>> This is on a Debian 8.11 / amd64 system:
>>
>> $ cat test.c
>> #include
>> #include
>> #include
>> int main()
>> {
>>printf("sizeof(off_t)=%zd\n", sizeof(off_t));
>>printf("sizeof(long)=%zd\n", sizeof(long));
>>printf("sizeof(long long)=%zd\n", sizeof(long long));
>>printf("APR_OFF_T_FMT=" APR_OFF_T_FMT "\n");
>>return 0;
>> }
>> $ cc -o test test.c
>> $ ./test
>> sizeof(off_t)=8
>> sizeof(long)=8
>> sizeof(long long)=8
>> APR_OFF_T_FMT=ld
>
> That doesn't tell me anything the question is, what is the typedef
> for apr_off_t on linux? if it's 'long' there but 'long long' on OpenBSD,
> then *something* is being done specially there.
>
> FWIW: All these types (apr_off_t, apr_size_t, apr_ssize_t) should be set
> to their OS/ABI underlying types where those are available. But they're
> not as far as I know.
>
> -- Brane
>
Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD
On 17.01.2019 13:28, Stefan Sperling wrote:
> On Thu, Jan 10, 2019 at 01:17:40AM +0100, Branko Čibej wrote:
>> I get that part, my question was related to APR's configure setting the
>> type of apr_off_t and its format specifier correctly on Linux but
>> incorrectly on OpenBSD, even though they're equivalent.
> It seems to be wrong on Linux as well.
>
> This is on a Debian 8.11 / amd64 system:
>
> $ cat test.c
> #include
> #include
> #include
> int main()
> {
> printf("sizeof(off_t)=%zd\n", sizeof(off_t));
> printf("sizeof(long)=%zd\n", sizeof(long));
> printf("sizeof(long long)=%zd\n", sizeof(long long));
> printf("APR_OFF_T_FMT=" APR_OFF_T_FMT "\n");
> return 0;
> }
> $ cc -o test test.c
> $ ./test
> sizeof(off_t)=8
> sizeof(long)=8
> sizeof(long long)=8
> APR_OFF_T_FMT=ld
That doesn't tell me anything the question is, what is the typedef
for apr_off_t on linux? if it's 'long' there but 'long long' on OpenBSD,
then *something* is being done specially there.
FWIW: All these types (apr_off_t, apr_size_t, apr_ssize_t) should be set
to their OS/ABI underlying types where those are available. But they're
not as far as I know.
-- Brane
Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD
On Thu, Jan 10, 2019 at 01:17:40AM +0100, Branko Čibej wrote:
> I get that part, my question was related to APR's configure setting the
> type of apr_off_t and its format specifier correctly on Linux but
> incorrectly on OpenBSD, even though they're equivalent.
It seems to be wrong on Linux as well.
This is on a Debian 8.11 / amd64 system:
$ cat test.c
#include
#include
#include
int main()
{
printf("sizeof(off_t)=%zd\n", sizeof(off_t));
printf("sizeof(long)=%zd\n", sizeof(long));
printf("sizeof(long long)=%zd\n", sizeof(long long));
printf("APR_OFF_T_FMT=" APR_OFF_T_FMT "\n");
return 0;
}
$ cc -o test test.c
$ ./test
sizeof(off_t)=8
sizeof(long)=8
sizeof(long long)=8
APR_OFF_T_FMT=ld
Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD
On 09.01.2019 23:47, William A Rowe Jr wrote: > On Wed, Jan 9, 2019 at 3:26 PM Branko Čibej wrote: > >>> On Wed, Jan 9, 2019 at 9:38 AM Stefan Sperling wrote: >>> APR's configure script logic results in inconsistent type and format string definitions on OpenBSD. apr_off_t is defined as 'long long' but APR_OFF_T_FMT is defined as "ld". /home/stsp/svn/src/httpd-2.4.37/server/util_expr_eval.c:1144:56: error: format specifies type 'long' but the argument has type 'apr_off_t' (aka 'long long') [-Werror,-Wformat] return apr_psprintf(ctx->p, "%" APR_OFF_T_FMT, sb.size); This happens because off_t is defined as 'long long', and because sizeof(long) and sizeof(long long) are both 8, on OpenBSD/amd64. This looks like a generic problem, but I am not sure the existing logic could be make to work in general. Switching the order of checks makes the configure script produce valid results on OpenBSD but I am not sure if that would >> be a correct thing to do on other platforms. >> How come this works on x86_64 Linux, which is also LP64? >> > As a cautionary measure the compiler in here disambiguates > printf formatting int from long from long long, even if they are > identities. This helps detect invalid code as the code is moved > from the current x86_64 model to one supporting longer long long > or shorter long types. The compiler is right, it's beneficial. I get that part, my question was related to APR's configure setting the type of apr_off_t and its format specifier correctly on Linux but incorrectly on OpenBSD, even though they're equivalent. -- Brane
Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD
On Wed, Jan 9, 2019 at 3:26 PM Branko Čibej wrote: > > On Wed, Jan 9, 2019 at 9:38 AM Stefan Sperling wrote: > > > >> APR's configure script logic results in inconsistent type and format > >> string definitions on OpenBSD. apr_off_t is defined as 'long long' > >> but APR_OFF_T_FMT is defined as "ld". > >> > >> /home/stsp/svn/src/httpd-2.4.37/server/util_expr_eval.c:1144:56: error: > >> format specifies type 'long' but the argument has type 'apr_off_t' > >> (aka 'long long') [-Werror,-Wformat] > >> > >> return apr_psprintf(ctx->p, "%" APR_OFF_T_FMT, sb.size); > >> > >> This happens because off_t is defined as 'long long', and because > >> sizeof(long) and sizeof(long long) are both 8, on OpenBSD/amd64. > >> > >> This looks like a generic problem, but I am not sure the existing logic > >> could > >> be make to work in general. Switching the order of checks makes the > >> configure > >> script produce valid results on OpenBSD but I am not sure if that would > be > >> a > >> correct thing to do on other platforms. > > How come this works on x86_64 Linux, which is also LP64? > As a cautionary measure the compiler in here disambiguates printf formatting int from long from long long, even if they are identities. This helps detect invalid code as the code is moved from the current x86_64 model to one supporting longer long long or shorter long types. The compiler is right, it's beneficial.
Re: [PATCH] apr_off_t is 'long long' but APR_OFF_T_FMT is "ld" on OpenBSD
On Wed, Jan 9, 2019 at 9:38 AM Stefan Sperling wrote: > APR's configure script logic results in inconsistent type and format > string definitions on OpenBSD. apr_off_t is defined as 'long long' > but APR_OFF_T_FMT is defined as "ld". > > This results in obvious build failures e.g. if httpd is built with -Werror. > This is just one example of many such errors: > > /home/stsp/svn/src/httpd-2.4.37/server/util_expr_eval.c:1144:56: error: > format > specifies type 'long' but the argument has type 'apr_off_t' > > (aka 'long long') [-Werror,-Wformat] > > return apr_psprintf(ctx->p, "%" APR_OFF_T_FMT, sb.size); > > ~~~ ^~~ > > This happens because off_t is defined as 'long long', and because > sizeof(long) and sizeof(long long) are both 8, on OpenBSD/amd64. > > The configure script section which sets APR_OFF_T_FMT first checks for: > "$ac_cv_sizeof_off_t" = "$ac_cv_sizeof_long" > and sets APR_OFF_T_FMT to "ld", before it checks for: > "$ac_cv_sizeof_off_t" = "$ac_cv_sizeof_long_long". > > This looks like a generic problem, but I am not sure the existing logic > could > be make to work in general. Switching the order of checks makes the > configure > script produce valid results on OpenBSD but I am not sure if that would be > a > correct thing to do on other platforms. > > Since the existing logic apparently works on other platforms it's > probably best to leave as it is and add an override for OpenBSD. > However, any platform where off_t is 'long long' and long is a 64 bit > type is affected by this issue. Couldn't some AC_TRY_COMPILE()s with -Wall catch this? I'd prefer we continue to attempt these in %d %ld %lld %I64d order. Least complex and most portable first.
