Vulnerability Development mailing list archives
Re: C versus other languages, round 538 or so (Re: CGI scriptsinsh)
From: "Bluefish (P.Magnusson)" <11a () GMX NET>
Date: Mon, 2 Oct 2000 02:03:25 +0200
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
Current thread:
- Re: C versus other languages, round 538 or so (Re: CGI scriptsinsh) Bluefish (P.Magnusson) (Oct 02)
- Re: C versus other languages, round 538 or so (Re: CGI scriptsinsh) Dag-Erling Smorgrav (Oct 02)
- Re: C versus other languages, round 538 or so (Re: CGI scriptsinsh) Peter Pentchev (Oct 02)
- <Possible follow-ups>
- Re: C versus other languages, round 538 or so (Re: CGI scriptsinsh) Aigars Grins (Oct 10)