On Sat, 2007-12-22 at 23:20 -0700, Thomas Hruska wrote:
> Christopher Carver wrote:
> > I think I'm straight forward and I find to many cooks in the kitchen
> > arguing what to call s spoon, that they forget to make the soup.
> Call it
> > half a dozen or six and it's the same thing.
> > 
> > For the original poster, strings in C and strings in C++ can be
> > different depending on who and what train of thinking they have and
> what
> > context the two are talking about. But basically it's nothing more
> than
> > a series of bytes with a terminating character at the end. That's
> not
> > 100% true all the time, but usually the case.
> 
> Wrong. I don't use null-terminators for in-memory data storage. I 
> haven't done that for almost a decade (since 1998). Using a special 
> character to signify the end of a chunk of data was and still is one
> of 
> the worst ideas _ever_. That alone has caused WAY more problems
> (buffer 
> overflows, etc.) than I care to count.
> 

I quote:

A byte with all bits set to 0, called the null character, shall exist in
the basic execution character set; it is used to terminate a character
string literal.
- ANSI/ISO 9899:1990 (the ANSI C standard), section 5.2.1

A string is a contiguous sequence of characters terminated by and
including the first null character.
- ANSI/ISO 9899:1990 (the ANSI C standard), section 7.1.1

It's not the worst idea ever, because without a null termination
character you are forced to use a storage data type to specify the
length of the data. If the data length is beyond that of the storage
data can hold, the code behavior will become unknown or the coder has to
compensate. Buffer overflows is writing past the allocated storage and
has nothing to do with null terminators. If a coder doesn't compensate
for the null termination, then that's the coders fault, not the
methodology. If you don't use null terminators, then I can safety assume
you just use C++ strings. And that's great, but don't disparage C as a
lessor extent. 

The poster needed away to copy one string to another without the use of
strcpy() functions, so we are talking about ANSI-C strings; though K&R
strings are the exact same; hence a null terminator. I provided helpful
information without giving a blatant answer or a canned non-helpful
response. I think most folks can Google or go to bookstores. Giving some
actual helpful pointers (haha, pointers) is not only more helpful, but
friendlier than cut and paste canned responses.

> > In context to the question initially posted a string, character
> array,
> > buffer, etc. etc. all mean the same thing, they just different ways
> to
> > get to the same thing. There are those that would like to polish
> their
> > word smithing and say otherwise.
> > 
> > If you are serious about learning about pointers then I suggest a
> book
> > called Understanding Pointers in C by Yashavant P. Kanetkar. Though
> it
> > might be a hard book to find. I picked it up when I was in India.
> > 
> > -- Chris
> 
> Yashavant Kanetkar may have an easy-to-understand style of writing,
> BUT 
> he is a non-ANSI Standard author. If you watch this list, you'll
> notice 
> the following bit of canned response show up when I reply to a "I'm 
> looking for a good book" question:
> 
> -----
> Beware any C/C++ author who does not adhere closely to the ANSI C/C++ 
> Standard. One very popular author is Yashavant Kanetkar who is the 
> author of "Let Us C". His writing may be simple to understand however 
> his code is non-ANSI Standard. Similar great writers have shown up
> over 
> the years who tell wonderful stories but don't adhere to the
> Standards 
> defined by the ANSI C/C++ committees.
> -----
> 
> I've personally contacted Yashavant and he pretty much flat out
> refused 
> to look at the ANSI C/C++ Standard - the document on which all
> compliant 
> compilers AND book authors rely - to author his books in compliance
> of. 
> His books may be easy to read but he is definitely an author to
> avoid. 
> The other major author to avoid like the plague is Schildt. 
> Unfortunately, the latter hasn't done _nearly_ as much damage as 
> Yashavant has - and Yashavant is a relatively recent author. Please
> do 
> not recommend either author. c-prog doesn't enjoy doing damage
> control.
> 

The "Understanding Pointers In C" by Yashavant is all standard C
operations, so it will run on all C compilers on any platform. Show me a
snippet from the book I mention that does not work on any platform or
compiler. The same rules apply from C89 to C99 compliant compilers. I
can not comment on his other works. But this is an excellent book that
takes great care in explaining and showing all the different aspects of
memory handling. Far more than most C books and far greater than most C
++ books will ever tread. 

After reading your response, I know you have not read this book.

> -- 
> Thomas Hruska
> CubicleSoft President
> Ph: 517-803-4197
> 
> *NEW* MyTaskFocus 1.1
> Get on task. Stay on task.
> 
> http://www.CubicleSoft.com/MyTaskFocus/
> 
> 
> 
> 
>  

Reply via email to