Discussion:
signal warnings fixed; now what's a translation unit?
(too old to reply)
Chuck Martin
2003-07-22 09:21:12 UTC
Permalink
Sorry for the delayed response. I've been very busy this past week.
"Translation unit" is the language legalese for what you normally think
of as a source file. So this is saying there is no real C code in
the source file. This can happen if the source file is only comments.
Another case is if you aren't compiling with the right preprocessor
337$ cat x.c
#if BAR
int foo() {
return 7;
}
#endif
338$ /usr/bin/cc -c -DBAR x.c
339$ /usr/bin/cc -c x.c
"x.c", line 6: warning: empty translation unit
Thanks. That explains it perfectly. The whole file is effectively
removed if CRYPT isn't defined. Now I just need to figure out how
to fix it in a way that doesn't seem like a kludge.

Chuck
Chuck Martin
2003-07-22 09:48:05 UTC
Permalink
I typically fix these by adding some harmless external reference to the
#if BAR
int foo() {
return 7;
}
#else
extern int main(); /* prevent "empty translation unit" warning */
#endif
Note that the external reference has _no_ effect on the compiler output,
since it isn't actually used. The resulting "empty" x.o does not
contain the string "main".
Thanks, Bela. I guess that's one way to do it, but it seems like a kludge.
I was trying to do it in the Makefile, but haven't had much luck. I tried
changing this:

crypt.o: crypt.c sc.h
$(CC) ${CFLAGS} ${CRYPT} ${DOBACKUPS} -c crypt.c

to this:

crypt.o: crypt.c sc.h
if [ ${CRYPT} ]; then \
$(CC) ${CFLAGS} ${CRYPT} ${DOBACKUPS} -c crypt.c; \
fi

But then it complains because crypt.o doesn't exist. The object files,
including crypt.o, are all listed in ${OBJS}. Is there a way to redefine
that variable based on whether ${CRYPT} is defined? I guess I need to
take time to learn make better. The obvious things I tried didn't seem
to work, but I guess that's because make isn't sh or bash, or any other
shell.

Chuck
Bela Lubkin
2003-07-22 17:35:39 UTC
Permalink
Post by Chuck Martin
I typically fix these by adding some harmless external reference to the
#if BAR
int foo() {
return 7;
}
#else
extern int main(); /* prevent "empty translation unit" warning */
#endif
Note that the external reference has _no_ effect on the compiler output,
since it isn't actually used. The resulting "empty" x.o does not
contain the string "main".
Thanks, Bela. I guess that's one way to do it, but it seems like a kludge.
I was trying to do it in the Makefile, but haven't had much luck. I tried
crypt.o: crypt.c sc.h
$(CC) ${CFLAGS} ${CRYPT} ${DOBACKUPS} -c crypt.c
crypt.o: crypt.c sc.h
if [ ${CRYPT} ]; then \
$(CC) ${CFLAGS} ${CRYPT} ${DOBACKUPS} -c crypt.c; \
fi
But then it complains because crypt.o doesn't exist. The object files,
including crypt.o, are all listed in ${OBJS}. Is there a way to redefine
that variable based on whether ${CRYPT} is defined? I guess I need to
take time to learn make better. The obvious things I tried didn't seem
to work, but I guess that's because make isn't sh or bash, or any other
shell.
The only way to get USL-derived compilers not to warn about this is to
feed them _something_ in the file. If you don't like `extern int
main();', how about an include? It doesn't even have to be ifdef'd. In
fact you can just move one of the includes that's inside the `#ifdef
CRYPT' above it. Or add an include of something innocuous like
unistd.h.
Post by Chuck Martin
Bela<
Chuck Martin
2003-07-22 18:59:45 UTC
Permalink
Post by Bela Lubkin
The only way to get USL-derived compilers not to warn about this is to
feed them _something_ in the file. If you don't like `extern int
main();', how about an include? It doesn't even have to be ifdef'd. In
fact you can just move one of the includes that's inside the `#ifdef
CRYPT' above it. Or add an include of something innocuous like
unistd.h.
Thanks. I at least have several ideas to consider now.

Chuck

Chuck Martin
2003-07-22 18:56:52 UTC
Permalink
Okay. Thanks for the input.

Chuck
Loading...