Subject: Re: toolchain/22118: make won't compile with -Wcast-qual
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Greywolf <greywolf@starwolf.com>
List: tech-toolchain
Date: 07/18/2003 16:06:12
Thus spake der Mouse ("dM> ") sometime Today...

dM> This is very interesting.  Thank you.
dM>
dM> > /* start */
dM> > /* GCC */
dM> > char textbar[]="Text?"; /* BOTH: .data [RW] */
dM> > char textbar2[14] = "Is this text?";    /* BOTH: .data [RW] */
dM> > char *textptr="Textpointer?";   /* GCC: .rodata, Sun: .data1 [RW] */
dM> > int unalloc;    /* GCC: .text, Sun: .data */
dM>
dM> .text?  Not .bss?  Are you sure?

Yes.  There is no .bss segment produced, in fact; it might be considered
.common, I don't know, but in any case "unalloc" did not show up there.

Since 'unalloc' is outside the scope of a function, and lives in the global
section, quite honestly, I'm very surprised that SunPRO-C put it in .data!
Only in-function unallocated data goes in .bss, to my knowledge.

[unless, of course, I'm misinterpreting .bss again, which is not out
of the question.]

dM> >     char *textest = "is this in .text?";    /* G: .rodata, S: .data1 [RW] */
dM>
dM> > I find it interesting, the different treatment of char * by the two
dM> > compilers...
dM>
dM> I assume you are talking about where the text string itself goes, not
dM> where the pointer variable goes?

Yes, probably, but keep in mind that if you don't want the pointer
variable to change, you must use "char const *var"; i.e., you'd then
be applying the "const" to the pointer attribute, not the class attribute.
[sorry if the wording isn't quite right.]

dM> It also might be interesting to add a string literal as part of an
dM> expression, maybe something like
dM>
dM> 	printf("Where does this go?");
dM>
dM> I expect them to be treated the same as char * initializers
dM> (.rodata/.data1), but it'd be interesting to find out.

Let me check.

/* start */
main(argc,argv)
char *argv[];	/* I deplore empty main() */
{
	printf("Where is this?");
}
/* end */

GCC puts it in .rodata, SunPRO-C puts it in .data1(,#alloc,#write) [this
implies writability.]

I'm not sure I agree with Sun's treatment of it.  Writable initialised
arrays don't thrill me; pointers to initialized (writable) storage seem
to make more sense.

Let me try a third:

/* start */
testfunc()
{
    char *writeme = "where is this?";	/* S: .data1, G: .rodata */
    const char *can_i = "write this?";	/* BOTH: .rodata */
    char const *may_i = "or this?";	/* BOTH: .rodata */
}
/* end */

and a fourth:

/* start */
char *writeme = "writeme";
	/* Sun: writeme: .data [RW], *writeme: .data1 [RW] */
	/* GCC: writeme: .data [RW], *writeme: .rodata [RO] */
const char *can_i = "can I?";
	/* Sun: can_i: .data [RW], *can_i: .rodata1 [RO] */
	/* GCC: can_i: .data [RW], *can_i: .rodata [RO] */
char const *may_i = "may I?";
	/* Sun: may_i: .data [RW], *may_i: .rodata1 [RO] */
	/* GCC: may_i: .data [RW], *may_i: .rodata [RO] */
char * const doubt_it = "Nope.";
	/* Sun: doubt_it: .rodata [RO], *doubt_it: .data1 [RW] */
	/* GCC: doubt_it: .rodata [RO], *doubt_it: .rodata [RO] */
/* end */

I find it interesting that Sun will separate the constance of a pointer
from the constance of what it points to, while GCC lumps them together,
saying that if you can't modify the pointer, you also cannot modify
where it points, which, semantically, I disagree with.

I also find it interesting that "char const *" == "const char *";

				--*greywolf;
--
NetBSD: the free unix for the rest of us.