#25 GCC 4.8 build errors (new warnings)

[Samuel Jero]

My debian unstable box just got updated with GCC 4.8 which introduces some new warnings (see http://gcc.gnu.org/gcc-4.8/porting_to.html) and causes ION to fail to build. In researching the issue I also found a debian bug for their packaged version of ION about this build failure (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701298).

The first build error results from a new pointer access check and exposes what is definitely a bug in ION (although it appears to be benign given what is being done here).
ici/sdr/sdrxn.c: In function 'createDbFile':
ici/sdr/sdrxn.c:943:28: error: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to provide an explicit length? [-Werror=sizeof-pointer-memaccess]
memset(buffer, 0 , sizeof buffer);

The fix is trivially simple. We want to use bufsize, set 7 lines above, instead of sizeof buffer.

Then we get two more complicated errors. These result from a new warning about unused local typedefs. Some of the BSP header files define typedef'ed structures that they never use:
In file included from ./bp/library/ext/bsp/extbspbab.h:11:0,
from ./bp/library/ext/bpextensions.c:18,
from bp/library/bei.c:45:
bp/library/bei.c: In function 'getExtensionDefs':
./bp/library/ext/bsp/extbsputil.h:237:3: error: typedef 'BundleParts' locally defined but not used [-Werror=unused-local-typedefs]
} BundleParts;
^
In file included from ./bp/library/ext/bpextensions.c:18:0,
from bp/library/bei.c:45:
./bp/library/ext/bsp/extbspbab.h:118:3: error: typedef 'BspBabCollaborationBlock' locally defined but not used [-Werror=unused-local-typedefs]
} BspBabCollaborationBlock;
^

In the case of "BundleParts", it doesn't appear to be used anywhere. "BspBabCollaborationBlock" is used in ./bp/library/ext/bsp/extbspbab.c.

My recommendation would be to remove "BundleParts" entirely (since nobody is using it) and move BspBabCollaborationBlock from the header file into the c file. However, I'm not familiar enough with BSP to know if that is reasonable or if we really want those typedefs in the headers. Thoughts?

[Scott Burleigh]

All three fixes look right to me, Samuel. BSP may need a fairly heavy overhaul anyway, when and if the proposed BSP spec simplifications are endorsed by DTNRG, but in the meantime I can't see any problem with removing the BundleParts type and moving the BspBabCollaborationBlock definition into extbspbab.c.

[Samuel Jero]

Okay. I've pushed these changes out. I'm also attaching a patch in case anybody else runs into this issue before the next release.

[Scott Burleigh]

These changes are merged into the 3.2.0 integration branch.