Text-Based Windows Library

On Apr 12, 3:46 am, "hstagni" <sta...@gmail.comwrote:

Where can I find a library to created text-based windows applications?
Im looking for a library that can make windows and buttons inside
console.. Many old apps were make like this, i guess

____________________________________
| |
| ------------------ |
| | BUTTON | |
| ------------------ |
| |
| |
L_________________ _________________|

I tried to draw a window here, but im looking for something better
than that,,huahua

DDJ had a project for a character based user interface a few years ago
called D-flat.
ftp://ftp.mv.com/pub/ddj/packages/dflt20.zip

Apr 12 '07 #6

Tak-Shing Chan

On Thu, 12 Apr 2007, user923005 wrote:

On Apr 12, 3:46 am, "hstagni" <sta...@gmail.comwrote:
>Where can I find a library to created text-based windows applications?
Im looking for a library that can make windows and buttons inside
console.. Many old apps were make like this, i guess

____________________________________
| |
| ------------------ |
| | BUTTON | |
| ------------------ |
| |
| |
L_________________ _________________|

I tried to draw a window here, but im looking for something better
than that,,huahua

DDJ had a project for a character based user interface a few years ago
called D-flat.
ftp://ftp.mv.com/pub/ddj/packages/dflt20.zip

[OT] Isn't D-flat the same as C-sharp? I hope Microsoft
wouldn't sue them for trademark infringement. <g,d&r>

Tak-Shing

Apr 12 '07 #7

Clever Monkey

Tak-Shing Chan wrote:

On Thu, 12 Apr 2007, user923005 wrote:

>On Apr 12, 3:46 am, "hstagni" <sta...@gmail.comwrote:
>>Where can I find a library to created text-based windows applications?
Im looking for a library that can make windows and buttons inside
console.. Many old apps were make like this, i guess

____________________________________
| |
| ------------------ |
| | BUTTON | |
| ------------------ |
| |
| |
L_________________ _________________|

I tried to draw a window here, but im looking for something better
than that,,huahua

DDJ had a project for a character based user interface a few years ago
called D-flat.
ftp://ftp.mv.com/pub/ddj/packages/dflt20.zip

[OT] Isn't D-flat the same as C-sharp? I hope Microsoft
wouldn't sue them for trademark infringement. <g,d&r>

[So very OT]

It depends on where you start counting the intervals.

Apr 12 '07 #8

Tak-Shing Chan

On Thu, 12 Apr 2007, Clever Monkey wrote:

Tak-Shing Chan wrote:
>On Thu, 12 Apr 2007, user923005 wrote:

>>On Apr 12, 3:46 am, "hstagni" <sta...@gmail.comwrote:
Where can I find a library to created text-based windows applications?
Im looking for a library that can make windows and buttons inside
console.. Many old apps were make like this, i guess

____________________________________
| |
| ------------------ |
| | BUTTON | |
| ------------------ |
| |
| |
L_________________ _________________|

I tried to draw a window here, but im looking for something better
than that,,huahua

DDJ had a project for a character based user interface a few years ago
called D-flat.
ftp://ftp.mv.com/pub/ddj/packages/dflt20.zip

[OT] Isn't D-flat the same as C-sharp? I hope Microsoft
wouldn't sue them for trademark infringement. <g,d&r>

[So very OT]

It depends on where you start counting the intervals.

[OT] Why should Microsoft care about theory? As far as
MIDI is concerned, D-flat == C-sharp (mod 12). ;-)

Tak-Shing

Apr 12 '07 #9

Charlton Wilbur

>>>>"CM" == Clever Monkey <sp******@clevermonkey.orgwrites:

CMTak-Shing Chan wrote:

>[OT] Isn't D-flat the same as C-sharp? I hope Microsoft
wouldn't sue them for trademark infringement. <g,d&r>

CM[So very OT]
CMIt depends on where you start counting the intervals.

[While we're OT]

Actually, it depends on what your tuning system is. In equal
temperament, for instance, they're the same pitch, and which one you
use is a matter of semantics to convey the meaning you want it to
have. In just intonation, they're different pitches.

Charlton

--
Charlton Wilbur
cw*****@chromatico.net

Apr 12 '07 #10

Tak-Shing Chan

On Thu, 12 Apr 2007, Charlton Wilbur wrote:

>>>>>"CM" == Clever Monkey <sp******@clevermonkey.orgwrites:

CMTak-Shing Chan wrote:

>[OT] Isn't D-flat the same as C-sharp? I hope Microsoft
>wouldn't sue them for trademark infringement. <g,d&r>

CM[So very OT]
CMIt depends on where you start counting the intervals.

[While we're OT]

Actually, it depends on what your tuning system is. In equal
temperament, for instance, they're the same pitch, and which one you
use is a matter of semantics to convey the meaning you want it to
have. In just intonation, they're different pitches.

[OT] If Microsoft do early music, they'll probably patent the
concept of tuning systems (before putting it in the latest
version of Windows Media Player)...

Tak-Shing

Apr 12 '07 #11

"Chris Johnson" <ef******@gmail.comwrote:

On Apr 12, 5:46 am, "hstagni" <sta...@gmail.comwrote:
Where can I find a library to created text-based windows applications?

If I remember properly (not programming Windows, myself), the conio.h
header is the Windows equivalent of curses.

You don't remember properly. Also, for those implementations where it
is, large parts of it it aren't. IOW, don't expect to replace curses
with conio without a lot of work; and ask for help with it in a group
where conio is on-topic. Something like comp.os.msdos.programmer,
perhaps?

Richard

Apr 13 '07 #12

Tak-Shing Chan <t.****@gold.ac.ukwrote:

On Thu, 12 Apr 2007, Clever Monkey wrote:

Tak-Shing Chan wrote:
On Thu, 12 Apr 2007, user923005 wrote:

On Apr 12, 3:46 am, "hstagni" <sta...@gmail.comwrote:
Where can I find a library to created text-based windows applications?
Im looking for a library that can make windows and buttons inside
console.. Many old apps were make like this, i guess

____________________________________
| |
| ------------------ |
| | BUTTON | |
| ------------------ |
| |
| |
L_________________ _________________|

I tried to draw a window here, but im looking for something better
than that,,huahua

DDJ had a project for a character based user interface a few years ago
called D-flat.
ftp://ftp.mv.com/pub/ddj/packages/dflt20.zip

[OT] Isn't D-flat the same as C-sharp? I hope Microsoft
wouldn't sue them for trademark infringement. <g,d&r>

[So very OT]

It depends on where you start counting the intervals.

[OT] Why should Microsoft care about theory? As far as
MIDI is concerned, D-flat == C-sharp (mod 12). ;-)

Yes, but MIDI is an industry-wide Standard. Where M$ is concerned,
industry-wide Standards exist to be broken, by preference in the most
irritating and egregious manner possible.

Richard

Apr 13 '07 #13

Some 20 years ago, it became clear that C strings were not as safe, nor
as fast, as strings in PL/I, Assembler or Pascal.

The primary reasons are that one needs to find the current length of a
string before or during a copy process - this is very time consuming.

Secondly, there is no way of determining the maximum length of a string,
and therefore when copying to a string, it is easy to over-write
adjacent storage with often disastrous consequences, including the
deliberate introduction of viruses.
Decades have passed and the C string problem continues. Buffer
over-runs are just part of the story, and the bugs that can be
introduced - the safety problem is still with us all and it has come
back to bite all of us on the lower part of our anatomy, over and over
again.

I have spent some years studying this problem and have developed some
User friendly C macros that solve the problem.

These solutions do enhance the speed and safety aspects of all "C"
programs - these benefits of speed and safety can be passed on to your
users.

The main benefits are:

* Increased speed (up to 20 times for some string handling)
* More reliability (strings cannot overwrite adjacent storage)
* Easier coding and debugging (consistent set of macros)
* Easier external variables

Here is a very short example:

dcl (op,charvar,253," ",ext); // Variable 'op' is defined
// as an External variable - Max length of 253 characters.
dcl (symbolic,charfixed,8," ",ext); // Fixed length of 8

cpylit(op, "This is a 30 character string ");
cat(op,op); /* Concatenate variable op with it self. Now 60
characters */

cpy(symbolic,op); /* Truncates it to 8 characters */

cpy(op,symbolic); /* Copy it back. */

I invite you download the macros and code at
http://members.ozemail.com.au/~oscar.../fastsafe.html where a fuller
discussion can be found.

Clement Clarke

,-._|\ Clement V. Clarke - Author Jol, EASYPANEL, OSCAR, 370TO486
/ Oz \ Web: www.ozemail.com.au/~oscarptyltd
\_,--.x/ 38 Kings Park Road, West Perth, AUSTRALIA, 6005.
v Tel (61)-8-9324-1119, Mob 0401-054-155.

Apr 13 '07 #14

Clem Clarke said:

Some 20 years ago, it became clear that C strings were not as safe,
nor
as fast, as strings in PL/I, Assembler or Pascal.

C strings are perfectly safe. Some people, however, should not be let
anywhere near a text editor.

The primary reasons are that one needs to find the current length of a
string before or during a copy process - this is very time consuming.

If you need to know it so often that calculating it is a bottleneck,
remember it. And if you don't, don't bother. Hardly difficult.

Secondly, there is no way of determining the maximum length of a
string,

Yes, there is. When you allocate its storage, you know how much you
allocated. Don't Forget.

Decades have passed and the C string problem continues.

What problem?

I have spent some years studying this problem and have developed some
User friendly C macros that solve the problem.

Aha! We're getting to your point...

<snip>

I invite you download the macros and code at
http://members.ozemail.com.au/~oscar.../fastsafe.html where a
fuller discussion can be found.

Convince me that it's worth my time.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Apr 13 '07 #15

Clem Clarke <os*********@ozemail.com.auwrote:

[ The old, old bollocks about C being unsafe, and would we please use
his magic bullet ]

And what, pray, does this have to do with the post you replied to?

Richard

Apr 13 '07 #16

Barry Schwarz

On Fri, 13 Apr 2007 15:26:45 +0800, Clem Clarke
<os*********@ozemail.com.auwrote:

>Some 20 years ago, it became clear that C strings were not as safe, nor
as fast, as strings in PL/I, Assembler or Pascal.

I wonder why you posted it to comp.lang.asm370.

>
The primary reasons are that one needs to find the current length of a
string before or during a copy process - this is very time consuming.

Secondly, there is no way of determining the maximum length of a string,
and therefore when copying to a string, it is easy to over-write
adjacent storage with often disastrous consequences, including the
deliberate introduction of viruses.
Decades have passed and the C string problem continues. Buffer
over-runs are just part of the story, and the bugs that can be
introduced - the safety problem is still with us all and it has come
back to bite all of us on the lower part of our anatomy, over and over
again.

I have spent some years studying this problem and have developed some
User friendly C macros that solve the problem.

Except they use non-portable pragmas, C99 unique comments, and invade
the implementation namespace.

>
These solutions do enhance the speed and safety aspects of all "C"
programs - these benefits of speed and safety can be passed on to your
users.

The main benefits are:

* Increased speed (up to 20 times for some string handling)
* More reliability (strings cannot overwrite adjacent storage)
* Easier coding and debugging (consistent set of macros)
* Easier external variables

Here is a very short example:

dcl (op,charvar,253," ",ext); // Variable 'op' is defined
// as an External variable - Max length of 253 characters.
dcl (symbolic,charfixed,8," ",ext); // Fixed length of 8

cpylit(op, "This is a 30 character string ");
cat(op,op); /* Concatenate variable op with it self. Now 60
characters */

cpy(symbolic,op); /* Truncates it to 8 characters */

cpy(op,symbolic); /* Copy it back. */

Yes, with enough macros you can pass PL/I code to the C compiler.
Remove del for email

Apr 13 '07 #17

Army1987

"Tak-Shing Chan" <t.****@gold.ac.ukha scritto nel messaggio
news:Pi*******************************@scorpio.gol d.ac.uk...

>> [OT] Isn't D-flat the same as C-sharp? I hope Microsoft
wouldn't sue them for trademark infringement. <g,d&r>

[So very OT]

It depends on where you start counting the intervals.

[OT] Why should Microsoft care about theory? As far as
MIDI is concerned, D-flat == C-sharp (mod 12). ;-)

In equal temperament, which long predates MIDI and Microsoft, Db and C# are
the same pitch class, and pitch classes are always defined as notes mod 12.

(Anyway, they are used differently as far as harmony is concerned. And also
in dodecaphonic music, usually one uses sharps when rising and flats when
falling.)

Apr 13 '07 #18

Default User

Clem Clarke wrote:

I invite you download the macros and code at

I figure if a guy can't even use his newsreader properly (this message
was posted as a non-sequitur reply to another thread) then I have grave
doubts about any software he wrote.

Couple that with ludicrous strawman arguments about C-strings, well
safe to say I won't bother.

Brian

Apr 13 '07 #19

Barry

"Barry Schwarz" <sc******@doezl.netwrote in message
news:qu********************************@4ax.com...

On Fri, 13 Apr 2007 15:26:45 +0800, Clem Clarke
<os*********@ozemail.com.auwrote:

>>Some 20 years ago, it became clear that C strings were not as safe, nor
as fast, as strings in PL/I, Assembler or Pascal.

I wonder why you posted it to comp.lang.asm370.

>>
The primary reasons are that one needs to find the current length of a
string before or during a copy process - this is very time consuming.

Secondly, there is no way of determining the maximum length of a string,
and therefore when copying to a string, it is easy to over-write
adjacent storage with often disastrous consequences, including the
deliberate introduction of viruses.
Decades have passed and the C string problem continues. Buffer
over-runs are just part of the story, and the bugs that can be
introduced - the safety problem is still with us all and it has come
back to bite all of us on the lower part of our anatomy, over and over
again.

I have spent some years studying this problem and have developed some
User friendly C macros that solve the problem.

Except they use non-portable pragmas, C99 unique comments, and invade
the implementation namespace.

>>
These solutions do enhance the speed and safety aspects of all "C"
programs - these benefits of speed and safety can be passed on to your
users.

The main benefits are:

* Increased speed (up to 20 times for some string handling)
* More reliability (strings cannot overwrite adjacent storage)
* Easier coding and debugging (consistent set of macros)
* Easier external variables

Here is a very short example:

dcl (op,charvar,253," ",ext); // Variable 'op' is defined
// as an External variable - Max length of 253 characters.
dcl (symbolic,charfixed,8," ",ext); // Fixed length of 8

cpylit(op, "This is a 30 character string ");
cat(op,op); /* Concatenate variable op with it self. Now 60
characters */

cpy(symbolic,op); /* Truncates it to 8 characters */

cpy(op,symbolic); /* Copy it back. */

Yes, with enough macros you can pass PL/I code to the C compiler.

I did a little real work with some PL/I to C translated code and the
translator (a commercial product) either didn't know PL/I or didn't
know C. It was quite a task to debug, as I had no access to the
translator, just the output.

Apr 13 '07 #20

On Apr 13, 1:15 am, Richard Heathfield <r...@see.sig.invalidwrote:

Clem Clarke said:

Some 20 years ago, it became clear that C strings were not as safe,
nor
as fast, as strings in PL/I, Assembler or Pascal.

C strings are perfectly safe. Some people, however, should not be let
anywhere near a text editor.

I think that this is a dangerous oversimplification, because the
language allows:
gets(str);
and
scanf() with %s
and memcpy which does not know how long the objects are
and strcpy which does not know how long the objects are

The billions of dollars of damage caused by computer virus attacks is
largely due to buffer overrun.

Let's not pretend that there isn't any problem. If we do not tread
carefully in C, we can do stupendous damage.

On the other hand, let's also not pretend that we can have s'afe and
fast'. We can have 'safe or fast'. Either I check the physical target
storage address of every character I transfer by stupendous effort or
I don't.

String handling in C is definitely the greatest weakness of the
language. And so we must be keenly aware of it and tread very, very,
very carefully.

IMO-YMMV
[snip]

Apr 13 '07 #21

Keith Thompson

"user923005" <dc*****@connx.comwrites:
[...]

On the other hand, let's also not pretend that we can have s'afe and
fast'. We can have 'safe or fast'. Either I check the physical target
storage address of every character I transfer by stupendous effort or
I don't.

But it is possible to have "safe and nearly as fast as the unsafe
version". Straying slightly off-topic, in a language that has bounds
checking built into the language definition, a sufficiently clever
compiler can often eliminate many, probably most, of the checks.

For example, consider something like this:

char *s = "hello, world";
int len = strlen(s);
int i;
for (i = 0; i < len; i ++) {
printf("s[i] = '%c'\n", s[i]);
}

Theoretically, the expression s[i] requires a bounds check on each
evaluation; if i < 0 or i >= strlen(s), the check fails. But a clever
compiler can perform data flow analysis and determine that the check
will never fail, and thus can be eliminated.

In other words, a lot of checks can be done at compilation time, *if*
there's enough information there for the compiler to work with.

Since C wasn't designed with this kind of thing in mind, it can be
difficult to provide this kind of information in the source.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Apr 13 '07 #22

user923005 said:

On Apr 13, 1:15 am, Richard Heathfield <r...@see.sig.invalidwrote:
>Clem Clarke said:

Some 20 years ago, it became clear that C strings were not as safe,
nor
as fast, as strings in PL/I, Assembler or Pascal.

C strings are perfectly safe. Some people, however, should not be let
anywhere near a text editor.

I think that this is a dangerous oversimplification, because the
language allows:
gets(str);
and
scanf() with %s

This is a problem with gets and scanf("%s", not a problem with C
strings. That is why I do not use gets or scanf("%s".

and memcpy which does not know how long the objects are

Yes, it does, because you tell it. Of course, if the programmer tells it
the wrong information, that's a problem, but it's not a memcpy problem.
It's a programmer problem.

and strcpy which does not know how long the objects are

That doesn't matter, since the programmer takes responsibility for
ensuring that he or she doesn't ask strcpy to do something unsafe. Of
course, some people should not be let anywhere near a text editor...

The billions of dollars of damage caused by computer virus attacks is
largely due to buffer overrun.

This is not a C string issue, though. This is a programmer issue.

Let's not pretend that there isn't any problem. If we do not tread
carefully in C, we can do stupendous damage.

That is a good reason to tread carefully. It is not a good reason to
reject C strings as being inherently unsafe.

On the other hand, let's also not pretend that we can have s'afe and
fast'. We can have 'safe or fast'. Either I check the physical target
storage address of every character I transfer by stupendous effort or
I don't.

I have yet to see a fast string. :-)

String handling in C is definitely the greatest weakness of the
language.

Personally, I disagree, but I certainly respect your opinion.

And so we must be keenly aware of it and tread very, very,
very carefully.

And those who do tread carefully will still occasionally foul up, but
that's what testing's for, right? As for those who do not tread
carefully, I wouldn't want them programming in *any* language, using
*any* string model.

IMO-YMMV

A bit, yes. I think it's just a question of perspective, actually. We
both see the same problems, but we think about them in different ways.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Apr 13 '07 #23

On Apr 13, 2:19 pm, Richard Heathfield <r...@see.sig.invalidwrote:

user923005 said:

On Apr 13, 1:15 am, Richard Heathfield <r...@see.sig.invalidwrote:
Clem Clarke said:

Some 20 years ago, it became clear that C strings were not as safe,
nor
as fast, as strings in PL/I, Assembler or Pascal.

C strings are perfectly safe. Some people, however, should not be let
anywhere near a text editor.

I think that this is a dangerous oversimplification, because the
language allows:
gets(str);
and
scanf() with %s

This is a problem with gets and scanf("%s", not a problem with C
strings. That is why I do not use gets or scanf("%s".

and memcpy which does not know how long the objects are

Yes, it does, because you tell it. Of course, if the programmer tells it
the wrong information, that's a problem, but it's not a memcpy problem.
It's a programmer problem.

and strcpy which does not know how long the objects are

That doesn't matter, since the programmer takes responsibility for
ensuring that he or she doesn't ask strcpy to do something unsafe. Of
course, some people should not be let anywhere near a text editor...

The billions of dollars of damage caused by computer virus attacks is
largely due to buffer overrun.

This is not a C string issue, though. This is a programmer issue.

Let's not pretend that there isn't any problem. If we do not tread
carefully in C, we can do stupendous damage.

That is a good reason to tread carefully. It is not a good reason to
reject C strings as being inherently unsafe.

On the other hand, let's also not pretend that we can have s'afe and
fast'. We can have 'safe or fast'. Either I check the physical target
storage address of every character I transfer by stupendous effort or
I don't.

I have yet to see a fast string. :-)

String handling in C is definitely the greatest weakness of the
language.

Personally, I disagree, but I certainly respect your opinion.

And so we must be keenly aware of it and tread very, very,
very carefully.

And those who do tread carefully will still occasionally foul up, but
that's what testing's for, right? As for those who do not tread
carefully, I wouldn't want them programming in *any* language, using
*any* string model.

IMO-YMMV

A bit, yes. I think it's just a question of perspective, actually. We
both see the same problems, but we think about them in different ways.

The C language strings are clearly a danger. The literal billions of
dollars in damage caused by careless use of strings is a clear
indication of that fact. It is possible to design strings that know
how big they are and protect themselves from over-writes. Other
languages have this feature. Of course the cost is that these strings
are not fast like C strings.

Here is a C language feature that is dangerous which has to do with
strings:

static const char token[6] = "123456";

....

if (strstr(string, token) != NULL) puts("found it.");

The fact that it is so insidious made the C++ people choose this as
something that simply had to be fixed and could not be passed on as
allowed in the new language.

Apr 13 '07 #24

Barry

"user923005" <dc*****@connx.comwrote in message
news:11**********************@e65g2000hsc.googlegr oups.com...

On Apr 13, 2:19 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>user923005 said:

On Apr 13, 1:15 am, Richard Heathfield <r...@see.sig.invalidwrote:
Clem Clarke said:

Some 20 years ago, it became clear that C strings were not as safe,
nor
as fast, as strings in PL/I, Assembler or Pascal.

>C strings are perfectly safe. Some people, however, should not be let
anywhere near a text editor.

I think that this is a dangerous oversimplification, because the
language allows:
gets(str);
and
scanf() with %s

This is a problem with gets and scanf("%s", not a problem with C
strings. That is why I do not use gets or scanf("%s".

and memcpy which does not know how long the objects are

Yes, it does, because you tell it. Of course, if the programmer tells it
the wrong information, that's a problem, but it's not a memcpy problem.
It's a programmer problem.

and strcpy which does not know how long the objects are

That doesn't matter, since the programmer takes responsibility for
ensuring that he or she doesn't ask strcpy to do something unsafe. Of
course, some people should not be let anywhere near a text editor...

The billions of dollars of damage caused by computer virus attacks is
largely due to buffer overrun.

This is not a C string issue, though. This is a programmer issue.

Let's not pretend that there isn't any problem. If we do not tread
carefully in C, we can do stupendous damage.

That is a good reason to tread carefully. It is not a good reason to
reject C strings as being inherently unsafe.

On the other hand, let's also not pretend that we can have s'afe and
fast'. We can have 'safe or fast'. Either I check the physical target
storage address of every character I transfer by stupendous effort or
I don't.

I have yet to see a fast string. :-)

String handling in C is definitely the greatest weakness of the
language.

Personally, I disagree, but I certainly respect your opinion.

And so we must be keenly aware of it and tread very, very,
very carefully.

And those who do tread carefully will still occasionally foul up, but
that's what testing's for, right? As for those who do not tread
carefully, I wouldn't want them programming in *any* language, using
*any* string model.

IMO-YMMV

A bit, yes. I think it's just a question of perspective, actually. We
both see the same problems, but we think about them in different ways.

The C language strings are clearly a danger. The literal billions of
dollars in damage caused by careless use of strings is a clear
indication of that fact. It is possible to design strings that know
how big they are and protect themselves from over-writes. Other
languages have this feature. Of course the cost is that these strings
are not fast like C strings.

Here is a C language feature that is dangerous which has to do with
strings:

static const char token[6] = "123456";

...

if (strstr(string, token) != NULL) puts("found it.");

The fact that it is so insidious made the C++ people choose this as
something that simply had to be fixed and could not be passed on as
allowed in the new language.

You just said a few minutes ago anyone can be a C programmer in
a month. While you are not in error here, your argument isn't
consistent.

Apr 13 '07 #25

user923005 said:

<snip>

The C language strings are clearly a danger.

Well, obviously it's clear to you, but it's not so clear to me.

The literal billions of
dollars in damage caused by careless use of strings is a clear
indication of that fact.

To me, it indicates, rather, that carelessness is clearly a danger.

<snip>

Here is a C language feature that is dangerous which has to do with
strings:

static const char token[6] = "123456";

I see nothing dangerous about this.

if (strstr(string, token) != NULL) puts("found it.");

But this is just carelessness on the part of the programmer, since
'token' - whilst an array of char - is not a string, so he has no
business passing it to a function that expects one.

The fact that it is so insidious made the C++ people choose this as
something that simply had to be fixed and could not be passed on as
allowed in the new language.

Insidious? MMMV.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Apr 13 '07 #26

Ed Jensen

Richard Heathfield <rj*@see.sig.invalidwrote:

>and memcpy which does not know how long the objects are

Yes, it does, because you tell it. Of course, if the programmer tells it
the wrong information, that's a problem, but it's not a memcpy problem.
It's a programmer problem.

[SNIP]

>and strcpy which does not know how long the objects are

That doesn't matter, since the programmer takes responsibility for
ensuring that he or she doesn't ask strcpy to do something unsafe. Of
course, some people should not be let anywhere near a text editor...

[SNIP]

>The billions of dollars of damage caused by computer virus attacks is
largely due to buffer overrun.

This is not a C string issue, though. This is a programmer issue.

[SNIP]

Maybe we should write old style (K&R) C code too. You know, without
unnecesary things like function prototypes.

After all, if you screw up your parameters and the compiler fails to
tell you, "it's just a programmer problem" and "that's what testing is
for".

We wouldn't want the compiler making life easier for the developer and
safer for the end user. No, oh no. That's a programmer issue!

Apr 14 '07 #27

Ed Jensen said:

<snip>

Maybe we should write old style (K&R) C code too. You know, without
unnecesary things like function prototypes.

After all, if you screw up your parameters and the compiler fails to
tell you, "it's just a programmer problem" and "that's what testing is
for".

But function prototypes do not increase the execution time of the code.
They're a translation feature. If we can make the programmer's life
easier by making the translator spot more errors, that's great! If the
compiler can spot bounds violations at compilation time, that's
fabulous! Nothing but good news, surely. But let's not put the
bounds-checker into the C runtime - ***please***.

If I write a loop that I know won't violate bounds, what's the point in
the computer agreeing with me over and over again?

And if I write a loop that I know *will* violate bounds but which will
cause a (highly non-portable) behaviour that I happen to want, then I
don't want the compiler telling me I can't.

And if I write a loop without realising that it violates bounds, it's my
own stupid fault.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Apr 14 '07 #28

websnarf

On Apr 13, 12:26 am, Clem Clarke <oscarpty...@ozemail.com.auwrote:

Some 20 years ago, it became clear that C strings were not as safe, nor
as fast, as strings in PL/I, Assembler or Pascal. [...] I have spent some
years studying this problem and have developed some User friendly C macros
that solve the problem. [...]

These macros just look like they encode classic tricks that any
competent C programmer could or would duplicate by hand. The set of
functions your propose is also extremely small, (fgets(), strftime(),
strtok() anyone?). So it seems hard to see this as an effective
programming aid. Data truncation or runtime stops are also kinds of
errors -- while usually better than overruning the buffer, this leaves
the problem of dynamic strings unsolved in the C language. The real
reason why Pascal strings are still better than C is because storage
for the strings is automatically managed.

Look, if you want to compare safety and speed, you should compare it
to my library:

http://bstring.sf.net/

I set a pretty high bar for both speed and safety. Its also extremely
easy to use, its portable, and works directly with ordinary C string-
based libraries without onerous conversion penalties, if the need
arises. This library also performs automatic dynamic memory
management so that buffer overflows are basically eliminated.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Apr 14 '07 #29

Ed Jensen

Richard Heathfield <rj*@see.sig.invalidwrote:

Ed Jensen said:
>Maybe we should write old style (K&R) C code too. You know, without
unnecesary things like function prototypes.

After all, if you screw up your parameters and the compiler fails to
tell you, "it's just a programmer problem" and "that's what testing is
for".

But function prototypes do not increase the execution time of the code.
They're a translation feature. If we can make the programmer's life
easier by making the translator spot more errors, that's great! If the
compiler can spot bounds violations at compilation time, that's
fabulous! Nothing but good news, surely. But let's not put the
bounds-checker into the C runtime - ***please***.

No matter how much some people might advocate it, nobody is going to
take regular C strings away from C developers. On the other hand,
having access to macros or a library that implements "safe" strings
might be a tradeoff some developers want to make.

Hell, it's very likely a tradeoff most end users would want the
developer to make, unless we're talking about low level, performance
critical code.

Therefore, given that C developers lose nothing (they can keep using
regular C strings), and only incur the overhead of "safe" strings if
they choose it, I really don't see what the debate is all about.

Apr 14 '07 #30

Great. Thank you, I will have a look at them.

Do they keep a length byte somewhere for speed like PL/I or Pascal, or
do they use strlen (or equivalent)?
Cheers,

Clem Clarke

we******@gmail.com wrote:

On Apr 13, 12:26 am, Clem Clarke <oscarpty...@ozemail.com.auwrote:

These macros just look like they encode classic tricks that any
competent C programmer could or would duplicate by hand. The set of
functions your propose is also extremely small, (fgets(), strftime(),
strtok() anyone?). So it seems hard to see this as an effective
programming aid. Data truncation or runtime stops are also kinds of
errors -- while usually better than overruning the buffer, this leaves
the problem of dynamic strings unsolved in the C language. The real
reason why Pascal strings are still better than C is because storage
for the strings is automatically managed.

Look, if you want to compare safety and speed, you should compare it
to my library:

http://bstring.sf.net/

I set a pretty high bar for both speed and safety. Its also extremely
easy to use, its portable, and works directly with ordinary C string-
based libraries without onerous conversion penalties, if the need
arises. This library also performs automatic dynamic memory
management so that buffer overflows are basically eliminated.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Apr 14 '07 #31

Ed Jensen wrote:

I agree with you Ed. No-one would dare to try and take away normal strings!

However, having an easy to use set of routines that make string much
safer, that even make strings faster, seems like a GOOD thing to me.
Cheers,

Clem Clarke
,-._|\ Clement V. Clarke - Author Jol, EASYJCL, EASYPANEL, 370TO486
/ Oz \ Web: http://www.ozemail.com.au/~oscarptyltd
\_,--.x/ 16/38 Kings Park Road, West Perth, AUSTRALIA, 6005.
v Tel (61)-8-9324-1119, Mob 0401-054-155.
Email: os*********@ozemail.com.au

>

No matter how much some people might advocate it, nobody is going to
take regular C strings away from C developers. On the other hand,
having access to macros or a library that implements "safe" strings
might be a tradeoff some developers want to make.

Hell, it's very likely a tradeoff most end users would want the
developer to make, unless we're talking about low level, performance
critical code.

Therefore, given that C developers lose nothing (they can keep using
regular C strings), and only incur the overhead of "safe" strings if
they choose it, I really don't see what the debate is all about.

Apr 14 '07 #32

Re Overheads.

And I have been thinking about making a more simplified version (maybe
using C++) that doesn't allow for "fixed" PL/I or 370 Assembler fields.
This would reduce the overhead to a quick binary compare and swap the
maximum lengths. But you would still get the huge speed advantage of
not having to search for (or check for) the binary zero.

Having "fixed" length strings creates a bit of code bloat on Borland 5.x
32 bit compilers. The earlier 16 bit Borland compilers used to optimize
everything away not needed code.

I am all for speed and efficiency, which is why I mentioned this at all.
Every version of Windows gets bigger and slower, and I am quite
convinced that C strings are partly to blame.

Even IBM is using C in Z/OS, and it isn't nearly as fast as it could be,
even though IBM has added a special instruction to go searching for
things like binary zeros.

And on the mainframes, there was always had an instruction to move a
bunch of bytes quickly, in one hit (MVC and later MVCL). So I like to
use them where possible. Although on 64 bit machines you can move 8
bytes pretty quickly by loading and storing a register...
Create only joy and happiness in your life and in others,

Clem Clarke
,-._|\ Clement V. Clarke - Author Jol, EASYJCL, EASYPANEL, 370TO48
/ Oz \ Web: http://www.ozemail.com.au/~oscarptyltd
\_,--.x/ 16/38 Kings Park Road, West Perth, AUSTRALIA, 6005.
v Tel (61)-8-9324-1119, Mob 0401-054-155.
Richard Heathfield wrote:

>
But function prototypes do not increase the execution time of the code.
They're a translation feature. If we can make the programmer's life
easier by making the translator spot more errors, that's great! If the
compiler can spot bounds violations at compilation time, that's
fabulous! Nothing but good news, surely. But let's not put the
bounds-checker into the C runtime - ***please***.

Apr 15 '07 #33

Hi Brian,

(This is definitely off topic...)

I could easily just ignore this totally, but it is an excellent
opportunity to talk about philosophy and judgment.

You have all heard the saying "Judge not" or similar.

What I didn't realise was that judging stops you receiving. It puts
walls around you and stops things coming in.

So, it might be money (too much money is evil...). It might be love (I
am unlovable). It might be ideas (only birds can fly or if we were
meant to to fly, we would have wings).

It might be thoughts about programming languages (PL/I is better than C).

It could be anything....

So, I am doing my darndest to remove all judgments and allow all sorts
of ideas etc to flow to me, from this wonderfully abundant universe.

If you haven't seen the movie "What The Bleep Do we Know", or "The
Secret", they are two of many movies that will give you an idea of what
I am talking about. www.whatthebleep.com and
http://www.thesecret.tv/home.html
And you might like to go to a site
http://www.accessconsciousness.com/about.asp to learn more.

Enjoy life,

Clem

"I am only one, but I am one. I cannot do everything, but I can do
something. And I will not let what I cannot do interfere with what I can
do." ~Edward Everett Hale

Default User wrote:

Clem Clarke wrote:

>>I invite you download the macros and code at

I figure if a guy can't even use his newsreader properly (this message
was posted as a non-sequitur reply to another thread) then I have grave
doubts about any software he wrote.

Couple that with ludicrous strawman arguments about C-strings, well
safe to say I won't bother.

Brian

Apr 15 '07 #34

Ian Collins

Clem Clarke wrote:

Hi Brian,

(This is definitely off topic...)

If you are going to post off topic drivel, the least you can do is not
to top-post it.

--
Ian Collins.

Apr 15 '07 #35

CBFalconer

Clem Clarke wrote:

>
And I have been thinking about making a more simplified version (maybe
using C++) that doesn't allow for "fixed" PL/I or 370 Assembler fields.
This would reduce the overhead to a quick binary compare and swap the
maximum lengths. But you would still get the huge speed advantage of
not having to search for (or check for) the binary zero.

Top-posting has greatly decreased your readership. Your answer
belongs after (or intermixed with) the quoted material to which you
reply, after snipping all irrelevant material. See the following
links:

--
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/ (taming google)
<http://members.fortunecity.com/nnqweb/ (newusers)

--
Posted via a free Usenet account from http://www.teranews.com

Apr 15 '07 #36

Default User

Clem Clarke wrote:

Hi Brian,

(This is definitely off topic...)

I could easily just ignore this totally, but it is an excellent
opportunity to talk about philosophy and judgment.

I think I already plonked you with my work account. At any rate, I'm
definitely plonking you at home.

Brian

Apr 15 '07 #37

Martin Ambuhl

Clem Clarke wrote:

Hi Brian,

(This is definitely off topic...)

I could easily just ignore this totally, but it is an excellent
opportunity to talk about philosophy and judgment.

[followed by random crap that is definitely not about philosophy or
judgment, as well as being not topical in comp.lang.c]

Bye. I'm sure that by now you've convinced many that you have nothing
worthwhile to say. At least I won't be seeing any of your crap until
you do what trolls usually do to avoid killfiles.

Apr 15 '07 #38

websnarf

On Apr 14, 4:24 pm, Clem Clarke <oscarpty...@ozemail.com.auwrote:

Great. Thank you, I will have a look at them.

Do they keep a length byte somewhere for speed like PL/I or
Pascal, or do they use strlen (or equivalent)?

It has a length field, but its not hidden. Its an explicit part of
the structure and properly defines the correct length of the
"bstring". '\0' is not considered a real terminator except where
semantic equivalency with standard C strings has been ensured (the
situations are intuitive, and explained in the documentation).

Besides the obvious gargantuan performance advantage over strcat,
simple things like loop unrolling for string comparison can be
performed without having to check for terminators first, for example.
For copying, the faster memcpy() and memmove() functions (which can
use system based block copy enhancements) can be used in place of
strcpy(). Functionality improves by allowing you to make arbitrary
reference based sub-strings in a safe way, the library never truncates
results so long as there is available memory, it never buffer
overflows if you are just using the API, it allows you to treat any
binary block of data as a string and it comes with lots of example and
utility code to show you how to use it.

Its also extremely easy to understand and use. Its feels as easy as
Python, Java, Pascal or whatever in terms of string use, while
retaining all the power and representational functionality of C.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Apr 15 '07 #39

Al Balmer

On Sun, 15 Apr 2007 09:47:59 +0800, Clem Clarke
<os*********@ozemail.com.auwrote:

>So, I am doing my darndest to remove all judgments and allow all sorts
of ideas etc to flow to me, from this wonderfully abundant universe.

You've succeeded. If you had any judgment, you wouldn't be posting
this crap here.

--
Al Balmer
Sun City, AZ

Apr 16 '07 #40

Charlton Wilbur

>>>>"EJ" == Ed Jensen <ej*****@visi.comwrites:

EJTherefore, given that C developers lose nothing (they can keep
EJusing regular C strings), and only incur the overhead of
EJ"safe" strings if they choose it, I really don't see what the
EJdebate is all about.

Violent agreement; on my usual programming platform, for instance, I
use CFStrings on a regular basis for just that reason. I accept the
drawbacks (more overhead, reduced portability) in exchange for a
number of other benefits (more automatic memory management, safety
from buffer overruns, easier internationalization because of Unicode
support). C strings are still there for me to use, but the tradeoffs
make them not worth it.

Programmers who cannot competently manage C strings themselves and who
refuse to use any of the available safe string libraries are, in a
word, stupid. Managers who hire such programmers -- or who, having
hired programmers who cannot competently manage C strings, prohibit
them from using safe string libraries -- are, in three words, *really*
@#$%ing stupid.

Charlton
--
Charlton Wilbur
cw*****@chromatico.net

Apr 16 '07 #41

"user923005" <dc*****@connx.comwrote:

On Apr 13, 1:15 am, Richard Heathfield <r...@see.sig.invalidwrote:
Clem Clarke said:

Some 20 years ago, it became clear that C strings were not as safe,
nor
as fast, as strings in PL/I, Assembler or Pascal.
C strings are perfectly safe. Some people, however, should not be let
anywhere near a text editor.

I think that this is a dangerous oversimplification, because the
language allows:
gets(str);
and
scanf() with %s
and memcpy which does not know how long the objects are
and strcpy which does not know how long the objects are

String handling in C is definitely the greatest weakness of the
language.

However, it is also one of its greatest strengths. Yes, I know this is
heresy in the eyes of the Perl programmers, but really, the way C
handles strings may require a bit of care, but it also allows a lot of
efficiency.

Richard

Apr 17 '07 #42

Kelsey Bjarnason

[snips]

On Fri, 13 Apr 2007 15:06:16 -0700, user923005 wrote:

Here is a C language feature that is dangerous which has to do with
strings:

static const char token[6] = "123456";

...

if (strstr(string, token) != NULL) puts("found it.");

Okay, I don't see the problem. You created a char array - not a string,
simply a char array - and passed it to a function that expects a string.

If one insists upon passing about incorrect data, one is going to get
failures. This isn't a language issue, it's an issue of someone being
careless - not a good sign in a programmer. Or clueless, an even worse
sign.

Apr 17 '07 #43

On Apr 17, 3:14 pm, Kelsey Bjarnason <kbjarna...@ncoldns.comwrote:

[snips]

On Fri, 13 Apr 2007 15:06:16 -0700, user923005 wrote:
Here is a C language feature that is dangerous which has to do with
strings:

static const char token[6] = "123456";

...

if (strstr(string, token) != NULL) puts("found it.");

Okay, I don't see the problem. You created a char array - not a string,
simply a char array - and passed it to a function that expects a string.

The only difference between a character array and a string in the C
language is the contents.
This is one way in which the problem can arise (and it does happen).
It can also arise from memcpy or strcpy of one char too far, assigning
the last char to a non-zero value, and a host of other ways.

If one insists upon passing about incorrect data, one is going to get
failures. This isn't a language issue, it's an issue of someone being
careless - not a good sign in a programmer. Or clueless, an even worse
sign.

It is a sign of a defect in the language. That many C programmers
refuse to see this is simply unbelievable.

If there were not literally BILLIONS of dollars of damage caused by
this defect, then the defenders would have a leg to stand on.
These problems are not always due to carelessness. They are also due
to malice.

I have seen (for instance) scanf() or sscanf() used with %s used for
reading a string, written by good programmers. This is (of course)
exactly the same danger as gets(). Herein lies the problem: They are
assuming that the program's users are sensible people who are not out
to harm anyone. In reality, this is true for 99.9999% of the users.
But that one tiny fragment on the end is out to cause harm.

It's kind of like making armor, with a great big opening over the
heart. "But people should't stab you in the heart! That's not very
nice!" Well, yes, but that's the whole point of armor.

I also think that dangerous constructs are (to some degree)
unavoidable to C. But to say that these things are not dangerous is
really putting our head in the sand.

One could also say that an unsheathed sword is not dangerous. After
all, if we do not weild it in a malevolent or incompetent manner,
nobody is going to get hurt (unless they fall on it themselves). But
in reality a sword *is* a dangerous thing because it requires *great
and competent care* not to harm someone with it. Pretending there is
no danger attached to a sword does not make it safer. If anything, it
will make it more dangerous. Pretending that C does not have
dangerous (or even badly designed) things is also something that
encourages carelessness. The very thing we want to avoid in the
utmost.
IMO YMMV.
But if you think differently, then YOIW.

Apr 17 '07 #44

Keith Thompson

user923005 <dc*****@connx.comwrites:
[...]

I have seen (for instance) scanf() or sscanf() used with %s used for
reading a string, written by good programmers. This is (of course)
exactly the same danger as gets().

[...]

A "good" programmer would not use scanf() with "%s".

Actually, it's probably a little harsh to judge someone as not being a
"good programmer" because of one mistake, even a serious one. But it
certainly is a mistake, and one that should be corrected both in the
code and in the programmer's habits.

(sscanf() could be a different story, since the data being scanned is
under the control of the programmer.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Apr 17 '07 #45

On Apr 13, 3:16 pm, "Barry" <bar...@nullhighstream.netwrote:

"user923005" <dcor...@connx.comwrote in message

news:11**********************@e65g2000hsc.googlegr oups.com...

On Apr 13, 2:19 pm, Richard Heathfield <r...@see.sig.invalidwrote:
user923005 said:

On Apr 13, 1:15 am, Richard Heathfield <r...@see.sig.invalidwrote:
Clem Clarke said:

Some 20 years ago, it became clear that C strings were not as safe,
nor
as fast, as strings in PL/I, Assembler or Pascal.

C strings are perfectly safe. Some people, however, should not be let
anywhere near a text editor.

I think that this is a dangerous oversimplification, because the
language allows:
gets(str);
and
scanf() with %s

This is a problem with gets and scanf("%s", not a problem with C
strings. That is why I do not use gets or scanf("%s".

and memcpy which does not know how long the objects are

Yes, it does, because you tell it. Of course, if the programmer tells it
the wrong information, that's a problem, but it's not a memcpy problem.
It's a programmer problem.

and strcpy which does not know how long the objects are

That doesn't matter, since the programmer takes responsibility for
ensuring that he or she doesn't ask strcpy to do something unsafe. Of
course, some people should not be let anywhere near a text editor...

The billions of dollars of damage caused by computer virus attacks is
largely due to buffer overrun.

This is not a C string issue, though. This is a programmer issue.

Let's not pretend that there isn't any problem. If we do not tread
carefully in C, we can do stupendous damage.

That is a good reason to tread carefully. It is not a good reason to
reject C strings as being inherently unsafe.

On the other hand, let's also not pretend that we can have s'afe and
fast'. We can have 'safe or fast'. Either I check the physical target
storage address of every character I transfer by stupendous effort or
I don't.

I have yet to see a fast string. :-)

String handling in C is definitely the greatest weakness of the
language.

Personally, I disagree, but I certainly respect your opinion.

And so we must be keenly aware of it and tread very, very,
very carefully.

And those who do tread carefully will still occasionally foul up, but
that's what testing's for, right? As for those who do not tread
carefully, I wouldn't want them programming in *any* language, using
*any* string model.

IMO-YMMV

A bit, yes. I think it's just a question of perspective, actually. We
both see the same problems, but we think about them in different ways.

The C language strings are clearly a danger. The literal billions of
dollars in damage caused by careless use of strings is a clear
indication of that fact. It is possible to design strings that know
how big they are and protect themselves from over-writes. Other
languages have this feature. Of course the cost is that these strings
are not fast like C strings.

Here is a C language feature that is dangerous which has to do with
strings:

static const char token[6] = "123456";

...

if (strstr(string, token) != NULL) puts("found it.");

The fact that it is so insidious made the C++ people choose this as
something that simply had to be fixed and could not be passed on as
allowed in the new language.

You just said a few minutes ago anyone can be a C programmer in
a month. While you are not in error here, your argument isn't
consistent.

No, I said the O.P. can become competent enough for junior projects in
a month. And I did not say anyone could do it. There are clearly
people who are not cut out to be programmers. If you want to
attribute something to me, why not quote it from my message? If you
take an actual quote, then there is less chance for misapplication.

Apr 17 '07 #46

Kenneth Brody

Kelsey Bjarnason wrote:

>
[snips]

On Fri, 13 Apr 2007 15:06:16 -0700, user923005 wrote:

Here is a C language feature that is dangerous which has to do with
strings:

static const char token[6] = "123456";

...

if (strstr(string, token) != NULL) puts("found it.");

Okay, I don't see the problem. You created a char array - not a string,
simply a char array - and passed it to a function that expects a string.

If one insists upon passing about incorrect data, one is going to get
failures. This isn't a language issue, it's an issue of someone being
careless - not a good sign in a programmer. Or clueless, an even worse
sign.

It's "dangerous" in that a newbie doesn't see the difference between:

char token[6] = "123456";
and
char token[] = "123456";

After all, they only see 6 chars in both.

And, as far as the compiler is concerned, both can be passed to
strstr() without issue.

However, a language that prevents a newbie from doing anything that
you can call "dangerous" is also not going to allow an experienced
programmer from doing anything beyond newbie-stuff.

With power comes responsibility.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Apr 17 '07 #47

On Apr 17, 3:55 pm, Kenneth Brody <kenbr...@spamcop.netwrote:

Kelsey Bjarnason wrote:

[snips]

On Fri, 13 Apr 2007 15:06:16 -0700, user923005 wrote:

Here is a C language feature that is dangerous which has to do with
strings:

static const char token[6] = "123456";

...

if (strstr(string, token) != NULL) puts("found it.");

Okay, I don't see the problem. You created a char array - not a string,
simply a char array - and passed it to a function that expects a string.

If one insists upon passing about incorrect data, one is going to get
failures. This isn't a language issue, it's an issue of someone being
careless - not a good sign in a programmer. Or clueless, an even worse
sign.

It's "dangerous" in that a newbie doesn't see the difference between:

char token[6] = "123456";
and
char token[] = "123456";

After all, they only see 6 chars in both.

And, as far as the compiler is concerned, both can be passed to
strstr() without issue.

However, a language that prevents a newbie from doing anything that
you can call "dangerous" is also not going to allow an experienced
programmer from doing anything beyond newbie-stuff.

That has not been demonstrated.

With power comes responsibility.

It's dangerous because it's dangerous.

We are not talking about newbies. The buffer overrun virus attacks
that have caused billions of dollars of damage attacked code written
by experienced programmers.
If Grand Coulee dam burst, the damage would be in billions. We would
call something that might do that "dangerous".
There have been billions of dollars of damage caused by C buffer
overruns. These programs were not written by newbies but by people
with decades of experience.
I can show you literally dozens of posts -- written in this forum by
experts respected by all -- that contain buffer overrun exploits.
There is no debate as to whether the construct is dangerous or not.
The fact that it has caused billions of dollars of damage means that
it *is* _by definition_ dangerous.
C strings are a bad design, and reliance upon a zero byte to terminate
them is bad.
Now, it's OK for a language to have bad features. Every language has
bad features. But to pretend that they aren't bad and don't need
attention -- that is very bad. In fact, it is worse than the defects
in the first place.

I belive that those who say that C strings are not dangerous are not
clear thinkers, or are simply so in love with C that they refuse to
look at the wart on her nose and say that it is anything less than
breathtakingly beautiful.

They are dangerous because they have caused huge, huge harm again and
again -- despite careful experts doing their best to write safe code.

>From http://www.m-w.com/cgi-bin/dictionar...y&va=dangerous

we have this:
dangerous
One entry found for dangerous.
Main Entry: dan·ger·ous
Pronunciation: 'dAn-j&-r&s; 'dAn-j&rs, -zhr&s
Function: adjective
1 : exposing to or involving danger <a dangerous job>
2 : able or likely to inflict injury or harm <a dangerous man>
- dan·ger·ous·ly adverb
- dan·ger·ous·ness noun
synonyms DANGEROUS, HAZARDOUS, PRECARIOUS, PERILOUS, RISKY mean
bringing or involving the chance of loss or injury. DANGEROUS applies
to something that may cause harm or loss unless dealt with carefully
<soldiers on a dangerous mission>. HAZARDOUS implies great and
continuous risk of harm or failure <claims that smoking is hazardous
to your health>. PRECARIOUS suggests both insecurity and uncertainty
<earned a precarious living by gambling>. PERILOUS strongly implies
the immediacy of danger <perilous mountain roads>. RISKY often applies
to a known and accepted danger <shied away from risky investments>.

Billions of dollars in damage would amount to "harm or loss". Much of
this harm or loss is caused by C buffer overrun exploits. By
definition, C strings are dangerous.

Apr 18 '07 #48