lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.42.0209151834160.848-100000@nimue.bos.bindview.com>
From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: Re: C initialization of static objects (was:
 ALERT ALERT ALERT! google under attack ALERT ALERT ALERT!)

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.

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.

Ok, it's not ellegant, but this is exactly what makes C so popular and
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
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.

/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
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.

/Rant off.

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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ