[openssl-project] OS/X builds failing

[Matt Caswell]

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   : %8ju\n", BIO_number_read(in));
 ^~~
%8llu
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));
 ^~~
%8llu
2 errors generated.


The thing is though this is *our* BIO_printf, and we do seem to expect a
uint64_t for a "%ju". So I'm not sure how to fix that.

Matt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] OS/X builds failing

[Andy Polyakov]

> 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));
>  ^~~
> %8llu
> 2 errors generated.
> 
> 
> The thing is though this is *our* BIO_printf, and we do seem to expect a
> uint64_t for a "%ju". So I'm not sure how to fix that.

I'd suggest -Wno-format. With rationale that a) Xcode is arguably
somewhat unreasonable, b) we can rely on Linux builds to catch warnings
that actually matter.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] OS/X builds failing

[Viktor Dukhovni]

> 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
> long long') [-Werror,-Wformat]
>BIO_printf(bio_err, "bytes read   : %8ju\n", BIO_number_read(in));
> ^~~
>%8llu
> 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));
> ^~~
>%8llu
> 2 errors generated.
> 
> 
> The thing is though this is *our* BIO_printf, and we do seem to expect a
> uint64_t for a "%ju". So I'm not sure how to fix that.

The obvious and correct fix is to cast the output of BIO_number_read() and
BIO_number_written() to uintmax_t.  And we should expect uintmax_t with %j,
even in our BIO_printf().  It happens to be 64-bit on all the platforms we
support perhaps (any Crays?), but that's just a coincidence.

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] OS/X builds failing

[Viktor Dukhovni]

> 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 new
one, but that's a bad idea.  So I think the "or ..." part is
not a good idea.

Just cast to (intmax_t) or use OSSL_PRIi64/OSSL_PRIu64 (defined
to PRIi64/PRIu64 where available or else to some appropriate
letter for the platform in question).

BIO_printf should handle the underlying primitive types when,
e.g., encountering "%lu", "%llu", "%ju" and "%zu"...

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] OS/X builds failing

[Viktor Dukhovni]

> 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 telling you that their definitions are independent, and they *could*
be different, and so the code is not portable.

> (that error does surprise me, since uintmax_t is supposed to be the
> largest integer type possible, and yet, the error suggests that this
> isn't the case here)

See above.  Compiling the below on the latest MacOS/X:

$ 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(unsigned int));
printf("long = %zu\n", sizeof(unsigned long int));
printf("long long = %zu\n", sizeof(unsigned long long int));

printf("int8_t = %zu\n", sizeof(uint8_t));
printf("int16_t = %zu\n", sizeof(uint16_t));
printf("int32_t = %zu\n", sizeof(uint32_t));
printf("int64_t = %zu\n", sizeof(uint64_t));
printf("intmax_t = %zu\n", sizeof(uintmax_t));
return 0;
}

shows that long, long long, int64_t and intmax_t are presently all the same:

$ ./size
char = 1
short = 2
int = 4
long = 8
long long = 8
int8_t = 1
int16_t = 2
int32_t = 4
int64_t = 8
intmax_t = 8

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] OS/X builds failing

[Andy Polyakov]

>> 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));
>>  ^~~
>> %8llu
>> 2 errors generated.
>>
>>
>> The thing is though this is *our* BIO_printf, and we do seem to expect a
>> uint64_t for a "%ju". So I'm not sure how to fix that.
> 
> I'd suggest -Wno-format. With rationale that a) Xcode is arguably
> somewhat unreasonable, b) we can rely on Linux builds to catch warnings
> that actually matter.

Another possibility *could* be suppressing corresponding __attribute__
in bio.h, but it's public header, so question would be if change can be
justified in minor release. Just in case, suppress specifically for
Xcode [which would cover even iOS].
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Draft Travel Reimbursement policy

[Salz, Rich]

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 action item to draft a travel reimbursement policy. 
 Here’s a starting point.  After discussion dies down I’ll post it to the 
bureau and vote.


The OpenSSL project may pay travel expenses for OMC members when pre-approved 
by the OMC or when it is an official OMC meeting (as determined by vote). 
Project members may seek to be reimbursed if their employer is not covering the 
expense. The requirements for reimbursement are:


  *   An email sent to openssl-omc, including scanned attachments of all 
receipts over 30 Euro’s.
  *   Barring exceptional circumstances, for an all-day meeting the project 
will pay for arrival the day before and departure the following morning.
  *   When presenting at a conference, the project will pay the expenses for 
the entire conference provided the attendee agrees to act as representative of 
the project during that time.
  *   Reasonable lodging and meal expenses during the travel time will be 
covered.
  *   Barring exceptional circumstances, room service, minibar, in-room movies, 
and other similar amenities are not covered.


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] OS/X builds failing

[Andy Polyakov]

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-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project