malloc + 4??

**Joona I Palaste** · Nov 14 '05, 05:29 AM

Re: malloc + 4??

Kevin Torr <kevintorr@hotm ail.com> scribbled the following:[color=blue]
> http://www.yep-mm.com/res/soCrypt.c[/color]
[color=blue]
> 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.[/color]
[color=blue]
> 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?[/color]

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

--
/-- Joona Palaste (palaste@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** · Nov 14 '05, 05:29 AM

Re: malloc + 4??

In article <4070182a$0$276 45$61ce578d@new s.syd.swiftdsl. com.au>
Kevin Torr <kevintorr@hotm ail.com> writes:[color=blue]
>http://www.yep-mm.com/res/soCrypt.c[/color]

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. :-)
[color=blue]
>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.[/color]
[color=blue]
>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?[/color]

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):
[color=blue]
>// soCrypt 1.0
>
>#include <stdio.h>
>#include <stdlib.h>
>#include <string.h>
>#include <time.h>
>// #include <md5.h>[/color]

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.
[color=blue]
>// 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[/color]

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).
[color=blue]
>char *pMasterKey; // Malloc pointer to the master key
>char *pInputData; // Malloc pointer to the input data[/color]

Skipping forward, we have:
[color=blue]
>// 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;[/color]

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).
[color=blue]
> if ((pInputData = (char *)malloc(inSize * sizeof(char))) == NULL)
> {
> statCode = 8;
> return(statCode );
> }[/color]

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:
[color=blue]
> rewind(inFile);
> i = 0;
> tmp_char = 'a';
> while (i < inSize)
> {
> tmp_char = getc(inFile);
> *(pInputData + i) = tmp_char;
> i++;
> }
> return 0;
>}[/color]

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:
[color=blue]
>// Writes the output file
>
>int writeFile()
>{
> fputs(pInputDat a, outFile);
> fputs(pMasterKe y, keyOut);
> return 0;
>}[/color]

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) +1 801 277 2603
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** · Nov 14 '05, 05:30 AM

Re: malloc + 4??

"Chris Torek" <nospam@torek.n et> wrote in message
news:c4pdra031g a@news2.newsguy .com...[color=blue]
> In article <4070182a$0$276 45$61ce578d@new s.syd.swiftdsl. com.au>
> Kevin Torr <kevintorr@hotm ail.com> writes:[color=green]
> >http://www.yep-mm.com/res/soCrypt.c[/color]
>
> 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. :-)
>[color=green]
> >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.[/color]
>[color=green]
> >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?[/color]
>
> 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):
>[color=green]
> >// soCrypt 1.0
> >
> >#include <stdio.h>
> >#include <stdlib.h>
> >#include <string.h>
> >#include <time.h>
> >// #include <md5.h>[/color]
>
> 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.
>[color=green]
> >// 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[/color]
>
> 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).
>[color=green]
> >char *pMasterKey; // Malloc pointer to the master key
> >char *pInputData; // Malloc pointer to the input data[/color]
>
> Skipping forward, we have:
>[color=green]
> >// 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;[/color]
>
> 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).
>[color=green]
> > if ((pInputData = (char *)malloc(inSize * sizeof(char))) == NULL)
> > {
> > statCode = 8;
> > return(statCode );
> > }[/color]
>
> 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:
>[color=green]
> > rewind(inFile);
> > i = 0;
> > tmp_char = 'a';
> > while (i < inSize)
> > {
> > tmp_char = getc(inFile);
> > *(pInputData + i) = tmp_char;
> > i++;
> > }
> > return 0;
> >}[/color]
>
> 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:
>[color=green]
> >// Writes the output file
> >
> >int writeFile()
> >{
> > fputs(pInputDat a, outFile);
> > fputs(pMasterKe y, keyOut);
> > return 0;
> >}[/color]
>
> 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.)[/color]

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)** · Nov 14 '05, 05:30 AM

Re: malloc + 4??

Kevin Torr wrote:[color=blue]
> Wow, thanks for all that. I will have to get my head around it all.
>
> So when do I need not cast mallocs?[/color]

Never.
[color=blue]
> when I include a header? which header?[/color]

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)
nuclear@siggrap h.org

John Tsiombikas web site

http://thelab.demoscene.gr/nuclear/

**Ben Pfaff** · Nov 14 '05, 05:30 AM

Re: malloc + 4??

"John Tsiombikas (Nuclear / the Lab)" <nuclear@siggra ph.org> writes:
[color=blue]
> Kevin Torr wrote:[color=green]
>> Wow, thanks for all that. I will have to get my head around it all.
>> So when do I need not cast mallocs?[/color]
>
> Never.[/color]

Too many negatives for me. Simply stated, the return value of
malloc() rarely needs to be cast.
[color=blue][color=green]
>> when I include a header? which header?[/color]
>
> 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)[/color]

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** · Nov 14 '05, 05:30 AM

Re: malloc + 4??

John Tsiombikas (Nuclear / the Lab) wrote:[color=blue]
> Kevin Torr wrote:
>[color=green]
>> Wow, thanks for all that. I will have to get my head around it all.
>>
>> So when do I need not cast mallocs?[/color]
>
>
> Never.[/color]

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

**Dan Pop** · Nov 14 '05, 05:30 AM

Re: malloc + 4??

In <4075c834$0$296 $7a628cd7@news. club-internet.fr> Richard Delorme <abulmo@nospam. fr> writes:
[color=blue]
>Dan Pop a écrit :[color=green]
>> In <ln65cbi73x.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:
>>[color=darkred]
>>>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).[/color]
>>
>> There are such contests for French, too. The winners are usually NOT
>> native French speakers.[/color]
>
>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.[/color]

Obviously, a non-native French speaker cannot win at the category reserved
to native French speakers :-) I was talking about open contests.
[color=blue][color=green]
>> 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).[/color]
>
>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.[/color]

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.
[color=blue]
>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.[/color]

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: Dan.Pop@ifh.de

**Alberto Giménez** · Nov 14 '05, 05:30 AM

Re: malloc + 4??

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

El 8 Apr 2004 08:33:51 GMT, Joona I Palaste escribió:[color=blue]
> 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.[/color]

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** · Nov 14 '05, 05:30 AM

Re: malloc + 4??

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

El Thu, 8 Apr 2004 11:50:17 -0400 (EDT), Arthur J. O'Dwyer escribió:[color=blue]
> 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[/color]

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-----

**John Tsiombikas (Nuclear / the Lab)** · Nov 14 '05, 05:30 AM

Re: malloc + 4??

Martin Ambuhl wrote:[color=blue]
>
> John Tsiombikas (Nuclear / the Lab) wrote:
>[color=green]
>> Kevin Torr wrote:[color=darkred]
>>> So when do I need not cast mallocs?[/color]
>>
>> Never.[/color]
>
>
> Actually he *always* need not cast mallocs.
> What he need never do is cast mallocs.[/color]

Hm, it seems I missed the *not* in there, for some obscure reason I
thought that he asked "So when do I need to cast mallocs?". :)))

--
John Tsiombikas (Nuclear / the Lab)
nuclear@siggrap h.org

John Tsiombikas web site

http://thelab.demoscene.gr/nuclear/

**Joona I Palaste** · Nov 14 '05, 05:30 AM

Re: malloc + 4??

Alberto Giménez <algibe@telelin e.es> scribbled the following:[color=blue]
> El 8 Apr 2004 08:33:51 GMT, Joona I Palaste escribió:[color=green]
>> 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.[/color][/color]
[color=blue]
> 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.[/color]

Close, but no cigar. Some minor points: Why is the 'u' in "qu"
pronounced differently than the normal 'u'? (For example "una
quilogramme".) Why do 'l' by itself and "ll" have separate
pronunciations? (I don't know how the "ll" is pronounced correctly,
but I think I know it's *not* pronounced as two 'l' sounds.)
Why can 'y' be both a consonant (like in "yo") and a vowel (like in
"hay")?
I suppose 'j' in Spanish is always pronounced like 'h' in English.
Fair enough, but seeing as it's pronounced in Finnish like the
consonant 'y' in English and Spanish, it strikes me as a little weird.

--
/-- Joona Palaste (palaste@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It was, er, quite bookish."
- Horace Boothroyd

**John Tsiombikas (Nuclear / the Lab)** · Nov 14 '05, 05:30 AM

Re: malloc + 4??

Ben Pfaff wrote:[color=blue][color=green][color=darkred]
>>>when I include a header? which header?[/color]
>>
>>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 to do that)[/color]
>
> 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.[/color]

So are you saying that you can't do the following?

#include <stddef.h> /* for size_t */
void *malloc(size_t) ;

this is providing a prototype for malloc, without including stdlib.h and
yes ofcourse it's better to just use the header, I just added that
comment for completeness, if I may quote myself :)
"or provide the prototype of malloc() yourself, but i can't imagine why
you would prefer to do that"

--
John Tsiombikas (Nuclear / the Lab)
nuclear@siggrap h.org

John Tsiombikas web site

http://thelab.demoscene.gr/nuclear/

**Ben Pfaff** · Nov 14 '05, 05:30 AM

Re: malloc + 4??

"John Tsiombikas (Nuclear / the Lab)" <nuclear@siggra ph.org> writes:
[color=blue]
> Ben Pfaff wrote:[color=green][color=darkred]
>>>>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 to do that)[/color]
>> 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.[/color]
>
> So are you saying that you can't do the following?
>
> #include <stddef.h> /* for size_t */
> void *malloc(size_t) ;
>
> this is providing a prototype for malloc, without including stdlib.h[/color]

You got size_t from a header, which seems to fall afoul of the
spirit of the provision above. Whether it is actually undefined
behavior would be better judged in comp.std.c. But it is better
in any case to simply include <stdlib.h>.
--
"We put [the best] Assembler programmers in a little glass case in the hallway
near the Exit sign. The sign on the case says, `In case of optimization
problem, break glass.' Meanwhile, the problem solvers are busy doing their
work in languages most appropriate to the job at hand." --Richard Riehle

**Arthur J. O'Dwyer** · Nov 14 '05, 05:30 AM

[OT] Re: malloc + 4??

On Tue, 13 Apr 2004, Joona I Palaste wrote:[color=blue]
>
> Alberto Giménez <algibe@telelin e.es> scribbled the following:[color=green]
> > El 8 Apr 2004 08:33:51 GMT, Joona I Palaste escribió:[color=darkred]
> >> 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.[/color]
> >
> > 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.[/color]
>
> Close, but no cigar. Some minor points: Why is the 'u' in "qu"
> pronounced differently than the normal 'u'? (For example "una
> quilogramme".)[/color]

Is this correct in some Spanish dialect with which I'm unfamiliar?
I thought the word for "kilogram" in Spanish was... well.. "kilogramo. "
Certainly the "gramme" ending in Joona's word isn't Spanish; Spanish
doesn't double consonants. Looks like a weird Ibero-British hybrid
to me. :)
(After Googling: is this something like Catalan?)
[color=blue]
> Why do 'l' by itself and "ll" have separate
> pronunciations? (I don't know how the "ll" is pronounced correctly,
> but I think I know it's *not* pronounced as two 'l' sounds.)[/color]

The two-'l' letter is the "elle" (pronounced roughly like the
English letter "A": "A-yay"). In words, it's pronounced like the
English 'y': "me llamo" -> "may yamo". And perfectly regularly so.

Spanish used to consider both the 'll' and the 'ch' to be letters
in their own right, along with the enye (n+tilde; sorry, not in my
encoding). But IIRC recently the Spanish people in charge of the
"official" language decided to give up the separate letters for 'ch'
and 'll', and now you'll find "llama" in between "liviano" and "local"
in the dictionary.
[color=blue]
> Why can 'y' be both a consonant (like in "yo") and a vowel (like in
> "hay")?[/color]

I'd say, because Spanish doesn't consider 'y' either a consonant or
a vowel, just as in English. The 'y' sound is kind of in-between.
In any event, the 'y' in "yo" isn't really acting like a consonant:
it's just adding the extra "ee" sort of sound. Just like it's doing
in "hay," which without the 'y' would be pronounced "ahh." With the
'y', it's pronounced "ahh-ee," but run together into "ai."

[It's weird trying to write down phonetic descriptions in "English"
syllables, when we're talking about a *more* phonetic language in the
first place, and I know English isn't your first language in the second
place. ;) ]
[color=blue]
> I suppose 'j' in Spanish is always pronounced like 'h' in English.[/color]

Correct, AFAIK.
[color=blue]
> Fair enough, but seeing as it's pronounced in Finnish like the
> consonant 'y' in English and Spanish, it strikes me as a little weird.[/color]

Sounds to me like *Finnish* is the weird one. ;-))

-Arthur