The new travis OS/X builds are failing with this:
-MT apps/enc.o -c -o apps/enc.o apps/enc.c
apps/enc.c:567:54: error: format specifies type 'uintmax_t' (aka
'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned
long long') [-Werror,-Wformat]
BIO_printf(bio_err, "bytes read
> apps/enc.c:568:54: error: format specifies type 'uintmax_t' (aka
> 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned
> long long') [-Werror,-Wformat]
> BIO_printf(bio_err, "bytes written: %8ju\n",
> BIO_number_written(out));
>
>> apps/enc.c:568:54: error: format specifies type 'uintmax_t' (aka
>> 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned
>> long long') [-Werror,-Wformat]
>> BIO_printf(bio_err, "bytes written: %8ju\n",
>> BIO_number_written(out));
>>
Any commentary on this? Otherwise I’ll do a (two-week) vote next week.
From: Rich Salz
Reply-To: "openssl-project@openssl.org"
Date: Monday, January 29, 2018 at 11:18 AM
To: "openssl-project@openssl.org"
Subject: [openssl-project] Draft Travel Reimbursement policy
At the London F2F I had the
For the record. I don't generally appreciate fast commits, but I feel
like 100 times stronger when it comes to public headers [naturally in
supported or minor release] and I can't qualify 19 minutes turnaround
for merge request as appropriate.
___
openssl
> On Feb 9, 2018, at 5:15 AM, Matt Caswell wrote:
>
> The new travis OS/X builds are failing with this:
>
> -MT apps/enc.o -c -o apps/enc.o apps/enc.c
> apps/enc.c:567:54: error: format specifies type 'uintmax_t' (aka
> 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned
> lon
In message on Fri, 9 Feb
2018 11:03:40 -0500, Viktor Dukhovni said:
openssl-users>
openssl-users>
openssl-users> > On Feb 9, 2018, at 5:15 AM, Matt Caswell
wrote:
openssl-users> >
openssl-users> > The new travis OS/X builds are failing with this:
openssl-users> >
openssl-users> > -MT apps
> On Feb 9, 2018, at 11:23 AM, Richard Levitte wrote:
>
> From those errors, it looks to me like uintmax_t isn't 64-bit on that
> Mac OS/X machine, unless 'unsigned long' and 'unsigned long long' are
> the same.
No, the compiler is not telling you they're not actually the same, rather
it is te
> On Feb 9, 2018, at 11:36 AM, Viktor Dukhovni
> wrote:
>
> $ cat size.c
> #include
> #include
>
> int main(int argc, char **argv)
> {
>printf("char = %zu\n", sizeof(unsigned char));
>printf("short = %zu\n", sizeof(unsigned short));
>printf("int = %zu\n", sizeof(unsi
On Fri, Feb 09, 2018 at 11:52:48AM -0500, Viktor Dukhovni wrote:
>
> Still, we're wrong to use int64_t values with "%j" formats. All format
> arguments to "%j" need to be "intmax_t".
We document printf to be like the C standard, so it should be
intmax_t, not int64_t, or we need to fix the docume
> On Feb 9, 2018, at 12:39 PM, Kurt Roeckx wrote:
>
> We document printf to be like the C standard, so it should be
> intmax_t, not int64_t, or we need to fix the documentation.
I don't think we get to coöpt "j" for another purpose, if we
we want a letter format for int64t, we'll need to use a
11 matches
Mail list logo
