Message-ID: <20020915165126.B7787@hamsec.aurora.sfo.interquest.net>
From: silvio at big.net.au (silvio@....net.au)
Subject: Re: C initialization of static objects (was: ALERT ALERT ALERT! google under attack ALERT ALERT ALERT!)

On Sun, Sep 15, 2002 at 07:04:20PM -0400, Michal Zalewski wrote:
> On Sun, 15 Sep 2002 silvio@....net.au wrote:
> 
> > Personally though, without even looking at the specs.. I much prefer all
> > initialization to be explicit :)
> 
> Why? Implicit initializations are shorter and more convenient. It can get
> hairy - from programmer's perspective - when NULL pointers and/or "zeros"
> for different arithmetic types are not the same, but it's not very common.
 
i prefer this -->

	if i see a declaration, and its initialized, then i assume the
	initialization is required immediately.

	if i see a declaration, without an initialization, then
	i assume it is not required and will be initialized at some
	later point through calculation or input.

that is how would prefer to think of initialization.. it does make
coding simpler, because the code is suggesting what is actually happening,
without having to sift through a million cases.

> Sure, it's a bit odd that explicit initializations are necessary for local
> variables, and not for global variables, but the reason is that the latter
> does not cause such a big performance impact in a typical design. Since
> implicit initializations simplify the code, I'd rather have them in as
> many places as possible than nowhere at all.
 
I totally disagree with this :)

implicit initialization does _not_ simplify code.  it makes it shorter
by a few characters.  That does not imply the code is more understandable
and therefore simpler.

if a binary is smaller than the source code, is the binary simpler?

> Ok, it's not ellegant, but this is exactly what makes C so popular and

bah.  C _is_ elegant in many respects..

> useful - extremely short (and often unreadable) notation; implicit
> conversions, initializations, sometimes typecasting; weak typing; no range
> control; etc, etc. C is so successful because it combines almost all

the language allows for many things.. but most of them should be anally
explicity programmed, to leave as little room for error IMHO.
almost every language can be abused, but strict programming and following
decent practices, you can definately avoid more problems than not by following
such guides.

the typing is definately an issue with C.. it does have weak typing, which
causes many many problems.  Range control isn't strictly necessary everywhere
of course.. on the upper layers you dont want to know what a range is,
but low level its required at some point (this is where C comes in!).

> paradigms of bad coding. This is not necessarily bad - it makes the
> language simple, fast and fairly powerful. If C was designed to avoid
> those problems, have neat syntax and rules and be very portable and
> abstract, it would become another Ada or one of few thousand less popular
> languages.
 
well C is elegant.. its portable..

abstract?  well. in todays standards, no.  but where it came from..
very abstract.

> /Rant on:
> 
> There are languages engineered to avoid confusion and guide the
> programmer, promote portable, intuitive and readable coding, or force a
> specific design approach; C isn't - fine. The only problem with C is that

for C

avoid confusion and guide programmer - not really (ok. no in general case)
promote portable - very much, but... (use a shell script!)
intuitive - different paradigms all say this.
readable - yes.. to an extent.  but not in comparison with other languages.
force a specific design approach - definately not with C :)

readability is interesting.. i think well written C is very readable.
but it can get into extremely hard to read cases when abused or such behaviour
is desired :(

big long names for random variables or functions etc, does not imply
readability as we all know :)

> it became a victim of its own popularity, becoming a language of
> necessity, not a language of choice, for way too many programmers who are
> not experienced enough to avoid trivial mistakes - or are simply too
> tired, well ;-) I don't think that SSH, Apache or Sendmail should be
> written in C, they do not benefit from any particular language
> capabilities, and suffer badly from C's shortcomings, but there's not much
> choice (perl doesn't count) when you want the code to compile everywhere,
> with a number of #ifdefs and API interoperability bugs, of course.
 
yah.. problem is.. C is unfortunately damn good at what it _can_ do :)
just not used well in many cases :(

> /Rant off.
> 
> -- 
> Michal Zalewski
> http://lcamtuf.coredump.cx/evilfinder/ef.shtml
> 
>

--
Silvio 

Powered by blists - more mailing lists