signal warnings fixed; now what's a translation unit?
Chuck Martin
functions by adding an int argument to all of the signal handlers. Now
I have one remaining warning I'd like to eliminate. It says:
"crypt.c", line 176: warning: empty translation unit
Could someone please tell me what a translation unit is so I know where
to begin looking for this. The crypt.c file only has 175 lines, so I
assume the problem is something similar to unmatched parentheses, brackets,
etc., but I have no idea what it is. Thanks again in advance.
Chuck
J. L. Schilling
> [...] I have one remaining warning I'd like to eliminate. It says:
>
> "crypt.c", line 176: warning: empty translation unit
>
> Could someone please tell me what a translation unit is so I know where
> to begin looking for this.
"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
macro values. Example:
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
Jonathan Schilling
Bela Lubkin
I typically fix these by adding some harmless external reference to the
file:
#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".
>Bela<
Chuck Martin
In article <ff3c0649.03071...@posting.google.com>,
J. L. Schilling <jlsels...@my-deja.com> wrote:
>"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
>macro values. Example:
>
>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
Bela Lubkin <be...@sco.com> wrote:
>I typically fix these by adding some harmless external reference to the
>file:
>
> #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
J. L. Schilling
Make is a declarative language with a few procedural features bolted
on in the gmake idiom. You can probably figure out some way to get
make to stand on its head to do what you want, but by then you've
got a nearly unreadable makefile. All for what -- to clear some
innocuous warning. You're better off living with the warning.
I know that some people won't sleep well until all their warnings
are cleared ... but unless you can convince somebody to modify
crypt.c, it's not worth the effort here. You can always stick an
"echo" in the makefile that says to expect a particular warning
on the next step. If you have a management mandate to clear all
warnings, then you're in a different boat.
Jonathan Schilling
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.
>Bela<
Chuck Martin
Chuck