* Reply to a message in personal_mail.

George White wrote in a message to Tom Torfs:

 GW> I feel the wording "new operator" can be a little confusing as the
 GW> close relative to C (C++) has a "new" operator. Perhaps replacing
 GW> "new operator" by "another operator" in both
cases is less likely
 GW> to lead to any confusion. 

Fixed.

 GW> [*] Some compilers also support a "t" for text files, but since
 GW> this is non-standard and not required you shouldn't use it.

 GW> This is difficult

I've added the reason why it is not required (it is the default).

 GW> The fact that the default open mode can be set by changing the
 GW> value of the global variable _fmode (default setting in stdio.h)
 GW> makes it especially problematic and means that great care should be
 GW> taken when using any compiler that supports the language extension.

No "great care" required... just a little common sense, i.e.
don't turn on compiler options that will break your compiler. It's a
standard C tutorial, after all.

 GW> int rename(const char *old, const char *new);

 GW> Again this may be less confusing if you changed "old" and
"new" to
 GW> "oldname" and "newname" (again because of the
existance of "new" in
 GW> C++). 

In this context, there's no confusion possible (not "new
operator" here). I'm teaching C, not C++ :-)

 GW> Another thought (on strings).
 GW> I'm not sure of how to word it, but I feel the warning about access
 GW> to array elements (only from the start to one after the end) needs
 GW> to be strengthened for string operations. The dangers of the
 GW> str...() functions over-writing memory if the destination buffers
 GW> are not large enough to contain the source data, especially with
 GW> strcat(), cannot be over emphasised for programmers coming from
 GW> languages where they are protected from this type of problem. It is
 GW> especially easy to declare a string pointer and then strcpy() to it
 GW> without a malloc() to create the space, and it is difficult to see
 GW> the cause of any resultant problems. This of course also applies to
 GW> memcpy()/memmove()/memset() as well. 

OK, added to todo list.

 GW> Robin Sheppard has already pointed out the only other thing I've
 GW> spotted (the "while (i" error).

That was actually an error in my HTML-to-text conversion program.

greetings,
Tom
tomtorfs{at}village.uunet.be

--- timEd/2 1.10+