copy long strings in C

[Mark McIntyre]

char st1[1000],st2[650];

st2[650] = '\0';

st2 doesn't have a 651st element, so this will cause a crash of some
sort.

 

[Suman]

In C, empty parentheses in the DEFINITION of a function
indicate that it takes no parameters. This definition would
provide a declaration, but not a prototype, for the defined function.

N869
Introduction
[#2] Certain features are obsolescent, which means that they
may be considered for withdrawal in future revisions of this
International Standard. They are retained because of their
widespread use, but their use in new implementations (for
implementation features) or new programs (for language
[6.11] or library features [7.26]) is discouraged.

6.11 Future language directions
6.11.4 Function declarators
[#1] The use of function declarators with empty parentheses
(not prototype-format parameter type declarators) is an
obsolescent feature.
6.11.5 Function definitions
[#1] The use of function definitions with separate parameter
identifier and declaration lists (not prototype-format
parameter type and identifier declarators) is an obsolescent
feature.

Thanks, pete. I'll keep that in mind.

 

[Keith Thompson]

The length of a character array is determined by NULL.

The length of a character array is determined by the length of the array.

The length of a string is determined by the position of the first null
character (if it doesn't have one, it's not a string). A null
character is sometimes referred to as NUL. NULL is (a macro that
expands to) a null pointer constant, which is a very different thing.

 

[Keith Thompson]

char st1[1000],st2[650];

st2[650] = '\0';

st2 doesn't have a 651st element, so this will cause a crash of some
sort.

st2 doesn't have a 651st element, but this very likely *won't* cause a
crash. It's more likely to quietly write over some other piece of
memory, which may or may not be part of some other variable.

 

[Suman]

Defining functions in this way is deprecated and is still maintained
only for compatibility with old code. There is no good reason for not
using prototypes. Furthermore, adding 'void' improves consistency, since
a function _declaration_ with empty parentheses means a completely
different thing from a function _definition_ defined in this way.

Concur. I took a little liberty ...

 

[Coder]

The length of a character array is determined by the length of the array.

The length of a string is determined by the position of the first null
character (if it doesn't have one, it's not a string). A null
character is sometimes referred to as NUL. NULL is (a macro that
expands to) a null pointer constant, which is a very different thing.

Thanks Keith for enlightening me on the difference between a null
character and a NULL macro.

 

[Chris Dollin]

No, it procedures undefined behaviour.

Hell's teeth, what an ... interesting ... piece of autotypoing.

"produces".

 

[Mark McIntyre]

char st1[1000],st2[650];

st2[650] = '\0';

st2 doesn't have a 651st element, so this will cause a crash of some
sort.

st2 doesn't have a 651st element, but this very likely *won't* cause a
crash. It's more likely to quietly write over some other piece of
memory, which may or may not be part of some other variable.

I define that as a crash. It may be invisible, buy nevertheless you're
off the rails.

 

[Default User]

On Wed, 17 Aug 2005 05:11:49 GMT, in comp.lang.c , Keith Thompson


I define that as a crash. It may be invisible, buy nevertheless you're
off the rails.

That's not any definition of "crash" in computer terms that I've ever
heard.



Brian

 

[Keith Thompson]

On 16 Aug 2005 01:25:29 -0700, in comp.lang.c , "Coder"

char st1[1000],st2[650];

st2[650] = '\0';

st2 doesn't have a 651st element, so this will cause a crash of some
sort.

st2 doesn't have a 651st element, but this very likely *won't* cause a
crash. It's more likely to quietly write over some other piece of
memory, which may or may not be part of some other variable.

I define that as a crash. It may be invisible, buy nevertheless you're
off the rails.

I don't call that a crash, and I don't think most people do either.

Regardless of terminology, the distinction is an important one.
A buffer overflow doesn't necessarily result in a visible failure.

 

[Richard Tobin]

st2 doesn't have a 651st element, but this very likely *won't* cause a
crash. It's more likely to quietly write over some other piece of
memory, which may or may not be part of some other variable.

[/QUOTE]

I define that as a crash. It may be invisible, buy nevertheless you're
off the rails.

Do you have some other term for what most other people refer to as a crash?

-- Richard

 

[pete]

Do you have some other term for what most other
people refer to as a crash?

At one place that I worked, they were very particular
and used the word "frozen" to describe what I call a "crash".
If I said my computer "crashed", they'd tell me where the broom was
and if I said my computer was "locked up", they'd ask me if I had a key.

 

[Netocrat]

At one place that I worked, they were very particular
and used the word "frozen" to describe what I call a "crash".
If I said my computer "crashed", they'd tell me where the broom was
and if I said my computer was "locked up", they'd ask me if I had a key.

Did you direct them to the microwave?

 

[Old Wolf]

Coder wrote:
Patrick wrote:

st2[650] = '\0';

Same mistake here. Moreover, strncpy() does copy the ending '\0' so
there is no need for the erroneous st2[650] = '\0';

No, not always. Read FAQ.

My mistake.. I should have said that it copies the '\0' when it reaches
it at the end of the word...

It doesn't exactly do that either. When it reaches the end of the
source, it zero-fills the rest of the target buffer. If it doesn't
reach the end of the source, no zeroes get written at all.

 

[Mark McIntyre]

That's not any definition of "crash" in computer terms that I've ever
heard.

*shrug* I can't be responsible for what you've heard.

I'm wondering what your point is - do you disagree that writing over
memory not belonging to you is a Bad Thing, and that it'll most likely
cause your app to fail in some way?

 

[Mark McIntyre]

I don't call that a crash, and I don't think most people do either.

And this matters because?

Regardless of terminology, the distinction is an important one.
A buffer overflow doesn't necessarily result in a visible failure.

Sure. Your app silently crashed, and is now no longer actually
operating properly...

 

[Keith Thompson]

*shrug* I can't be responsible for what you've heard.

I'm wondering what your point is - do you disagree that writing over
memory not belonging to you is a Bad Thing, and that it'll most likely
cause your app to fail in some way?

Certainly a silent failure is bad -- typically worse than a visible
failure such the program dying wit a segmentation fault.

My point was simply that I found your use of the term "crash"
confusing. As I understand the term, if the program quietly continues
running incorrectly, it hasn't "crashed"; a "crash" is a very visible
failure. (At least one other person made the same point.)

This usage of the term is consistent with the older real-world
meaning. If I'm driving down the highway and my brakes fail, the car
is not operating correctly -- but it hasn't "crashed" until it
actually runs into something.

If everybody but me uses the term your way, I'll have to be more
careful about how I use it.

Conversely, if everybody but you uses the term my way -- well, I'll
leave the corollary to the reader.

 

[Default User]

shrug I can't be responsible for what you've heard.

I'm wondering what your point is - do you disagree that writing over
memory not belonging to you is a Bad Thing, and that it'll most likely
cause your app to fail in some way?

I'm wondering what your point is, redefining terms to something odd and
unnatural.

A crash is a crash, and a silent overwrite of memory ain't a crash. It
may lead to one down the line, but that's another tale.



Brian

 

[Alan Balmer]

And this matters because?

Because, presumably, you were trying to communicate something to the
rest of us? Else why bother posting?

 

[Mark McIntyre]

Because, presumably, you were trying to communicate something to the
rest of us? Else why bother posting?

Actually I was trying to communicate with the OP, and frankly I think
keith was being extremely anal. I assume we don't disagree that
scribbling over memory that doesn't belong to you is a Bad Thing, and
that its most likely to cause your app to start misbehaving.
Furthermore, any sensible OS would immediately complain if you did it,
and try to terminate your app. If you and others choose to apply the
word "crash" only to cases where the app visibly falls over or
generates bluescreens or whatever, thats your privilege.