947735 - Build modules/libmar/ in unified mode

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Comment 1

[(no longer active)]

Attachment: Build modules/libmar/ in unified mode

Comment 2

[Brian R. Bondy [:bbondy]]

Comment on attachment 8344373 [details] [diff] [review]
Build modules/libmar/ in unified mode

Review of attachment 8344373 [details] [diff] [review]:
-----------------------------------------------------------------

r+ otherwise

::: modules/libmar/src/mar_read.c
@@ +551,3 @@
>                        int *hasAdditionalBlocks,
> +                      uint32_t *offsetAdditionalBlocks,
> +                      uint32_t *numAdditionalBlocks)

Why are these changes being made, is it in response to any warnings? If not I'd rather leave them out.

Comment 3

[(no longer active)]

(In reply to Brian R. Bondy [:bbondy] from comment #2)
> ::: modules/libmar/src/mar_read.c
> @@ +551,3 @@
> >                        int *hasAdditionalBlocks,
> > +                      uint32_t *offsetAdditionalBlocks,
> > +                      uint32_t *numAdditionalBlocks)
> 
> Why are these changes being made, is it in response to any warnings? If not
> I'd rather leave them out.

The compiler gets mad at us because this function actually doesn't match the signature of the function declared in the header: <http://mxr.mozilla.org/mozilla-central/source/modules/libmar/src/mar_cmdline.h#34>

The way that this currently "works" is that mar_read.c which is the fine that defines this function (mar_read.c) doesn't include mar_cmdline.h, so the compiler currently doesn't know about this incorrect code.  Unifying these files makes the compiler aware of this brokenness and it complains, rightly so.

Comment 4

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6ecda297fb37

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6ecda297fb37