Char array

[JS]

I have this struct:

int main()
{
struct jb {
char actor[25];
struct jb *next;
};
struct jb *bond;


As I understand it actor is a char array that can hold a string with 24
chars (excluding the NULL character).

But how is it then possible to write a string larger than 25 chars, like
this:
strcpy(bond->actor, "Sean Conneryhhhhhhhhhhhhhhhhhhhh");

 

[Walter Roberson]

I have this struct:

int main()
{
struct jb {
char actor[25];
struct jb *next;
};
struct jb *bond;

As I understand it actor is a char array that can hold a string with 24
chars (excluding the NULL character).

It can hold 24 characters followed by a NUL, or it could hold
25 characters with no NUL. (It is not mandatory for a NUL
to be in a character array -- but you have to be careful how
you use one that has no NUL.)

But how is it then possible to write a string larger than 25 chars, like
this:
strcpy(bond->actor, "Sean Conneryhhhhhhhhhhhhhhhhhhhh");

The same way that your car gas tank "can hold" a certain
amount of gas: the size does not prevent you from -trying- to
put too much in. If you try to put too much in, then the
rest spills out to somewhere else, with results that might not
matter or might be disasterous.

In your example, try writing a specific value into
the structure member next first, then do your extra-long
strcpy, and then examine what is in next afterwards.

 

[lndresnick]

I have this struct:

int main()
{
struct jb {
char actor[25];
struct jb *next;
};
struct jb *bond;


As I understand it actor is a char array that can hold a string with 24
chars (excluding the NULL character).

But how is it then possible to write a string larger than 25 chars, like
this:
strcpy(bond->actor, "Sean Conneryhhhhhhhhhhhhhhhhhhhh");

Writing outside the bounds of the array invokes undefined behavior.
Anything can happen. Sadly, that sometimes includes the program
seeming to function just fine. In the struct above on many platforms
there would be padding bytes between actor and next. Writing onto
those might well never have a bad effect, though it is still UB. There
are a variety of useful tools to readily detect this sort of problem
depending on what platform you are using.

In the above code, bond is never even allocated, so the bond->actor
dereference is also undefined, but perhaps all the code wasn't shown.

-David

 

[Andrey Tarasevich]

I have this struct:

int main()
{
struct jb {
char actor[25];
struct jb *next;
};
struct jb *bond;


As I understand it actor is a char array that can hold a string with 24
chars (excluding the NULL character).

Although this is pretty much correct, it is still not recommended to use
'NULL' to designate the terminating null-character. 'NULL' in C is
normally used as a null-pointer constant and has nothing to do with any
characters.

But how is it then possible to write a string larger than 25 chars, like
this:
strcpy(bond->actor, "Sean Conneryhhhhhhhhhhhhhhhhhhhh");
...

"Possible"? What exactly do you mean by this? Is it "possible" to divide
something by zero in C? Of course, one can write the code

int i = 0;
int j = 5 / i;

but nothing useful will come out of this. The same can be said about
your situation.

It is possible to perform an act of "writing" in this case, but
obviously it is not possible to fit a longer string into a 25 character
array. Formally, the behavior is undefined.

In practice, the extra characters will "stick out" of the 'actor' array.
The will either quietly overwrite the memory that immediately follows
the 'actor' array (the 'next' field in your case will get run over by
this 'strcpy' truck, and then, maybe, something else) or trigger the
platform-dependent memory-protection mechanisms, causing you program to
crash (or both).

 

[Keith Thompson]

Although this is pretty much correct, it is still not recommended to use
'NULL' to designate the terminating null-character. 'NULL' in C is
normally used as a null-pointer constant and has nothing to do with any
characters.

[...]

Using NULL to denote a null character isn't "pretty much correct".
If NULL is defined as 0, it will happen to work; if NULL is defined as
(void*)0, it won't.

 

[Andrey Tarasevich]

[...]

Although this is pretty much correct, it is still not recommended to use
'NULL' to designate the terminating null-character. 'NULL' in C is
normally used as a null-pointer constant and has nothing to do with any
characters.

[...]

Using NULL to denote a null character isn't "pretty much correct".
If NULL is defined as 0, it will happen to work; if NULL is defined as
(void*)0, it won't.

I never assumed that the use of 'NULL' in the OP's message was supposed
to refer specifically to the standard NULL macro. What he really meant
was clear to me from the context. The only problem I had with his
wording is that his use of 'NULL' can be _confused_ with the standard
NULL macro (by a hasteful reader). I viewed it as a mere readability
problem, not a technical mistake.

 

[Keith Thompson]

[...]

Although this is pretty much correct, it is still not recommended to use
'NULL' to designate the terminating null-character. 'NULL' in C is
normally used as a null-pointer constant and has nothing to do with any
characters.

[...]

Using NULL to denote a null character isn't "pretty much correct".
If NULL is defined as 0, it will happen to work; if NULL is defined as
(void*)0, it won't.

I never assumed that the use of 'NULL' in the OP's message was supposed
to refer specifically to the standard NULL macro. What he really meant
was clear to me from the context. The only problem I had with his
wording is that his use of 'NULL' can be _confused_ with the standard
NULL macro (by a hasteful reader). I viewed it as a mere readability
problem, not a technical mistake.

It was clear to me what he meant. It was also clear to me what
mistake he was making.

The word NULL in all-caps has a very specific meaning in C (a macro
that expands to a null pointer constant). Using NULL to refer to
anything else is a bad idea. The null character can be referred to as
the null character or as NUL.

Since we don't often use all-caps in English text (unless we're
shouting), any identifier in all-caps should usually be assumed to
refer to some declared C identifier (though I just noticed that this
sentence contains an exception).

I've seen code that assigns the value NULL to an element of a
character array; it happened to work on the system in question, but it
demonstrates why it's important to keep the distinction in mind.

 

[Richard Bos]

Using NULL to denote a null character isn't "pretty much correct".
If NULL is defined as 0, it will happen to work; if NULL is defined as
(void*)0, it won't.

The OP didn't write just "NULL", he wrote "the NULL character". This is
just as correct as "the NUL character": the latter is ASCII, the former
Unicode. I, too, think that this is unfortunate and confusing, but
within context it's still unambiguous. The C Standard uses the spelling
"null character", which is better.

Richard