Draft Secure C

[Jack]

http://www.open-std.org/jtc1/sc22/wg14/
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1135.pdf

Has anyone gone through this?
Is this useful? Will it make it to the next standard?

 

[Robert Gamble]

http://www.open-std.org/jtc1/sc22/wg14/
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1135.pdf

Has anyone gone through this?
Yes.

Is this useful?

Not in my opinion, but others differ.

Will it make it to the next standard?

Let's hope not.

Robert Gamble

 

[Richard Heathfield]

Robert Gamble said:

Not in my opinion, but others differ.


Let's hope not.

Well, let's at least hope that we don't start designing a new Standard until
C99 has been widely implemented. What would be the *point*?

 

[Robert Gamble]

Robert Gamble said:


Well, let's at least hope that we don't start designing a new Standard until
C99 has been widely implemented. What would be the *point*?

I think that a new Standard with carefully thought-out features which
reflect what the community values most may actually serve to increase
adoption of the rest of the C99 features faster than not. If a new
version provided functionality that the majority of the community could
get excited about and rally behind there is little doubt that
implementors would move at a much faster pace to implement it. Such a
venture would need to be extremely careful not to get bogged down with
the kinds of drastic changes, "special interests", and (what some
consider) unnecessary bloat that C99 brought along with it lest it
further jeopardize the relevance of the Standard, but success may be
the only thing that redeems it. TR 24731 qualifies for at least
"special interest" and bloat.

Robert Gamble

 

[CBFalconer]

http://www.open-std.org/jtc1/sc22/wg14/
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1135.pdf

Has anyone gone through this?
Is this useful? Will it make it to the next standard?

It originated at Microsoft. Nuff said.

 

[jacob navia]

Jack a écrit :

http://www.open-std.org/jtc1/sc22/wg14/
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1135.pdf

Has anyone gone through this?
Is this useful? Will it make it to the next standard?

The lcc-win32 compiler system implements more than
50% of that proposal. Only the wide character stuff
remains to be implemented.

Even it is not a solution to the bugs in the language,
it is a big step forward. I have discussed several
of the questions concerned in that proposal and in other
related ones in this group (where it was received by
the usual remarks of the "regulars" group) and in comp.std.c

Specifically the proposal is weak concerning the solution
for the zero terminated strings problems. It gives some extra
security without eliminating the problem at the root.

The problem is a bad data structure, and that is the
error that should be corrected.

jacob

 

[websnarf]

I think that a new Standard with carefully thought-out features which
reflect what the community values most may actually serve to increase
adoption of the rest of the C99 features faster than not. If a new
version provided functionality that the majority of the community could
get excited about and rally behind there is little doubt that
implementors would move at a much faster pace to implement it.

Absolutely correct. The Standard Committee may, or may not realize
this, but one thing is for sure, they do *NOT* realize that they
themselves are the reason this has not happened.

[...] Such a
venture would need to be extremely careful not to get bogged down with
the kinds of drastic changes, "special interests", and (what some
consider) unnecessary bloat that C99 brought along with it lest it
further jeopardize the relevance of the Standard, but success may be
the only thing that redeems it.

The C standard committee does not see the value of the language they
have ownership over, they don't see problems in the industry, and are
completely blind to the problems of the C language. There is a long
list of highly desirable features that the C language is crying out for
(no, not operator overloading -- I mean actual *functionality*) that
nobody is even thinking about.

[...] TR 24731 qualifies for at least "special interest" and bloat.

Huh? TR 24731 qualifies as *PLACEBO*. It does *NOT* accomplish what
it claims to set out to do. Because of the RSIZE_MAX fiasco, the
standard just continues to create portability problems. The thing is
just utter nonsense is what it is. The Robert Seacord proposal is a
little better (claimed to be targetted towards something different) but
*WAY* too slow. (It was sugggested by someone that I propose Bstrlib
to the C standard, however, manditory availability of the source is
considered one of its features.)

The *intended* scope of TR 24731 is not what I would call special
interest. Certainly any text processing programs should be using some
kind of alternate string functionality versus the CLIB's C strings.
Its just that TR 24731 is hardly any better.

 

[jacob navia]

(e-mail address removed) a écrit :

The C standard committee does not see the value of the language they
have ownership over, they don't see problems in the industry, and are
completely blind to the problems of the C language. There is a long
list of highly desirable features that the C language is crying out for
(no, not operator overloading -- I mean actual *functionality*) that
nobody is even thinking about.

Can you specify?

 

[Keith Thompson]

Specifically the proposal is weak concerning the solution
for the zero terminated strings problems. It gives some extra
security without eliminating the problem at the root.

The problem is a bad data structure, and that is the
error that should be corrected.

Zero-terminated strings are not themselves a problem. They have both
advantages and disadvantages. And it's not possible to eliminate them
entirely from the C language, at least not without breaking existing
code. (Requiring *any* source-level modification to make a program
work under a new standard constitutes "breaking" existing code.)

 

[jacob navia]

Keith Thompson a écrit :

Zero-terminated strings are not themselves a problem. They have both
advantages and disadvantages. And it's not possible to eliminate them
entirely from the C language, at least not without breaking existing
code. (Requiring *any* source-level modification to make a program
work under a new standard constitutes "breaking" existing code.)

Nobody wants to eliminate them in one
sweep. But an alternative could exist, that makes
their usage obsolete. Then, after 10-20 years
they are phased out.

That's all

 

[Keith Thompson]

Keith Thompson a écrit :
Nobody wants to eliminate them in one
sweep. But an alternative could exist, that makes
their usage obsolete. Then, after 10-20 years
they are phased out.

That's all

And we lose any *advantages* that zero-terminated strings might have
over counted strings.

 

[websnarf]

(e-mail address removed) a écrit :

Can you specify?

1) A better mapping to functionality commonly available in hardware.
I.e., high-word or widening multiply. Bit scan operations (i.e., fast
lg2, and scan for lowest.). Bit count. Endian swap. etc. Just look
through the instruction sets of the popular CPUs and see which useful
instructions are practically accessible through translation of C source
and what is not. Then add library functions that perform those and
allow the compiler vendor to support them however they wish. In this
way the most optimal paths for a given piece of hardware will be
available without resorting to non-portable inline assembly code. (And
for those platforms that do not support each function, each function
can be still be emulated which is equivalent to how such functionality
is portably delivered today.)

Just look through GMP or any similar multi-precision library. Yes it
has a portable pure C back-end, but it is utter nonsense and is only
invoked on compilers people have never heard of. But on those
compilers it is *AT LEAST* 4 times slower than the likely potential for
that hardware precisely because the language has no access to the
fastest, most functional instructions that are commonly available on
most hardware.

2) Better control flow functionality: Coroutines and alloca(). The
variable length array nonsense in C99 probably seemed like a good
cleaner substitute for alloca() at the time, but gcc has clearly shown
that its actually *harded* to implement that portably in at least their
compiler.

The whole setjmp, longjmp nonsense is precisely that. Personally I
have never gotten it to work correctly, and I have a hard time
approaching debugging of it -- I have always just found a way around
using them instead. However, it turns out that coroutines are fairly
straight forward to implement in assembly. And they incurr very little
overhead. It requires some method of allocating a new "call stack".
Although this sounds grossly exposing of platform details, if it is
abstracted correctly, it actually is a big benefit. Currently a
program itself within its source code cannot assert a requirement for
minimum of stack availability. So programs that use deep recursion can
crash easily. Besides that, coroutines represent truly new
functionality in the language that is just absolutely not duplicatable
by other means that can be considered scalable.

3) Better heap functionality. The only access we have to the heap is
through malloc/realloc/calloc/free. Its just not enough at all. The
thing is, even the best implementations of those functions put a best
amortized cost of a scalable implementation at around 50+ clocks per
allocation. That means memory allocation is something that you
necessarily try to push out of your inner loops. That means that
throwing in more functionality and more overhead into those calls will
not affect real world performance of applications that care about
performance, since such call will not be sitting in inner loops at all.

Now you can see from here in CLC itself, that there is a great need for
heaps with built-in debugging help. Simple functions that tell you the
total amount of allocated heap, or the size of a given allocation. C
is not a language that can implement garbage collection easily, but it
is very often the case that you can implement very close stand-ins that
achieve the same level of leak safety. In particular you can implement
seperate heaps, and include a "freeall()" function that will tear down
an entire heap at once rather than performing individual frees -- which
is often a lot of meaningless expense.

Another useful thing to have is an isFromAllocatedMemory() function.
The idea would be that the function would be well defined for certain
void * pointers that were from static memory, auto-memory, a pointer
allocated from heap memory and NULL. In this way you could determine
whether or not a pointer came from the heap. In practice, this would
be used primarily for debugging, but it could be used for functions
that perform "automatic freeing" of structures passed to it when they
are done with it, but *NOT* perform a free() if the structure passed to
it came from static memory.

4) A better preprocessor. Basically you want to be able to directly
compete with LISP's lambda functionality, and just make automatic code
generation more plausible in C. To be fully general, I would recommend
modelling it after the language LUA (since its such a small language,
but fully general) in terms of functionality. This kind of thing would
greatly assist things like generic programming, but also provide ways
for programmers to perform certain optimization techniques like
"constant propogation" with relative ease.

5) A universal 64bit time standard. Dave Tribble has posted his idea
and library that explains what he after. The point is to create a
universal time standard that is guaranteed to not barf in 2038 and that
lets you correctly calculate time differences in a universal way,
without being tied to the current local time (without daylight savings
messing you up). I have not looked too deeply, but obviously such a
standard would need also to include accurrate "sub-second" real-time
timer functionality which is currently not available (clock() delivers
processor tick time on UNIX systems, which is a different kind of
animal.)

The real point behind this list of features, is that they represent
true enhancements to the C language. They are enhancements that really
put the question to other languages like Java, Python, etc. Combined,
this set of features would enhance the performance, and rewiden the gap
between C and Java (or C#) for example, in ways that those two
languages could not easily catch up. These features would push the
frontiers of C precisely where other languages do not dare tread, or
else already have another approach they are locked into.

Today I can simply say to you, that if I want to use coroutines, I
cannot use the C language and am better off going to another language.
If I want multiprecision mathematics, I know that Python will deliver
it to me, and that I cannot really get a good C implementation unless
it is GMP (which is not thread-safe, BTW) or non-portable hand coded
assembly language. If I want better heap control, then I roll my own
non-portable solution, and go ahead and violate ANSI-strictness by
overriding malloc/free/realloc/calloc. On occasion I do write
auto-code generators -- but these days, I do it in Python, not the C
pre-processor or even C. And of course, I still do the occasional
in-line assembly code where I just don't otherwise have access to
certain instructions.

Strings, I don't care as much about, of course, because I have written
a portable library that anyone can use that completely solves the
problems using todays C compilers. So enhancements to C's string
functions at the standards level is actually completely useless to me.
It just goes to show how misguided that ANSI C committee is that they
are entertaining nonsense like TR 24731, which is both bad (or at best
benign), and not really necessary at the standards level.

 

[websnarf]

Keith Thompson a écrit :

[...]
Specifically the proposal is weak concerning the solution
for the zero terminated strings problems. It gives some extra
security without eliminating the problem at the root.

The problem is a bad data structure, and that is the
error that should be corrected.
Zero-terminated strings are not themselves a problem. They have both
advantages and disadvantages. And it's not possible to eliminate them
entirely from the C language, at least not without breaking existing
code. (Requiring *any* source-level modification to make a program
work under a new standard constitutes "breaking" existing code.)

Nobody wants to eliminate them in one
sweep. But an alternative could exist, that makes
their usage obsolete. Then, after 10-20 years
they are phased out.

That's all

And we lose any *advantages* that zero-terminated strings might have
over counted strings.

You can, of course, come up with a single example of such an
"advantage" (that applies to the 10-20 year time frame Jacob was
talking about)?

 

[Walter Roberson]

1) A better mapping to functionality commonly available in hardware.
I=2Ee., high-word or widening multiply. Bit scan operations (i.e., fast
lg2, and scan for lowest.). Bit count. Endian swap. etc.

2) Better control flow functionality: Coroutines and alloca(). The

3) Better heap functionality.

The real point behind this list of features, is that they represent
true enhancements to the C language.

In 25 years of C programming, I have rarely needed any of the
functionality you list. Memory leak analysis sometimes, but only
one of the several extensions to heap functionality you propose would
make any difference to me (and that only on the odd occasion.)

Endian swap I have only needed to the extent provided by Unix's
ntohl() and htonl() -- i.e., in the context of network programming
in which such routines would definitely be available as part of the
network stack; the implementation details have been irrelevant to me.
I have needed to convert file format byte orders, but such conversions
are inherently non-portable and do not necessarily represent
conversions from any actual hardware; the ability to nail down the
order of bitfields would sometimes be a convenience, but taking the
appropriate adjustments at runtime has never ever been a factor that
affected execution time measurably.


In short, it appears to me that your view of what "the C language is
crying out for" is very heavily coloured by the -kind- of work that
you do. There was *nothing* in your list that had me nodding and
saying, "Me too!". Hence I have strong doubts that the C language is
actually "crying out for" those features, and I have a definite
suspicion that implementing the features you suggest would push
C even more towards the "portable assembler" status -- at a time in
computing when assembler has, to -most- people, become nearly irrelevant.

Now, maybe what the embedded programming industry needs is a really
first rate "portable assembler" so that developers can write code
usable on anything from GPUs to cell phones to toasters to "hyperthreaded"
PCs.... but as best I understand, programming history is littered with
the carcasses of programming languages that attempted to be
provide portable high-level interfaces to hardware. And I can't say
I've ever seen -any- demand for ADA outside of the US DoD...

There is a growing gap between "implementors" (responsible for the
nitty gritty of providing funcitonality on particular hardware),
and "programmers" (who don't necessarily care what happens under the
hood). The programmers are in the growing majority; catering to
implementors is going to have about the same long-term effect as
catering to DBase 3 programmers: useful to some, yes, but C would
pretty much drop out of general consciousness as a general purpose
language.

 

[santosh]

In 25 years of C programming, I have rarely needed any of the
functionality you list. Memory leak analysis sometimes, but only
one of the several extensions to heap functionality you propose would
make any difference to me (and that only on the odd occasion.)

Endian swap I have only needed to the extent provided by Unix's
ntohl() and htonl() -- i.e., in the context of network programming
in which such routines would definitely be available as part of the
network stack; the implementation details have been irrelevant to me.
I have needed to convert file format byte orders, but such conversions
are inherently non-portable and do not necessarily represent
conversions from any actual hardware; the ability to nail down the
order of bitfields would sometimes be a convenience, but taking the
appropriate adjustments at runtime has never ever been a factor that
affected execution time measurably.


In short, it appears to me that your view of what "the C language is
crying out for" is very heavily coloured by the -kind- of work that
you do. There was *nothing* in your list that had me nodding and
saying, "Me too!". Hence I have strong doubts that the C language is
actually "crying out for" those features, and I have a definite
suspicion that implementing the features you suggest would push
C even more towards the "portable assembler" status -- at a time in
computing when assembler has, to -most- people, become nearly irrelevant.

Isn't it precisely because of C's rise that assembler was severely
sidelined? Wouldn't adding more functionality to C take it away from
assembler rather than towards it?

Now, maybe what the embedded programming industry needs is a really
first rate "portable assembler" so that developers can write code
usable on anything from GPUs to cell phones to toasters to "hyperthreaded"
PCs.... but as best I understand, programming history is littered with
the carcasses of programming languages that attempted to be
provide portable high-level interfaces to hardware. And I can't say
I've ever seen -any- demand for ADA outside of the US DoD...

By the time Ada matured C/C++ had developed enough momentum to ensure
that the former would not be widely considered. As I see it, Java was
the first language to break the stranglehold of C and it's brother.

There is a growing gap between "implementors" (responsible for the
nitty gritty of providing funcitonality on particular hardware),
and "programmers" (who don't necessarily care what happens under the
hood). The programmers are in the growing majority; catering to
implementors is going to have about the same long-term effect as
catering to DBase 3 programmers: useful to some, yes, but C would
pretty much drop out of general consciousness as a general purpose
language.

IMHO, C has already nearly lost out on the applications development
front, particularly on PCs. It seems that it's major use now and in the
future would be in the implementation space. So additions to the
language that make it more relevant for that area might not be so bad
an idea.

 

[websnarf]

In 25 years of C programming, I have rarely needed any of the
functionality you list.

I noticed how you didn't say never. So when you *have* needed some of
that functionality, what did you do about it? I would like to point
out that most of the entire C library is completely useless to me as
well. So I don't know what the point of this comment is.

[...] Memory leak analysis sometimes, but only
one of the several extensions to heap functionality you propose would
make any difference to me (and that only on the odd occasion.)

So your argument then, is that you don't think there should be memory
leak assistance, because the other proposals I made are not something
you would be interested in?

Endian swap I have only needed to the extent provided by Unix's
ntohl() and htonl() -- i.e., in the context of network programming
in which such routines would definitely be available as part of the
network stack; the implementation details have been irrelevant to me.

Okay ... So here is another one that you would use, but only if they
were tied to Unix and named "nothl" and "htonl"? Are you saying these
are only possibly useful to Unix and therefore must not be available to
other platforms in a portable way?

I have needed to convert file format byte orders, but such conversions
are inherently non-portable and do not necessarily represent
conversions from any actual hardware; the ability to nail down the
order of bitfields would sometimes be a convenience, but taking the
appropriate adjustments at runtime has never ever been a factor that
affected execution time measurably.

In short, it appears to me that your view of what "the C language is
crying out for" is very heavily coloured by the -kind- of work that
you do.

Ok, but your idea that these are unimportant to you (even though,
apparently some are) is clearly coloring your response here. So I
don't see the value of your argument. BTW, what do you know about the
kind of work that I do?

My ideas come from looking at other programming languages, and from
looking at real world applications:

Coroutines come from the fact that Lua has them, Python has something
similar but less general (generators) and they are very useful for
web-browsers (yeilding on socket blocks to allow a single tasking
application to efficiently download a web page) and chess engines (just
the way the jumble of loops for move generation intertwines with the
alpha-beta algorithm can be drastically simplified with coroutines).

Alloca(), and better heap management is actually a reaction to garbage
collection. Garbage collection makes memory management in other
languages a complete non-issue. Now, C cannot easily implement GC, and
I don't recommend this. However, C has to justify its strategy as an
alternative. All the mechanisms I recommend would enhance the
functionality of C in ways that make its weaknesses versus GC less
obvious (with leak detection assistance, GC's leak-lessness is less of
an advantage, of course; with isFromHeap(), double-free becomes less of
a problem.) C's memory management strategy is better for realtime and
precise memory handling. Since it can't be exactly the same as GC, is
has to be something else -- it might as well be the very best possible
instance of its alternative strategy.

The better preprocessor clearly is aimed at Lisp's Lambda and just
generally more powerful macro programming. However, its purpose is
also as a good stand-in for generics/templates. It can be used to
automatically unroll a massive number of loops with a single source
rendering.

[...] There was *nothing* in your list that had me nodding and
saying, "Me too!". Hence I have strong doubts that the C language is
actually "crying out for" those features, and I have a definite
suspicion that implementing the features you suggest would push
C even more towards the "portable assembler" status -- at a time in
computing when assembler has, to -most- people, become nearly irrelevant.

Ok, so do you think the need for large number arithmetic has become
irrelevant? The use of crypto is going *up* not down. I don't even
know what this means. People have run away from assembly because
people want to engange in sustainable programming and Moore's Law has
enabled them to ignore performance for many applications (please note
that crypto is not one of these applications -- you just do inline
assembly or you can forget it). However, enabling such functionality
in C, brings back the performance benefit to a language that, in
theory, is at least partially scalable -- if not, then C++, which is
more seriously scalable, can at least inherit the features.

Now, maybe what the embedded programming industry needs is a really
first rate "portable assembler" so that developers can write code
usable on anything from GPUs to cell phones to toasters to "hyperthreaded"
PCs.... but as best I understand, programming history is littered with
the carcasses of programming languages that attempted to be
provide portable high-level interfaces to hardware. And I can't say
I've ever seen -any- demand for ADA outside of the US DoD...

What in the holy hell are you talking about? Ada is just a more
functional variant of Pascal. How is Ada a portable assermbler? The
features I suggest would also not be of any help to a GPUs or DSPs.

There is a growing gap between "implementors" (responsible for the
nitty gritty of providing funcitonality on particular hardware),
and "programmers" (who don't necessarily care what happens under the
hood). The programmers are in the growing majority; catering to
implementors is going to have about the same long-term effect as
catering to DBase 3 programmers: useful to some, yes, but C would
pretty much drop out of general consciousness as a general purpose
language.

You are saying that adding enhancements to C are not a good idea,
because adding them to C++ would be better?!?! Hint: If you add them
to C, C++ *will* pick them up. Sorry, but I find your entire response
completely vacuous.

 

[jacob navia]

Walter Roberson a écrit :

In 25 years of C programming, I have rarely needed any of the
functionality you list. Memory leak analysis sometimes, but only
one of the several extensions to heap functionality you propose would
make any difference to me (and that only on the odd occasion.)

Yes, I have seen that argument a lot of times.

"I never needed memory leak detectors"
"Only on odd accasion I did use them"

Yes. Everybody here is a genius programmers, looking at this
messages.

BUGS?

ERRORS?

Defensive programming?

That is for wimps...

Endian swap I have only needed to the extent provided by Unix's
ntohl() and htonl() -- i.e., in the context of network programming
in which such routines would definitely be available as part of the
network stack; the implementation details have been irrelevant to me.
I have needed to convert file format byte orders, but such conversions
are inherently non-portable and do not necessarily represent
conversions from any actual hardware; the ability to nail down the
order of bitfields would sometimes be a convenience, but taking the
appropriate adjustments at runtime has never ever been a factor that
affected execution time measurably.


In short, it appears to me that your view of what "the C language is
crying out for" is very heavily coloured by the -kind- of work that
you do. There was *nothing* in your list that had me nodding and
saying, "Me too!". Hence I have strong doubts that the C language is
actually "crying out for" those features, and I have a definite
suspicion that implementing the features you suggest would push
C even more towards the "portable assembler" status -- at a time in
computing when assembler has, to -most- people, become nearly irrelevant.

You get that wrong. The situation now forces you to use non portable
assembler constructs. Incoporating them into the language makes the
need for including assembly less urgent...

Now, maybe what the embedded programming industry needs is a really
first rate "portable assembler" so that developers can write code
usable on anything from GPUs to cell phones to toasters to "hyperthreaded"
PCs.... but as best I understand, programming history is littered with
the carcasses of programming languages that attempted to be
provide portable high-level interfaces to hardware. And I can't say
I've ever seen -any- demand for ADA outside of the US DoD...

Ada is nothing like a "portable assembler"!!!! You are dreaming.

There is a growing gap between "implementors" (responsible for the
nitty gritty of providing funcitonality on particular hardware),
and "programmers" (who don't necessarily care what happens under the
hood). The programmers are in the growing majority; catering to
implementors is going to have about the same long-term effect as
catering to DBase 3 programmers: useful to some, yes, but C would
pretty much drop out of general consciousness as a general purpose
language.

Incredible how much nonsense someone can say in just a few sentences.
C users are implementors, since they implement algorithms and
software...

If you do not want to know what happens "under the hood" just use BASIC
or VB, or C# for that matter.

 

[Keith Thompson]

You can, of course, come up with a single example of such an
"advantage" (that applies to the 10-20 year time frame Jacob was
talking about)?

I don't know about a 10-20 year time frame, but consider this. If a
program is going to scan a string anyway, there's not much benefit in
storing its length separately. In a recent discussion here, somebody
posted an example of such a program (a fairly small one). jacob
claimed that a solution using memcpy() (which requires knowing the
length in advance) was faster than an equivalent solution using
strcpy() (which doesn't) -- but he only provided actual numbers for an
x86 platform. I demonstrated that the strcpy() solution is actually
faster on some other platforms.

Now if you're doing a lot of processing that *does* require knowing
the length in advance, then yes, counted strings are advantageous.
But if you don't happen need it, then computing and storing it is
useless overhead. I'm not arguing that C-style zero-terminated
strings are superior to counted strings, merely that there is a
tradeoff. I don't know which is better in general. jacob thinks he
does know, and that zero-termainted strings are inherently a bug in
the language.

 

[Richard Heathfield]

jacob navia said:

Walter Roberson a écrit :



Yes, I have seen that argument a lot of times.

"I never needed memory leak detectors"

Who has said this?

"Only on odd accasion I did use them"

Well, that may well be true for some people. Personally, I use a leak
detector I wrote myself, which is why I don't need to use a third-party
product such as valgrind.

Yes. Everybody here is a genius programmers, looking at this
messages.

Nobody here has claimed this. But a memory leak is normally pretty easy to
track down and fix.

BUGS?

ERRORS?

Defensive programming?

That is for wimps...

No, defensive programming is a sound strategy, but it's not a binary state -
defensive or not defensive. Rather, it's a matter of degree, and a good
programmer will be able to decide for himself which parts of his program
are vulnerable and need to be defended deeply, and which parts can be
allowed to fly, without let or hindrance from *unnecessary* checking.

If you do not want to know what happens "under the hood" just use BASIC
or VB, or C# for that matter.

Or C, where you very often get to choose whether you want, or do not want,
to know what happens behind the scenes.

 

[Walter Roberson]

Walter Roberson a écrit :

Yes, I have seen that argument a lot of times.

"I never needed memory leak detectors"
"Only on odd accasion I did use them"

Yes. Everybody here is a genius programmers, looking at this
messages.

According to the RCS logs, the last time I worked on a program
for which memory leak analysis was a significant factor, was
11 years ago -- and the actual leak analysis was 12 1/2 years ago.

I have programmed a far bit in C since that time, but the
memory usage patterns became less and less relevant: if the program
didn't run out of physical memory before termination, then
any leaks didn't matter. And I have the discipline to be consistant
in my memory usage, making leaks relatively improbable.

Self-discipline in programming doesn't take a genius programmer,
merely a stubborn one.