Re: C versus other languages, round 538 or so (Re: CGI scriptsinsh)

["Bluefish (P.Magnusson)" <11a () GMX NET>]

> This is more of a developer question, I was taught that I should always use
> '\0' as a terminator for my strings.  What is the reason for this?  Is
> it just

Reason 1: Ease of reading code (\0 means ASCII-Z termination, NULL means
          null pointer. It is not logical to use NULL. Less logical code,
          more programming misstakes)

Reason 2: Portability. As \0 is the prefered way, it will always work.
          Perhaps there exist some bastard-c where NULL != \0, then it
          won't work

Basicly both NULL and \0 is on 99.99% of all systems a binary zero. But it
is IMHO quite silly to use NULL.

I'd say that anyone out there who actually thinks [s]he is able to code
hard to read code is quite stupid; even if you are it rarely has any mayor
benefits and the pitfalls are many. Using NULL instead of \0 is quite an
example of this, why use constants at all if you the wrong constant? Using
0 rawly would even be wiser!

Looking at James' comments in the fixup;
// (sizeof(variable)-1) instead of sizeof(variable) - NULL, \0, 0

It's beyond me what he's actually wants to spell out.
  sizeof(variable) - NULL         == sizeof(variable) - 0
  sizeof(variable) - sizeof(NULL) == sizeof(variable) - 4 (if NULL 32bit)

With the risk of James feeling a bit flamed, I consider arguments and
code shown as quite demonstrative of a C programmer who trusts his skills
too much; the coding was either extremly careless or he hasn't fully
grasped some of the subject he thinks he does.

> From what I gathered, he thinks dong everything first in pseduo code would
be a solution to implementation faults. It isn't.

 * Many in the list probably have experience of implementing pseudo code.
   Going from pseduo to real code includes choises such as "will I do B as
   a pointer tree, or as an array tree?". Pseudo isn't strict enough, not
   even close to it.

 * Time; it takes a lot of time to write pseudo-code. You risk prolong the
   development quite a long time. And you aren't even sure that you gain
   anything from it.

 * Design revisions may cause several pieces of pseudocode to need
   revisions.

My approach to avoid as many implementation faults as possible would
involve:

  * good design (because then speedy changes of code wouldn't be
    reqired because of design changes). Easy to say, hard to do.

  * using simple code; if it's hard to understand, it's probably also hard
    to write correctly

  * Not allow or at least avoid as much as possible known dangerous
    functions.

  * QA tests, buddy checks etc. (Give QA people extra money if they find
    many bugs or dangerous bugs!)

..:::::::::::::::::::::::::::::::::::::::::::::::::..
     http://www.11a.nu || http://bluefish.11a.nu
    eleventh alliance development & security team

             http://www.eff.org/cafe