• C

C: strncpy() and terminating NULL

Hello,

I have the following: (line numbers inserted for clarity)

1. char buff[12], another_buff[12];
2. char something[[100];

// the buffer SOMETHING contains text read in via fgets()

3. setmem(buff, sizeof(buff), 0);
4. strncpy(buff, something, 11);
5. buff[11] = '\0';

So far so good. I guard against a buffer overrrun per BUFF by setting the terminating NULL.
So, BUFF might contain "ABCDEFGHIJK". (which is 11 characters)

Now right after the above,, we have

6. if (buff[0] == 'E') // error conditon, meaning the data starts in something[1]
7.     strncpy(buff, something+1, 11);
        // but years ago whoever wrote this did NOT re-set the terminating NULL.

Are we OK here? In other words, will buff[11] still be NULL per setting it in line 5 above?

so that if I do

strcpy(another_buff, buff, 11);

I won't overrun ANOTHER_BUFF since BUFF will still be properly NULL-terminated?

Thanks!
Steve
LVL 4
Stephen KairysTechnical Writer - ConsultantAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

mccarlIT Business Systems Analyst / Software DeveloperCommented:
Are we OK here? In other words, will buff[11] still be NULL per setting it in line 5 above?
Yes, buff[11] will still be NULL (or 0). Why? Because the strncpy call on line 7 will only copy a max of 11 chars (ie. it will only fill in locations from buff[0] -> buff[10]) and so buff[11] is left untouched.

As an aside, setting buff[11] to be NULL on line 5 is unnecessary for the very same reason above. The strncpy call on line 4 will also only fill locations buff[0] -> buff[10] and so buff[11] will still be NULL (or 0) as set in the setmem call on line 3.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Stephen KairysTechnical Writer - ConsultantAuthor Commented:
Hello again andt hank you.  I was maybe 75% sure that this was OK but 75% was not enough for me :)...this fragment is in a program that updates critical data, and if it crashes, that data might be compromised.

As an aside, the need to take the precautions like setmem() or nulling out buff[11] is why I hate strncpy(). It baffles me why it does not do like strcpy() does and append a terminating NULL.

Thanks again, and have a good evening.
-Steve
0
mccarlIT Business Systems Analyst / Software DeveloperCommented:
It baffles me why it does not do like strcpy() does and append a terminating NULL.
The reason is that it's original use was not to be a "safe" version of strcpy. It was to be able to easily fill in fixed-width fields in a memory record structure. If you have a 1000 byte region of memory that represents one record of a database (as an example), and that record contains 100 fields that are all 10 chars wide, if you wanted to have null-terminated strings you would need an additional 10% of memory to hold this. (And back in the day, memory was more expensive than it is now)  You don't NEED to have null-terminated strings if by definition you know that each field can only be a max of 10 chars. The function of strncpy then was to be able to copy an arbitrarily long string into this fixed width field but truncate it to 10 chars if it was longer than that. Also strncpy pads out the 10 chars with NULL's if the input string is less than 10 chars long, as this IS necessary so that one can determine if the string in the field IS less than 10 chars.

I hope all the makes sense... And thanks for accepting! :)
0
Stephen KairysTechnical Writer - ConsultantAuthor Commented:
Very intersting...yeah C dates back a long way.  Oh for the good old days/ Not sure I think so! :)

Thanks again.
-Steve
0
mccarlIT Business Systems Analyst / Software DeveloperCommented:
:)  I'm am pretty much 100% Java these days.... and not really looking back!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C

From novice to tech pro — start learning today.