Hi Tom,

You wrote to Dave Kelly:

TT> DK> Some FIDO gate/interface is chopping off the tail of your
TT> DK> messages at between 479 lines and 626 lines. At least that
TT> DK> was the case on their way to zone 1:106.
TT> DK> Only the first message about the announcement of the next
TT> DK> 8 messages had a tagline.
TT> DK> Would you be willing to repost them in smaller portions?

TT>Many changes have been made and the documents are getting larger, so
TT>reposting every time would not be appropriate for the echo.
TT>Make sure you fetch the latest version at
TT>http://bewoner.dma.be/tomtorfs/c/. If you don't have web
TT>access, let me know and I'll email or netmail it to you
TT>(the same goes for everyone else with this problem).

I suspect the problem is his mail reader rather than FIDO transfers.
Some readers (SLMR for example) will onlt display a limited length of a
message, the rest gets chopped off even if it is in the .qwk packet.
However, that leads me to my first plea - the .qwk mail packet is
limited to 25 character subject lines, could you ensure any future multi
part postings contain the part no and number of parts within the first
25 (and preferably 24 to account for some broken .qwk packers)
characters of the subject line (all I get through the .qwk door as a
subject is "An introduction to C, par").

Now to comments on the tutorial (they are nit picking - I think you have
done a marvelous job overall).

Comment 1)

You have:

However, instead of using the arrayname a to get the address of the array,
an element index is used (0 resp. 4) between the [ ], and a new operator is
............................................................^^^^^^^^^^^^
prepended: the address operator (&). Putting & before something takes the
address of that something (when that something has an address of course;
something like &5 will not work since the constant 5 doesn't have an
address in memory). So &variable takes the address of the variable, and
&arrayname[indexnumber] takes the address of an element of an array.

and again:

Ah, a new operator. The * is called the dereference operator [*]. To
......^^^^^^^^^^^^
dereference a pointer means to take the value of the variable to which
the pointer is pointing. So *p means the value of the int that p
is pointing at (i.o.w. whose address value p contains).

My thoughts:

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

Comment 2)

You have:

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

My thoughts:

This is difficult, I feel some expansion on the use of "t" by some
compilers is probably in order because it is an extension provided
by the Microsoft compiler and supported by many other PC platform
compilers for compatibility with the Microsoft compiler.
The fact that the default open mode can be set by changing the value
of the global variable _fmode (default setting in stdio.h) makes it
especially problematic and means that great care should be taken when
using any compiler that supports the language extension.

Comment 3)

You have:

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

Changes the name of the specified file from the string
pointed to by old to that pointed to by new.  Whether
a file by the latter name is allowed to exist already
depends on your system. Returns 0 when successful, nonzero
otherwise.

My thoughts:

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

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

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

George

 * SLMR 2.1a * Computers eliminate spare time.

--- Maximus/2 3.01