Get rid of a compile time dprintf warning

[Dave Frodin]

This patch gets rid of a compile time dprintf warning. 
A 'long int' was being passed to a '%d'.

Signed-off-by: Dave Frodin  
--- 
src/post.c | 2 +- 
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/post.c b/src/post.c 
index 924b311..b84d19e 100644 
--- a/src/post.c 
+++ b/src/post.c 
@@ -345,7 +345,7 @@ reloc_init(void) 
panic("No space for init relocation.\n");

// Copy code and update relocs (init absolute, init relative, and runtime) 
- dprintf(1, "Relocating low data from %p to %p (size %d)\n" 
+ dprintf(1, "Relocating low data from %p to %p (size %ld)\n" 
, datalow_start, final_datalow_start, datalow_end - datalow_start); 
updateRelocs(code32flat_start, _reloc_datalow_start, _reloc_datalow_end 
, final_datalow_start - datalow_start);

[Dave Frodin]

Here's a patch that's been lingering awhile. 
thanks, 
Dave

----- Original Message -----
> From: "Dave Frodin" 
> To: "seabios" 
> Sent: Wednesday, October 17, 2012 9:30:01 AM
> Subject: Get rid of a compile time dprintf warning
> This patch gets rid of a compile time dprintf warning.
> A 'long int' was being passed to a '%d'.
> Signed-off-by: Dave Frodin
>
> src/post.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> diff --git a/src/post.c b/src/post.c
> index 924b311..b84d19e 100644
> --- a/src/post.c
> +++ b/src/post.c
> @@ -345,7 +345,7 @@ reloc_init(void)
> panic("No space for init relocation.\n");
> // Copy code and update relocs (init absolute, init relative, and
> runtime)
> dprintf(1, "Relocating low data from %p to %p (size %d)\n"
> dprintf(1, "Relocating low data from %p to %p (size %ld)\n"
>
> , datalow_start, final_datalow_start, datalow_end - datalow_start);
> updateRelocs(code32flat_start, _reloc_datalow_start,
> _reloc_datalow_end
> , final_datalow_start - datalow_start);
> --
> 1.7.9

[Kevin O'Connor]

On Wed, Jan 09, 2013 at 08:34:18AM -0600, Dave Frodin wrote:
> Here's a patch that's been lingering awhile. 
> thanks,

Thanks.  I don't receive a warning for this - what is the exact
warning you receive?  I don't see why gcc would convert (datalow_end -
datalow_start) to a long.

-Kevin

[Dave Frodin]

Kevin,

Here are some of the lines from the output stream...

Compile checking out/esp-scsi.o
  Compile checking out/megasas.o
  Compile checking out/post.o
src/post.c: In function 'reloc_init':
src/post.c:350:5: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Wformat]
  Compile checking out/shadow.o
  Compile checking out/memmap.o
  Compile checking out/coreboot.o

I'm building this in cygwin, and using our (Sage's) toolchain.

thanks,
Dave

----- Original Message -----
> From: "Kevin O'Connor" 
> To: "Dave Frodin" 
> Cc: "seabios" 
> Sent: Wednesday, January 9, 2013 4:54:28 PM
> Subject: Re: [SeaBIOS] Get rid of a compile time dprintf warning
>
> On Wed, Jan 09, 2013 at 08:34:18AM -0600, Dave Frodin wrote:
> > Here's a patch that's been lingering awhile.
> > thanks,
>
> Thanks.  I don't receive a warning for this - what is the exact
> warning you receive?  I don't see why gcc would convert (datalow_end
>
> datalow_start) to a long.
>
> -Kevin

[Kevin O'Connor]

On Wed, Jan 09, 2013 at 06:03:24PM -0600, Dave Frodin wrote:
> Kevin,
>
> Here are some of the lines from the output stream...
>
> Compile checking out/esp-scsi.o
>   Compile checking out/megasas.o
>   Compile checking out/post.o
> src/post.c: In function 'reloc_init':
> src/post.c:350:5: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Wformat]
>   Compile checking out/shadow.o
>   Compile checking out/memmap.o
>   Compile checking out/coreboot.o
>
> I'm building this in cygwin, and using our (Sage's) toolchain.

What version of gcc is it?

If I change the format to %ld I get:

Compile checking out/post.o
src/post.c: In function ‘reloc_init’:
src/post.c:350:5: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘int’ [-Wformat]

Which is what I'd expect.  Maybe there is something odd with your
version of gcc?

$ gcc --version
gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)

and I get similar behavior with gcc v3.4.

-Kevin

[Dave Frodin]

Thanks for looking into this.

I'm using gcc version 4.6.3
> > I'm building this in cygwin, and using our (Sage's) toolchain.
>
> What version of gcc is it?
>
> If I change the format to %ld I get:
>
> Compile checking out/post.o
> src/post.c: In function ‘reloc_init’:
> src/post.c:350:5: warning: format ‘%ld’ expects argument of type
> ‘long int’, but argument 4 has type ‘int’ [-Wformat]
>
> Which is what I'd expect.  Maybe there is something odd with your
> version of gcc?
>
> $ gcc --version
> gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
>
> and I get similar behavior with gcc v3.4.
>
> -Kevin

[Laszlo Ersek]

On 01/10/13 00:54, Kevin O'Connor wrote:
> On Wed, Jan 09, 2013 at 08:34:18AM -0600, Dave Frodin wrote:
> > Here's a patch that's been lingering awhile. 
> > thanks,
>
> Thanks.  I don't receive a warning for this - what is the exact
> warning you receive?  I don't see why gcc would convert (datalow_end -
> datalow_start) to a long.

In the expression "datalow_end - datalow_start", both operands
- (have incomplete array type (size unknown), ISO C99 6.2.5p22),
- are converted ("decay") to type "pointer-to-u8" (ISO C99 6.3.2.1p3).

The expression "datalow_end - datalow_start" invokes undefined behavior,
because the (decayed) operands are not pointers into the same array (or
to the element one past the last element in the array).

Anyway, the result type of "datalow_end - datalow_start" would be
ptrdiff_t, whose size is implementation-defined.
> From ISO C99, 6.5.6 Additive operators (normative):

9 When two pointers are subtracted, both shall point to elements of
    the same array object, or one past the last element of the array
    object; the result is the difference of the subscripts of the two
    array elements. The size of the result is implementation-defined,
    and its type (a signed integer type) is ptrdiff_t defined in the
    <stddef.h> header. If the result is not representable in an object
    of that type, the behavior is undefined. In other words, if the
    expressions P and Q point to, respectively, the i-th and j-th
    elements of an array object, the expression (P)-(Q) has the value
    i-j provided the value fits in an object of type ptrdiff_t.
    Moreover, if the expression P points either to an element of an
    array object or one past the last element of an array object, and
    the expression Q points to the last element of the same array
    object, the expression ((Q)+1)-(P) has the same value as ((Q)-(P))+1
    and as -((P)-((Q)+1)), and has the value zero if the expression P
    points one past the last element of the array object, even though
    the expression (Q)+1 does not point to an element of the array
    object.88)

Footnote 88 (informative)

Another way to approach pointer arithmetic is first to convert the
    pointer(s) to character pointer(s): In this scheme the integer
    expression added to or subtracted from the converted pointer is
    first multiplied by the size of the object originally pointed to,
    and the resulting pointer is converted back to the original type.
    For pointer subtraction, the result of the difference between the
    character pointers is similarly divided by the size of the object
    originally pointed to.

When viewed in this way, an implementation need only provide one
    extra byte (which may overlap another object in the program) just
    after the end of the object in order to satisfy the "one past the
    last element" requirements.

I can see two ways to solve this "problem" (many are possible probably):

(1) print the difference (of type ptrdiff_t) with the "%td" printf()
conversion specification. It was first defined in SUSv3
http://pubs.opengroup.org/onlinepubs/000095399/functions/fprintf.html,
ie. not standard C. However this leaves the undefined behavior (the
subtraction) in place.

(2) Convert the operands first to pointer-to-void (safe), then to
uintptr_t ((a) an optional type that is required on XSI conformant
systems, (b) the conversion is safe from void*), then take their
difference, convert it to uintmax_t, and print it with "%"PRIuMAX:

dprintf(1, "Relocating low data from %p to %p (size %"PRIuMAX")\n"
            , (void *)datalow_start, (void *)final_datalow_start,
            , (uintmax_t)(  (uintptr_t)(void *)datalow_end
                          - (uintptr_t)(void *)datalow_start));

(I'm of course aware that you won't do this, bit I think it explains the
"problem" and you could simplify from here, perhaps exploiting
characteristics that are guaranteed for any platform that runs SeaBIOS.)

Laszlo