-=> On 09 Dec 97  10:12:04 you wrote to me <=-
Hi George,
Sorry, I couldn't be bothered trying to fix this horrible mess of
quotes. I hope you can work it all out. :)
MS>BLM> strncpy() was not appending a closing null as long as the string
MS>BLM> was longer than LABEL_MAX.  Here's how I decided to fix that...
MS>BLM> /* copy s2 to s1 truncating at n characters */
MS>BLM> char* strntrnc(char *s1, const char *s2, int n)
GW> MS>Names beginning with str... are reserved.
GW> That's news to me! I know single underscore at the start of an
GW> identifier is reserved, and double underscore at start and and of
GW> #defines. I wasn't aware of any reservation of any other prefix (for
GW> want of any better term) characters or character strings.
I see that Bob & Auke have set you straight on this point. :)
MS>BLM> {
MS>BLM>     char *old_s;
MS>BLM>     old_s = s1;
MS>BLM>     while( (n-- > 0) )
MS>BLM>       if(!(*s1++ = *s2++)) break;
MS>BLM>    *s1 = 0;
MS>BLM>     return old_s;
MS>BLM> }
MS>GW> You'd be better not using old_s at all, just return s1.
GW> MS>It *is* ok to return old_s, because it points to an object (the old
GW> MS>s1) that will still be in scope when the function ends.  It is no
GW> MS>more dangerous than returning s1 or s2.
GW> MS>FWIW, I'd return s1 to simplify string concatenation.
GW> He is returning s1 (the entry value of it).
How would that simplify string concatenation? I was suggesting to
return the final value of s1.
MS>GW> Reason:  old_s is an "automatic" variable which is created in
MS>GW> the stack frame for the function.  Once you have returned from
MS>GW> the function the stack frame is discarded and becomes "invalid".
MS>GW> If it is tested/assigned immediately after the return from the
MS>GW> function it is (normally) still valid, but thereafter there is
MS>GW> no guarantee...
GW> MS>The return value is not part of the stack frame for the function. As
GW> MS>I mentioned above, this return value is the address of an object
GW> MS>that is external to strntrnc() & it will be quite valid in the
GW> MS>calling function.
GW> The variable containing it is part of the stack frame though.
Yes, so what? In C all arguments are passed by value. Meditate
deeply on this and you will acheive enlightenment. :)
GW> I agree it is OK in this case. I'm always wary of returned automatic
GW> pointers to data because it is very easy to inadvertantly return them
GW> pointing to automatic data which then goes out of scope.
I see what you're saying, OTOH, a programmer should always know the
scope of data that is being pointed at, so I don't think this
objection is very valid.
MS>GW> If you must return a local variable by reference from a routine
MS>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
MS>GW> make it a "static" variable which will cause it to be in the
MS>GW> main variable pool and be available at all times.
GW> MS>The value of old_s is being returned, not it's address.
GW> That was a general comment, not intended on the code being considered.
A general comment based on faulty assumptions can be very dangerous.
Pointers should be treated with caution, not paranoia.  :)
GW> Given that limitation I agree with what you say.
Fine. :)
MS>BLM> Now I just use strntrnc() where I was using strncpy().
MS>GW> Good idea...
MS>GW> An alternative is to just force a terminator in the last valid
MS>GW> position of the source string, and then use strcpy(), if the
MS>GW> string is shorter than the max it will just be copied, otherwise
MS>GW> the added terminator does the job for you.  This, however, is a
MS>GW> matter of personal style.
MS>BLM> char* strntrnc(char *s1, const char *s2, int n)
GW> MS>You can't do this because the source string is const, but I won't
GW> MS>hassle you over this because I see that Darren had a few things to
GW> MS>say to you in this regard.  :)
GW> It is an _alternative_, as I said originally, which is worth
GW> remembering. I trust readers will have sufficient sense to determine the
GW> circumstances where it is appropriate.
Fair enough, OTOH, that goes against the spirit of modular
programming since you can't treat such a function like a black box.
GW> I _totally_ agree it cannot be used on constant strings under any
GW> civilised protected mode OS (after all I use them), but for truncating
GW> dynamic data where the rest of the data is redundant it is quite
GW> appropriate.
True, if the string is yours to command, you can do anything you
like with it, although don't forget what I said above about black
boxes.
GW> MS>Also, it is generally considered very bad form for a function to
GW> MS>alter its input data, especially when there is no valid reason for
GW> MS>doing so.  ;) The only case in the C Standard library of a function
GW> MS>which does alter its input data is stptok(), and many people think
GW> MS>that it really ought to make it's own internal copy of the string
GW> MS>that it's stepping through, rather than writing NULs over the input.
GW> I agree. It's like "goto", however there are a few times when it
GW> simplifies program design to do so.
Definitely! I certainly can't say that I've never done it. :)
GW> I don't think it should ever be done in library routines though.
Indeed, but tell that to the designers of stptok()... :)
Michael Stapleton of Graphic Bits.
 * AmyBW v2.10 *
... This tagline is encrypted
--- AdeptXBBS v1.11z (FREEWare/2)
---------------