malloc

[Bill Cunningham]

I have never seen anyone declare anything of type size_t to pass to
malloc but I have an example here. I used lcc this times and it had fits
with this code.

#include <stdio.h>
#include <stdlib.h>

main() {
char *man;
man=malloc(sizeof man);
free(man);}
Warning p.c: 4 no type specified. Defaulting to int
Error p.c: 7 found 'pointer to char' expected a function
Warning p.c: 7 missing prototype
Error p.c: 7 illegal expression
Error p.c: 7 syntax error; found `}' expecting ')'
Error p.c: 7 type error in argument 1 to `free'; found 'void' expected
'pointer to void'
Error p.c: 7 syntax error; found `}' expecting ')'
Error p.c: 7 Syntax error; missing semicolon before `}'

 

[Bill Cunningham]

I don't believe you. That is, I don't believe that what you've posted
is the same code that produced this diagnostic message.

Here's another copy that could've produced those errors as there were
two versions maybe I forgot to change error codes.

main()
{
char *man;
man=malloc(man(;
free(man);
return 0;
}

Therewas a right parenthesis turned around.

Bill

 

[Bill Cunningham]

Bill, you have been told over and over that you should include the
complete source, including headers. I will make no further comment on
any program you post here that excludes vital parts of the program
(such as headers).

Oops. Here's the complete source.

#include <stdio.h>
#include <stdlib.h> /*for malloc */

main()
{
char *man;
man=malloc(man(;
return 0;
}

I've never put *man in the parameter that malloc takes.

Bill

 

[Keith Thompson]

Oops. Here's the complete source.

#include <stdio.h>
#include <stdlib.h> /*for malloc */

main()
{
char *man;
man=malloc(man(;
return 0;
}

I've never put *man in the parameter that malloc takes.

Ok. You know this source is wrong. At the very least, you have a '('
where you should have a ')'. (And no, that's definitely not the only
problem.) What do you expect us to say about it that your compiler hasn't
already told you?

(A minor point: Please write "int main(void)" rather than "main()".)

You've seen plenty of correct calls to malloc, even, if I'm not
mistaken, in this thread. You have all the information you need to
call it correctly. You know, or should know, what type malloc expects
for its argument. You know, or should know, what that argument means.
You can certainly write something that compiles, even if it doesn't
actually work, so don't waste our time posting something that doesn't
compile.

If you write either malloc(man) or malloc(*man), then you're obviously
just guessing. Don't do that. The path to correct code is not to
type some random garbage and then make incremental changes until it
works; it's to figure out what you want to do, figure out how to do
it, and then do it. Mistakes will happen along the way, but if you
start with something that's obviously wrong you're far less likely to
produce something right.

It would have been far easier for me to write the correct code for
you, but that wouldn't help you to do it yourself.

RTFM (Read The F(ine) Manual). If you still have questions, come back
and ask them.

 

[Nick Keighley]

    I have never seen anyone declare anything of type size_t to pass to
malloc but I have an example here. I used lcc this times and it had fits
with this code.

    #include <stdio.h>
#include <stdlib.h>

main() {
        char *man;
        man=malloc(sizeof man);
        free(man);}
Warning p.c: 4  no type specified. Defaulting to int
Error p.c: 7  found 'pointer to char' expected a function
Warning p.c: 7  missing prototype
Error p.c: 7  illegal expression
Error p.c: 7  syntax error; found `}' expecting ')'
Error p.c: 7  type error in argument 1 to `free'; found 'void' expected
'pointer to void'
Error p.c: 7  syntax error; found `}' expecting ')'
Error p.c: 7  Syntax error; missing semicolon before  `}'

post the actual code you compiled

 

[Nick Keighley]

    Here's another copy that could've produced those errors as there were
two versions maybe I forgot to change error codes.

main()
{
    char *man;
    man=malloc(man(;
    free(man);
    return 0;

}

Therewas a right parenthesis turned around.

post the actual code you compiled

you are violating rule 1


0. fix your layout
1. post your code
2. post your input data
3. post your output
4. explain why you don't like 3
5. check return values
6. RTFM
7. don't guess (see 6)

 

[Mark Bluemel]

You have to bet taking the piss here surely? You don't believe this is
for real? And if it IS real that there is any point whatsoever going
over this with Bill again and again?

My feelings exactly. If he's a troll we shouldn't feed him. If he's
not, then he's (unfortunately) clearly beyond any help we can offer.

 

[Nick Keighley]

Why do you insist on posting what has already been posted? Did you not
see Keith and Heathfield already demand this? What thrill do you get
copying them? Chuck was famous for this. You want to inherit his mantel?

if it's a marble one, yes please!

 

[Bill Cunningham]

post the actual code you compiled

I will try again. This is only the 3rd time I've used lcc. I'm not
familiar with it's warnings at all though they should be pretty much the
same as gcc. I will try and work this out myself and if I have a problem
then come back as has been suggested.

Bill

 

[Default User]

My feelings exactly. If he's a troll we shouldn't feed him. If he's
not, then he's (unfortunately) clearly beyond any help we can offer.

Sheesh, "plain Richard" and I are in agreement on something. A
pertinent fact is that Bill has supposedly been learning C since at
least 1992. I think it's even earlier, that's the furthest back post I
can get the crippled Google Groups search to cough up. If he's no
farther along than this, there's little point in trying to instruct him.




Brian

 

[Bill Cunningham]

Sorry, but there is no rule number 6.

I will RTFM as soon as I can find the thing. I've got books scattered
everywhere from where I moved back with my parents. They seem to have taken
it upon themselves to clean rooms.

Bill

 

[Dik T. Winter]

> Don't do that. The path to correct code is not to
> type some random garbage and then make incremental changes until it
> works; it's to figure out what you want to do, figure out how to do
> it, and then do it.

The problem is not incremental changes, the problem is random changes. In
that case it becomes essentially a random walk.