Re: Bug#685625: implicit declaration of function ‘reallocf’
Hi,
To further confuse things, here's a related problem in freebsd-buildutils:
> gcc -O2 -g -Wall -D_GNU_SOURCE -DMACHINE_ARCH='"i386"' -DMACHINE_MULTIARCH='"i386-kfreebsd-gnu"' -I/build/buildd-freebsd-buildutils_9.0-11-kfreebsd-i386-fRMINn/freebsd-buildutils-9.0/build-tree/src/sys -D_GNU_SOURCE=1 -isystem /usr/include/freebsd -std=gnu99 -fstack-protector -c excludes.c
> excludes.c: In function 'read_excludes_file':
> excludes.c:75:2: warning: implicit declaration of function 'fgetln' [-Wimplicit-function-declaration]
> excludes.c:75:15: warning: assignment makes pointer from integer without a cast [enabled by default]
> gcc -O2 -g -Wall -D_GNU_SOURCE -DMACHINE_ARCH='"i386"' -DMACHINE_MULTIARCH='"i386-kfreebsd-gnu"' -I/build/buildd-freebsd-buildutils_9.0-11-kfreebsd-i386-fRMINn/freebsd-buildutils-9.0/build-tree/src/sys -D_GNU_SOURCE=1 -isystem /usr/include/freebsd -std=gnu99 -fstack-protector -c misc.c
> gcc -O2 -g -Wall -D_GNU_SOURCE -DMACHINE_ARCH='"i386"' -DMACHINE_MULTIARCH='"i386-kfreebsd-gnu"' -I/build/buildd-freebsd-buildutils_9.0-11-kfreebsd-i386-fRMINn/freebsd-buildutils-9.0/build-tree/src/sys -D_GNU_SOURCE=1 -isystem /usr/include/freebsd -std=gnu99 -fstack-protector -c mtree.c
> gcc -O2 -g -Wall -D_GNU_SOURCE -DMACHINE_ARCH='"i386"' -DMACHINE_MULTIARCH='"i386-kfreebsd-gnu"' -I/build/buildd-freebsd-buildutils_9.0-11-kfreebsd-i386-fRMINn/freebsd-buildutils-9.0/build-tree/src/sys -D_GNU_SOURCE=1 -isystem /usr/include/freebsd -std=gnu99 -fstack-protector -c spec.c
> spec.c: In function 'set':
> spec.c:229:4: warning: implicit declaration of function 'setmode' [-Wimplicit-function-declaration]
> spec.c:229:11: warning: assignment makes pointer from integer without a cast [enabled by default]
> spec.c:232:4: warning: implicit declaration of function 'getmode' [-Wimplicit-function-declaration]
fgetln, setmode and getmode are defined in bsd/stdio.h and bsd/unistd.h.
Using fgetln without its prototype truncates the pointer to 32 bits.
Fortunately a mode_t is only 16 bits long so getmode/setmode may be okay.
I think the preferred method is to use libbsd's 'overlay' in code that
needs these functions. Previously freebsd-buildutils couldn't use the
overlay, so 20_libbsd_overlay.diff worked around it with extra includes:
http://anonscm.debian.org/viewvc/glibc-bsd/trunk/freebsd-buildutils/debian/patches/20_libbsd_overlay.diff?view=markup
Then for some unexplained reason that workaround got disabled; the
overlay was never re-enabled though:
http://anonscm.debian.org/viewvc/glibc-bsd/trunk/freebsd-buildutils/debian/patches/series?r1=3805&r2=3960
[added Guillem Jover in Cc: in the hope he can explain any of this :) ]
Another occurrence is in freebsd-libs:
> cc -Wall -g -pipe -fPIC -I. -I/build/buildd-freebsd-libs_9.0+ds1-3-kfreebsd-i386-0LY6QJ/freebsd-libs-9.0+ds1/sys -D_GNU_SOURCE -D__va_list=__builtin_va_list -O2 -isystem /usr/include/freebsd -I/build/buildd-freebsd-libs_9.0+ds1-3-kfreebsd-i386-0LY6QJ/freebsd-libs-9.0+ds1/debian/local/include -I/build/buildd-freebsd-libs_9.0+ds1-3-kfreebsd-i386-0LY6QJ/freebsd-libs-9.0+ds1/lib/libgeom -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c geom_ctl.c
> In file included from geom_ctl.c:38:0:
> /usr/include/freebsd/unistd.h: In function 'feature_present':
> /usr/include/freebsd/unistd.h:138:2: warning: implicit declaration of function 'strcmp' [-Wimplicit-function-declaration]
> geom_ctl.c: At top level:
> geom_ctl.c:55:1: warning: no previous prototype for 'gctl_dump' [-Wmissing-prototypes]
> geom_ctl.c: In function 'gctl_new_arg':
> geom_ctl.c:142:2: warning: implicit declaration of function 'reallocf' [-Wimplicit-function-declaration]
> geom_ctl.c:142:11: warning: assignment makes pointer from integer without a cast [enabled by default]
And many more places in freebsd-utils according to:
https://buildd.debian.org/~brlink/packages/f/freebsd-utils.html
Regards,
--
Steven Chamberlain
steven@pyro.eu.org
Reply to: