Conference smurf::buildhelp

Date Of Receipt: 	14-NOV-1996 17:27:13.97
From: 	QUARRY::neth "Craig Neth USG  14-Nov-1996 1723"
To: 	"Joshua M. Friedman, Digital UNIX, 381-1548" <jmf@DEC:.zko.quarry>
CC: 	[email protected], buildhelp@DEC:.zko.quarry,
	schloss@DEC:.zko.quarry
Subj: 	Re: bcreate header [for .c and .h files]

>Also, what is the difference between
>
>	#pragma ident "foo"
>
>and
>
>	#ident "foo"

Functionally, I do not belive there is any difference - both strings end
up in the .rdata (read only data) section.

I think #pragma ident is preferred as it is ANSI standard conforming - pragmas
are reserved for definition by implementations, and if a compiler does not
understand a pragma it is to ignore it.    I don't know the history on #ident
to know why the kernel seems to use it vs. #pragma ident.

Incidentally, the de group has a 'wishlist' item to improve the handling of
#pragma ident to have the ident strings put in the .comment section, so
that these strings won't consume memory at runtime.

As far as the header file stuff - I don't think you want to put #pragma
ident in header files - it would mean that you would get a string contributed
from every header file you included in every .o file.    I think we would
see a large increase in the datasize of our images if we did that.

I'm not sure I see how the verification of conflicting headers would work -
can you elaborate on that?

Craig

Date Of Receipt: 	14-NOV-1996 17:49:05.63
From: 	FLUME::schloss "Mike Schloss usg  14-Nov-1996 1745"
To: 	"Craig Neth DTN 381-2174" <neth@DEC:.zko.flume>
CC: 	jmf@DEC:.zko.flume, deeng@DEC:.zko.flume, buildhelp@DEC:.zko.flume
Subj: 	Re: bcreate header [for .c and .h files]

> As far as the header file stuff - I don't think you want to put #pragma
> ident in header files - it would mean that you would get a string contributed
> from every header file you included in every .o file.    I think we would
> see a large increase in the datasize of our images if we did that.

Each string is only about 80 bytes.  You would increase the size of each
binary by one 8K page for every 100 strings.  Do you really think that this
will make that big of a difference?

> I'm not sure I see how the verification of conflicting headers would work -
> can you elaborate on that?

Sure, file foo.c include files frobnitz.h.  Library routine frobnitz() is
in frobnitz.c which also includes frobnitz.h.  When you build executable
foo you get the latest version of frobnitz.h (say version 8.8).  But static
library frobnitz.a which has not been recompiled in quite a while used
version 4.4 of frobnitz.h.  Now you can do something like:

% what foo | grep frobnitz.h
	frobnitz.h	version 4.4
	frobnitz.h	version 8.8

Something similar could also be done for shared libraries.

Mike

Date Of Receipt: 	15-NOV-1996 12:50:02.22
From: 	QUARRY::neth "Craig Neth USG  15-Nov-1996 1246"
To: 	Mike Schloss usg <schloss@DEC:.zko.quarry>
CC: 	jmf@DEC:.zko.quarry, [email protected], buildhelp@DEC:.zko.quarry
Subj: 	Re: bcreate header [for .c and .h files]

>Each string is only about 80 bytes.  You would increase the size of each
>binary by one 8K page for every 100 strings.  Do you really think that this
>will make that big of a difference?

Not just the binary, but the datasize usage of each binary also.  That means
memory (It will be shared by all users of the system, but it will still be
one more page of data...)   

If the ident stuff went in the .comment section (which is never loaded into
memory) it might make sense, but I don't think we can afford it with the
current implementation.   

> Now you can do something like:
>
>% what foo | grep frobnitz.h

Sure.  I was thinking that you had some automatic method in mind - I was
having troubles imagining how that would work.

Craig