malloc + 4??

[Kevin Torr]

http://www.yep-mm.com/res/soCrypt.c

I have 2 malloc's in my program, and when I write the contents of them to
the screen or to a file, there aren addition 4 characters.

As far as I can tell, both the code to register the malloc and to write
information into the malloc is solid. Why then ismy program returning an
additional 4 characters?

register malloc 1:
line 192

register malloc 2:
line 214

write to malloc 1:
line 200 - 205

write to malloc 2:
line 221 - 225

display malloc 2:
line 157

write malloc 2:
line 251

Here's how you execute the program:

socrypt.exe /e :i input.txt :o output.txt :A keya.txt :B keyb.txt :k
keyout.txt

**note that the input, keya, and keyb files must exist or the program will
return an error code.

If you write a text string into the input.txt file, it will write the same
string into the output.txt file plus an addition 4 characters.

The 1024 char random 'masterkey' is also written out to the keyout.txt file
with an addition 4 characters.

Why is this happening? I'm totally baffled and have spent days trying to
figure this out.

[Joona I Palaste]

Kevin Torr <ke*******@hotm ail.com> scribbled the following:

http://www.yep-mm.com/res/soCrypt.c I have 2 malloc's in my program, and when I write the contents of them to
the screen or to a file, there aren addition 4 characters. As far as I can tell, both the code to register the malloc and to write
information into the malloc is solid. Why then ismy program returning an
additional 4 characters?

The C standard says that malloc is allowed to allocate more memory than
requested.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It sure is cool having money and chicks."
- Beavis and Butt-head

[Chris Torek]

In article <40************ ***********@new s.syd.swiftdsl. com.au>
Kevin Torr <ke*******@hotm ail.com> writes:

http://www.yep-mm.com/res/soCrypt.c
In general, it is better to post the actual problematic code
(preferably after shrinking it down to a "problemati c nub", as it
were), but a URL reference can work if the one reading netnews
bothers to follow the link. :-)
I have 2 malloc's in my program, and when I write the contents of them to
the screen or to a file, there aren addition 4 characters. As far as I can tell, both the code to register the malloc and to write
information into the malloc is solid. Why then ismy program returning an
additional 4 characters?
It is not quite as solid as one might hope, although the problem
has nothing to do with malloc() per se. Here are excerpts from the
code (quoted with ">" as usual, although I had to insert the markers
myself):
// soCrypt 1.0

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
// #include <md5.h>
OK so far, although //-comments are specific to C99. You have
included necessary headers, so you will not need to cast malloc()'s
return value.
// Global variables

int statCode = 0; // Status code
int mode; // Mode variable (1 = enc, 2 = dec)
int i; // Looper variable
int inSize = 0; // Input filesize
int intRand; // Random int
char tmp_char; // Temporary char
Many of these should not be file-scope external-linkage ("global")
variables, although this is mostly a style issue (at least in a
program this small).

Note that tmp_char has type "char"; on a typical PowerPC, it would
hold values between 0 and 255 inclusive, because there plain "char"
is unsigned. The variable inSize is a plain (signed) int and has
at least the range [-32767..+32767] (although most systems, today,
have an even wider range, about +/- 2 billion).
char *pMasterKey; // Malloc pointer to the master key
char *pInputData; // Malloc pointer to the input data
Skipping forward, we have:
// Reads the input file

int readFile()
{

rewind(inFile);
i = 0;
tmp_char = 'a';
while(tmp_char != EOF)
{
i++;
tmp_char = getc(inFile);
}
inSize = i-1;
This loop tries to count the size of the file by calling getc()
until getc() returns EOF. The problem is that EOF is some sort of
negative number -- typically -1, but perhaps even -2000 or some
such -- and tmp_char is a plain "char". If tmp_char is unable to
hold the value EOF, which will be true if plain char is unsigned
or if EOF is less than CHAR_MIN (e.g., -2000 vs -128 for instance),
the loop will never terminate.

This is why getc() returns a value of type "int" in the first place,
so that it can return all possible "char"s (having first converted
any negative ones to positive values as if via "unsigned char"),
yet also return the special marker value EOF. If you want to store
both "any valid character" *and* EOF, you need something with a
wider range than "any valid character".

Of course, there is really no need for tmp_char at all, nor for
correcting for the off-by-one error produced by counting inside
the loop *before* getting a character. Just change the loop to,
e.g.:

while (getc(inFile) != EOF)
i++;

Combine this with using local variables, and perhaps a "for"
loop to collect up the initialization, test, and increment, we
might get something like:

int readFile() {
int i;

rewind(inFile);
for (i = 0; getc(inFile) != EOF; i++)
continue;
inSize = i;

(although I would also pass the "FILE *" parameter to readFile,
and probably return the allocated memory rather than an "int"
status code).
if ((pInputData = (char *)malloc(inSize * sizeof(char))) == NULL)
{
statCode = 8;
return(statCode );
}
This is OK in and of itself, but there are two important things to
note. First, the cast is not required. It does no harm, but also
does no help. It is a bit like saying "tmp_char = (char)getc(inFi le)",
when tmp_char is already a char. The assignment will do the
conversion for you -- and you do not use a cast below, so why use
one above?

Second, and the actual source of the observed problem later, note
that this allocates just enough space to store all the characters
you intend to read from the file.

Consider the C string "hello world". How many characters are in
it? How many characters does it take to *store* it? Why, after:

char hello[] = "hello world";

is there a difference of 1 between "sizeof hello" and "strlen(hello") ?

The answer is: because C strings require a '\0' marker after all
their valid "char"s. The array hello[] has size 12, not size 11,
because it stores the 11 "char"s that make up the two words and
the blank, and then one more to store the '\0' marker.

The variable inSize might (for instance) hold 5 if the file contents
are "word\n" (perhaps followed by an EOF marker, if your system
actually uses such markers in files), but if you want to use the
sequence {'w', 'o', 'r', 'd', '\n'} as a C string, you need *six*
bytes: {'w', 'o', 'r', 'd', '\n', '\0'}.

Of course, there is no requirement that you treat the file as
a C string -- that part is up to you. In any case:
rewind(inFile);
i = 0;
tmp_char = 'a';
while (i < inSize)
{
tmp_char = getc(inFile);
*(pInputData + i) = tmp_char;
i++;
}
return 0;
}
There is nothing *wrong* here, but the code can be simplified
enormously. First, tmp_char is never inspected without first
calling getc(), so there is no need to "prime the pump" -- the
loop tests "i < inSize". Second, there is no need for tmp_char
at all; you can just assign the value from getc() directly into
pInputData[i]. Third, you can write pInputData[i] that way,
rather than using the equivalent unary-"*" sequence, and again
perhaps a "for" loop might express the whole sequence better:

rewind(inFile);
for (i = 0; i < inSize; i++)
pInputData[i] = getc(inFile);
return 0;
}

Skipping forward to the source of the observed problem:
// Writes the output file

int writeFile()
{
fputs(pInputDat a, outFile);
fputs(pMasterKe y, keyOut);
return 0;
}

The fputs() function demands a string -- a sequence of "char"s
ending with a '\0' termination marker. pInputData points to the
first of a sequence of "char"s, but not one that has the "stop here
at the \0" mark in it.

Without making any other changes, you can either allocate one extra
byte and put in the '\0', or you can change the method you use to
write the final output. The two simply have to agree as to whether
pInputData (and pMasterKey -- but I did not even look at that code)
is a counted string (length inSize, for pInputData) or a C-style
'\0'-terminated string.

Note that a '\0'-terminated string cannot *contain* a '\0', so if
you want (for whatever reason) to allow embedded '\0' bytes, you
will have to choose the counted-string method. You could write
out a counted string with a loop:

int writeFile() {
int i;

for (i = 0; i < inSize; i++)
putc(pInputData[i], outFile);
/* optional:
if (fflush(outFile ) || ferror(outFile) )
... handle output failure ... */
/* and repeat for pMasterKey */
}

or you can use fwrite(), which essentially does the loop for you.
(Note that fwrite() works just fine with ordinary text, and in
fact, fputs() can be implemented internally as:

int fputs(char *s, FILE *stream) {
size_t len = strlen(s);

return fwrite(s, 1, len, stream) == len ? 0 : EOF;
}

Here strlen() looks for, but does not count, the terminating '\0',
then fwrite() loops over all the valid bytes, putc()ing each one
to the stream. The only remaining problem is that the return value
from fwrite() does not match that from fputs(), so it has to be
converted.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Kevin Torr]

"Chris Torek" <no****@torek.n et> wrote in message
news:c4******** *@news2.newsguy .com...

In article <40************ ***********@new s.syd.swiftdsl. com.au>
Kevin Torr <ke*******@hotm ail.com> writes:

http://www.yep-mm.com/res/soCrypt.c

In general, it is better to post the actual problematic code
(preferably after shrinking it down to a "problemati c nub", as it
were), but a URL reference can work if the one reading netnews
bothers to follow the link. :-)

I have 2 malloc's in my program, and when I write the contents of them to
the screen or to a file, there aren addition 4 characters.

As far as I can tell, both the code to register the malloc and to write
information into the malloc is solid. Why then ismy program returning an
additional 4 characters?

It is not quite as solid as one might hope, although the problem
has nothing to do with malloc() per se. Here are excerpts from the
code (quoted with ">" as usual, although I had to insert the markers
myself):

// soCrypt 1.0

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
// #include <md5.h>

OK so far, although //-comments are specific to C99. You have
included necessary headers, so you will not need to cast malloc()'s
return value.

// Global variables

int statCode = 0; // Status code
int mode; // Mode variable (1 = enc, 2 = dec)
int i; // Looper variable
int inSize = 0; // Input filesize
int intRand; // Random int
char tmp_char; // Temporary char

Many of these should not be file-scope external-linkage ("global")
variables, although this is mostly a style issue (at least in a
program this small).

Note that tmp_char has type "char"; on a typical PowerPC, it would
hold values between 0 and 255 inclusive, because there plain "char"
is unsigned. The variable inSize is a plain (signed) int and has
at least the range [-32767..+32767] (although most systems, today,
have an even wider range, about +/- 2 billion).

char *pMasterKey; // Malloc pointer to the master key
char *pInputData; // Malloc pointer to the input data

Skipping forward, we have:

// Reads the input file

int readFile()
{

rewind(inFile);
i = 0;
tmp_char = 'a';
while(tmp_char != EOF)
{
i++;
tmp_char = getc(inFile);
}
inSize = i-1;

This loop tries to count the size of the file by calling getc()
until getc() returns EOF. The problem is that EOF is some sort of
negative number -- typically -1, but perhaps even -2000 or some
such -- and tmp_char is a plain "char". If tmp_char is unable to
hold the value EOF, which will be true if plain char is unsigned
or if EOF is less than CHAR_MIN (e.g., -2000 vs -128 for instance),
the loop will never terminate.

This is why getc() returns a value of type "int" in the first place,
so that it can return all possible "char"s (having first converted
any negative ones to positive values as if via "unsigned char"),
yet also return the special marker value EOF. If you want to store
both "any valid character" *and* EOF, you need something with a
wider range than "any valid character".

Of course, there is really no need for tmp_char at all, nor for
correcting for the off-by-one error produced by counting inside
the loop *before* getting a character. Just change the loop to,
e.g.:

while (getc(inFile) != EOF)
i++;

Combine this with using local variables, and perhaps a "for"
loop to collect up the initialization, test, and increment, we
might get something like:

int readFile() {
int i;

rewind(inFile);
for (i = 0; getc(inFile) != EOF; i++)
continue;
inSize = i;

(although I would also pass the "FILE *" parameter to readFile,
and probably return the allocated memory rather than an "int"
status code).

if ((pInputData = (char *)malloc(inSize * sizeof(char))) == NULL)
{
statCode = 8;
return(statCode );
}

This is OK in and of itself, but there are two important things to
note. First, the cast is not required. It does no harm, but also
does no help. It is a bit like saying "tmp_char = (char)getc(inFi le)",
when tmp_char is already a char. The assignment will do the
conversion for you -- and you do not use a cast below, so why use
one above?

Second, and the actual source of the observed problem later, note
that this allocates just enough space to store all the characters
you intend to read from the file.

Consider the C string "hello world". How many characters are in
it? How many characters does it take to *store* it? Why, after:

char hello[] = "hello world";

is there a difference of 1 between "sizeof hello" and "strlen(hello") ?

The answer is: because C strings require a '\0' marker after all
their valid "char"s. The array hello[] has size 12, not size 11,
because it stores the 11 "char"s that make up the two words and
the blank, and then one more to store the '\0' marker.

The variable inSize might (for instance) hold 5 if the file contents
are "word\n" (perhaps followed by an EOF marker, if your system
actually uses such markers in files), but if you want to use the
sequence {'w', 'o', 'r', 'd', '\n'} as a C string, you need *six*
bytes: {'w', 'o', 'r', 'd', '\n', '\0'}.

Of course, there is no requirement that you treat the file as
a C string -- that part is up to you. In any case:

rewind(inFile);
i = 0;
tmp_char = 'a';
while (i < inSize)
{
tmp_char = getc(inFile);
*(pInputData + i) = tmp_char;
i++;
}
return 0;
}

There is nothing *wrong* here, but the code can be simplified
enormously. First, tmp_char is never inspected without first
calling getc(), so there is no need to "prime the pump" -- the
loop tests "i < inSize". Second, there is no need for tmp_char
at all; you can just assign the value from getc() directly into
pInputData[i]. Third, you can write pInputData[i] that way,
rather than using the equivalent unary-"*" sequence, and again
perhaps a "for" loop might express the whole sequence better:

rewind(inFile);
for (i = 0; i < inSize; i++)
pInputData[i] = getc(inFile);
return 0;
}

Skipping forward to the source of the observed problem:

// Writes the output file

int writeFile()
{
fputs(pInputDat a, outFile);
fputs(pMasterKe y, keyOut);
return 0;
}

The fputs() function demands a string -- a sequence of "char"s
ending with a '\0' termination marker. pInputData points to the
first of a sequence of "char"s, but not one that has the "stop here
at the \0" mark in it.

Without making any other changes, you can either allocate one extra
byte and put in the '\0', or you can change the method you use to
write the final output. The two simply have to agree as to whether
pInputData (and pMasterKey -- but I did not even look at that code)
is a counted string (length inSize, for pInputData) or a C-style
'\0'-terminated string.

Note that a '\0'-terminated string cannot *contain* a '\0', so if
you want (for whatever reason) to allow embedded '\0' bytes, you
will have to choose the counted-string method. You could write
out a counted string with a loop:

int writeFile() {
int i;

for (i = 0; i < inSize; i++)
putc(pInputData[i], outFile);
/* optional:
if (fflush(outFile ) || ferror(outFile) )
... handle output failure ... */
/* and repeat for pMasterKey */
}

or you can use fwrite(), which essentially does the loop for you.
(Note that fwrite() works just fine with ordinary text, and in
fact, fputs() can be implemented internally as:

int fputs(char *s, FILE *stream) {
size_t len = strlen(s);

return fwrite(s, 1, len, stream) == len ? 0 : EOF;
}

Here strlen() looks for, but does not count, the terminating '\0',
then fwrite() loops over all the valid bytes, putc()ing each one
to the stream. The only remaining problem is that the return value
from fwrite() does not match that from fputs(), so it has to be
converted.)

Wow, thanks for all that. I will have to get my head around it all.

So when do I need not cast mallocs? when I include a header? which header?
Or are you saying that I don't need to cast a malloc if I've already defined
the pointer as a data type?
What would be a possible bad thing if I did cast a malloc when I didn't need
to? Is there something that could go wrong or is it just redundant?

[John Tsiombikas (Nuclear / the Lab)]

Kevin Torr wrote:

Wow, thanks for all that. I will have to get my head around it all.

So when do I need not cast mallocs?
Never.
when I include a header? which header?

You have to include stdlib.h when you use malloc (or provide the
prototype of malloc() yourself, but i can't imagine why you would prefer
that)
--
John Tsiombikas (Nuclear / the Lab)
nu*****@siggrap h.org
http://thelab.demoscene.gr/nuclear/

[Ben Pfaff]

"John Tsiombikas (Nuclear / the Lab)" <nu*****@siggra ph.org> writes:

Kevin Torr wrote:

Wow, thanks for all that. I will have to get my head around it all.
So when do I need not cast mallocs?

Never.

Too many negatives for me. Simply stated, the return value of
malloc() rarely needs to be cast.

when I include a header? which header?

You have to include stdlib.h when you use malloc (or provide the
prototype of malloc() yourself, but i can't imagine why you would
prefer that)

Providing a prototype of malloc() yourself is arguably not valid
practice based on this sentence from the standard, section 7.1.4:

2 Provided that a library function can be declared without
reference to any type defined in a header, it is also
permissible to declare the function and use it without
including its associated header.

You can certainly declare malloc() without a type defined in a
header, but giving a prototype requires using size_t. It's
better just to use the header.
--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin

[Martin Ambuhl]

John Tsiombikas (Nuclear / the Lab) wrote:

Kevin Torr wrote:

Wow, thanks for all that. I will have to get my head around it all.

So when do I need not cast mallocs?

Never.

Actually he *always* need not cast mallocs.
What he need never do is cast mallocs.

[Dan Pop]

In <40************ *********@news. club-internet.fr> Richard Delorme <ab****@nospam. fr> writes:

Dan Pop a écrit :

In <ln************ @nuthaus.mib.or g> Keith Thompson <ks***@mib.or g> writes:

it for richness of vocabulary). I've heard that English is the only
language in which spelling bees are held (contests in which the object
is to correctly spell words after hearing them spoken).
There are such contests for French, too. The winners are usually NOT
native French speakers.

That's not true. The most popular contest is "la dictée de Pivot" also
known as "Les Dicos d'or" and the winners are usually French, but there
is a category for non native French speakers.

Obviously, a non-native French speaker cannot win at the category reserved
to native French speakers :-) I was talking about open contests.

BTW, the average native French speaker can speak French grammatically
correct, but cannot write French grammatically correct. For most verbs,
several tenses and forms are pronounced identically, but written
differently. Since they learned speaking instinctively, get it right
when speaking is trivial, while getting it right when writing requires
a solid understanding of the French grammar (otherwise, it's trivially
easy to mix up, e.g. the infinitive and past participle of most regular
verbs).

Although your last example is a common mistake, it's very easy to avoid
it for a native french speaker: just replace the verb by another one
(usually "prendre") and its pronunciation discriminates between the
infinitive and the past participle.

It doesn't matter how easy it is to avoid, what really matters is that it
is a *very* common mistake. If the written form sounds correctly, far too
many people don't bother to make the slightest effort to check that it is
the correct form.
The most difficult part of the
French grammar is the agreement of the adjectives and past participles.
In some cases, it only depends on the order of the words in the sentence.
Besides French grammar, spelling French is difficult because of the many
ways (not as much as English, though) to write the same sound and
because of the presence of mute letters (much more than English), e.g.
"saint", "sain", "sein", "seing", "ceint", "cinq" all share an identical
pronunciatio n but a different meaning.

It's not that difficult, once you get the hang of it. As a non-native
French speaker I was able to correctly spell words I was hearing for the
first time. And the context helps a lot when disambiguating between
words with identical or near identical pronunciation, just like
in English.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Alberto Giménez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 8 Apr 2004 08:33:51 GMT, Joona I Palaste escribió:

People here might know next to nothing about Finnish, but like it's
been said, Finnish is pronounced pretty much like it's written. I have
studied (at least cursorily) many languages, and I truly believe Finnish
gets the closest to a 1-1 correspondence between written glyphs and
spoken sounds.

I'm spanish, and I have to say that spanish is *exactly* pronounced as
it is written, except for "h" letter, that is not pronounced at all.

- --
Alberto Giménez, SimManiac en el IRC
http://www.almorranasozial.es.vg
GNU/Linux Debian Woody 3.0 GnuPG ID: 0x3BAABDE1
Linux registered user #290801
Windows 98 no se cuelg·$%&/# NO CARRIER
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAe9Qa0ke CtzuqveERAgKPAJ wN/1O1uFE2KwfXP8eO D+K++zQNMgCfQk3 O
ZBo2H5wau7YLtS3 ZmC+LUfU=
=olv1
-----END PGP SIGNATURE-----

[Alberto Giménez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Thu, 8 Apr 2004 11:50:17 -0400 (EDT), Arthur J. O'Dwyer escribió:

in Spanish pronunciation are what happens to 'c[aou]' versus 'c[ei]' and
'gu[ao]' versus 'gu[ei]'. But I'm a little out of it, so maybe I missed

yes, i forgot that in my last post :)
hm, i could add "r" versus "rr", but i don't think it is a
pronounciation "peculiarit y", and with qu[ei], where u is not pronounced
(in spanish no word is written with "qua" or "quo") :)

- --
Alberto Giménez, SimManiac en el IRC
http://www.almorranasozial.es.vg
GNU/Linux Debian Woody 3.0 GnuPG ID: 0x3BAABDE1
Linux registered user #290801
Windows 98 no se cuelg·$%&/# NO CARRIER
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAe9UD0ke CtzuqveERAqFiAJ 9d03tx0rF+ewWTZ L2vwMb7y1HPfwCd EXln
yjzYZb/1TY3ctvowwN/FqQI=
=qK14
-----END PGP SIGNATURE-----