Fix bunch of printf warnings

Signed-off-by: Max <max.suraev@fairwaves.co>
---
 openbsc/src/libbsc/bsc_api.c         |  4 ++--
 openbsc/src/libmgcp/mgcp_protocol.c  |  2 +-
 openbsc/tests/abis/abis_test.c       | 16 ++++++++--------
 openbsc/tests/gbproxy/gbproxy_test.c | 16 ++++++++--------
 4 files changed, 19 insertions(+), 19 deletions(-)

One step closer to build with -Werror :)

On Wed, Oct 22, 2014 at 04:50:08PM +0200, Max wrote:

Hi,

>  	gh = msgb_l3(msg);
>  	if (msgb_l3len(msg) - sizeof(*gh) != 1) {
> -		LOGP(DMSC, LOGL_ERROR, "Assignment Compl invalid: %u\n",
> +		LOGP(DMSC, LOGL_ERROR, "Assignment Compl invalid: %lu\n",
>  		     msgb_l3len(msg) - sizeof(*gh));

it looks like a candidate for ping-pong games on 32bit/64bit userland
on GNU/Linux. What is the type here? unsigned int - size_t?

holger

Good catch, I didn't notice it. Maybe we should just use size_t for all the length
functions in libosmo*? That's what size_t was invented for after all :)

22.10.2014 23:32, Holger Hans Peter Freyther пишет:
> On Wed, Oct 22, 2014 at 04:50:08PM +0200, Max wrote:
> 
> Hi,
> 
>>  	gh = msgb_l3(msg);
>>  	if (msgb_l3len(msg) - sizeof(*gh) != 1) {
>> -		LOGP(DMSC, LOGL_ERROR, "Assignment Compl invalid: %u\n",
>> +		LOGP(DMSC, LOGL_ERROR, "Assignment Compl invalid: %lu\n",
>>  		     msgb_l3len(msg) - sizeof(*gh));
> 
> it looks like a candidate for ping-pong games on 32bit/64bit userland
> on GNU/Linux. What is the type here? unsigned int - size_t?
> 
> holger
>

On Thu, Oct 23, 2014 at 10:24:57AM +0200, ☎ wrote:

> Good catch, I didn't notice it. Maybe we should just use size_t for all the length
> functions in libosmo*? That's what size_t was invented for after all :)

> > it looks like a candidate for ping-pong games on 32bit/64bit userland
> > on GNU/Linux. What is the type here? unsigned int - size_t?

I can't quote the ISO C specification. So what type is the result of
"unsigned int - size_t"? We have size_t, off_t, ptrdiff_t as potential
types. I don't know which is the right one. :)

On Thursday 2014-10-23 14:39, Holger Hans Peter Freyther wrote:

>On Thu, Oct 23, 2014 at 10:24:57AM +0200, ☎ wrote:
>
>> Good catch, I didn't notice it. Maybe we should just use size_t for all the length
>> functions in libosmo*? That's what size_t was invented for after all :)
>
>> > it looks like a candidate for ping-pong games on 32bit/64bit userland
>> > on GNU/Linux. What is the type here? unsigned int - size_t?
>
>I can't quote the ISO C specification. So what type is the result of
>"unsigned int - size_t"?

size_t, because it is of higher rank.
(The specifier to use is %zu.)

Jan Engelhardt wrote:
> > So what type is the result of "unsigned int - size_t"?
> 
> size_t, because it is of higher rank.

How come it has higher rank?

I don't have the spec, maybe it is stated explicitly there, but this
blog post (it's on the internet so it MUST be true!) outlines rules
based on the standard, and doesn't mention either size_t type.

I have a feeling that size_t is not strictly defined, ie. that a
programmer or even a compiler is free to choose any representation,
as long as all memory addresses can be stored. In that case size_t
rank can't really be determined.

We could always cast... :)


//Peter

23.10.2014 17:59, Peter Stuge пишет:
> 
> We could always cast... :)
> 

That's an evil witchcraft! :)

On Thu, Oct 23, 2014 at 05:59:32PM +0200, Peter Stuge wrote:

> How come it has higher rank?
> 
> I don't have the spec, maybe it is stated explicitly there, but this
> blog post (it's on the internet so it MUST be true!) outlines rules
> based on the standard, and doesn't mention either size_t type.

#include <stdint.h>
#include <sys/socket.h>
#include <stdint.h>

int foo()
{
        unsigned int foo = 1212323123123;
        size_t bla = 2;

        typeof(foo - bla) k;
        k = 3;
}


clang-3.4 -Xclang -ast-dump -fsyntax-only foo.c

`-FunctionDecl 0x9946300 </tmp/foo.c:5:1, line:12:1> foo 'int ()'
  `-CompoundStmt 0x9946588 <line:6:1, line:12:1>
    |-DeclStmt 0x99463c8 <line:7:2, col:34>
    | `-VarDecl 0x9946370 <col:2, col:21> foo 'unsigned int'
    |   `-ImplicitCastExpr 0x99463b8 <col:21> 'unsigned int' <IntegralCast>
    |     `-IntegerLiteral 0x99463a0 <col:21> 'long long' 1212323123123
    |-DeclStmt 0x9946438 <line:8:2, col:16>
    | `-VarDecl 0x99463e0 <col:2, col:15> bla 'size_t':'unsigned int'
    |   `-ImplicitCastExpr 0x9946428 <col:15> 'size_t':'unsigned int' <IntegralCast>
    |     `-IntegerLiteral 0x9946410 <col:15> 'int' 2
    |-DeclStmt 0x9946520 <line:10:2, col:21>
    | `-VarDecl 0x99464f0 <col:2, col:20> k 'typeof (foo - bla)':'unsigned int'
    `-BinaryOperator 0x9946570 <line:11:2, col:6> 'typeof (foo - bla)':'unsigned int' '='
      |-DeclRefExpr 0x9946530 <col:2> 'typeof (foo - bla)':'unsigned int' lvalue Var 0x99464f0 'k' 'typeof (foo - bla)':'unsigned int'
      `-ImplicitCastExpr 0x9946560 <col:6> 'typeof (foo - bla)':'unsigned int' <IntegralCast>
        `-IntegerLiteral 0x9946548 <col:6> 'int' 3

If I read this correctly the type is 'unsigned int' with clang? An
issue with my reading? Clang bug?


cheers
	holger

On Saturday 2014-10-25 15:42, Holger Hans Peter Freyther wrote:
>int foo()
>{
>        unsigned int foo = 1212323123123;
>        size_t bla = 2;
>
>        typeof(foo - bla) k;
>        k = 3;
>}
>
>clang-3.4 -Xclang -ast-dump -fsyntax-only foo.c
>    | `-VarDecl 0x99464f0 <col:2, col:20> k 'typeof (foo - bla)':'unsigned int'
>
>If I read this correctly the type is 'unsigned int' with clang?

You seem to be compiling in LP32 mode.
I get unsigned long -- which is what size_t amounts to on Linux/LP64.

Peter Stuge wrote:
> Jan Engelhardt wrote:
> > > So what type is the result of "unsigned int - size_t"?
> > 
> > size_t, because it is of higher rank.
> 
> How come it has higher rank?

I'd appreciate an answer to this. "because" isn't it.


//Peter

On Sunday 2014-10-26 13:04, Peter Stuge wrote:
>> > > So what type is the result of "unsigned int - size_t"?
>> > size_t, because it is of higher rank.
>> How come it has higher rank?
>I'd appreciate an answer to this. "because" isn't it.

Then you will be disappointed, because "because it is" is the answer - 
the standards body defined it to be that way.
https://www.securecoding.cert.org/confluence/display/seccode/INT02-C.+Understand+integer+conversion+rules

Jan Engelhardt wrote:
> >> > > So what type is the result of "unsigned int - size_t"?
> >> > size_t, because it is of higher rank.
> >> How come it has higher rank?
> >I'd appreciate an answer to this. "because" isn't it.
> 
> "because it is" is the answer -
> the standards body defined it to be that way.

It's not clear to me that this is the case.

> https://www.securecoding.cert.org/confluence/display/seccode/INT02-C.+Understand+integer+conversion+rules

Right, this is the blog post I referenced in my previous email. I
forgot to include the link. Thanks for sending it.

This post makes a reference to the standard and seems to repeat the
rank rules, but it doesn't seem to me that any of the rules apply to
the case at hand?


//Peter