Subject: Re: toolchain/22118: make won't compile with -Wcast-qual
To: None <tech-toolchain@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-toolchain
Date: 07/18/2003 17:37:12
> Hm.  C is anything but an ideal language.  I'm sure a lot of folks
> out there might agree with that, but I fail to see precisely why.

I don't think I'd agree with that in that blanket a form.  C is very
nearly ideal for its original purpose - writing a small, new,
experimental OS.  It is drastically suboptimal for many other purposes;
the biggest problem I see with it for general use is that it's too
low-level.  Perhaps unfortunately, this is rather outweighed for many
uses by its near-universality.

> The points I've heard against it are by and large:
> 	- lack of object-orientation, and
> 	- the ease by which bad code is able to be written.

I agree with you about the latter point.  There's a famous quote that
goes something like "there is not nor will there ever be a language in
which it is the least bit difficult to write bad code".

As for the former...well, that's part of what I meant by its being too
low-level.  (There are tasks for which low-level is an advantage; for
the most part, C is well-suited to them.)

> I just don't see OO as a huge plus -- it usually generates much more
> bloated code on output.

Yes, but - when it's an appropriate tool - it does so while producing
significantly more maintainable source code with significantly less
coder time and effort.  If memory is tight, an OO language may be
inappropriate for that reason.  But there are plenty of cases where a
more maintainable program, turned out faster, that uses double the
memory, is a net win.

> Just for the record, I threw this together and compiled with Sun's
> (unbundled) cc as well as gcc, and here's what I discovered from the
> resulting .s files, near's I can tell:

This is very interesting.  Thank you.

> /* start */
> /* GCC */
> char textbar[]="Text?"; /* BOTH: .data [RW] */
> char textbar2[14] = "Is this text?";    /* BOTH: .data [RW] */
> char *textptr="Textpointer?";   /* GCC: .rodata, Sun: .data1 [RW] */
> int unalloc;    /* GCC: .text, Sun: .data */

.text?  Not .bss?  Are you sure?

>     char *textest = "is this in .text?";    /* G: .rodata, S: .data1 [RW] */

> I find it interesting, the different treatment of char * by the two
> compilers...

I assume you are talking about where the text string itself goes, not
where the pointer variable goes?

It also might be interesting to add a string literal as part of an
expression, maybe something like

	printf("Where does this go?");

I expect them to be treated the same as char * initializers
(.rodata/.data1), but it'd be interesting to find out.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B