CODEWITHSUNDEEP
cmacosgcc
Alex
Alex

Reputation: 166

Still the "error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token"

This is a small pure C program illustrative of the problem. The program doesn't do anything; it's a stripped-down version of a larger program that exhibits the same problem.

Here is the scenario:

Mac OS X Lion;

gcc version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00);

Sample code:

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

char huge *pbA;
char huge *pbB;

int main(int argc,char *argv[])
{
    pbA = (char huge *)farmalloc(2);
    pbB = pbA;
    *(pbB++) = 'A';
    return( 0 );
}

Compile command:

gcc -c -Wall -O -g -pipe  -D_SDL myTest.c

Errors messages:

myTest.c:4: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
myTest.c:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
myTest.c: In function ‘main’:
myTest.c:10: error: ‘pbA’ undeclared (first use in this function)
myTest.c:10: error: (Each undeclared identifier is reported only once
myTest.c:10: error: for each function it appears in.)
myTest.c:10: error: expected ‘)’ before ‘huge’
myTest.c:10: warning: implicit declaration of function ‘farmalloc’
myTest.c:11: error: ‘pbB’ undeclared (first use in this function)

So, what am I missing?

Upvotes: 0

Views: 4832

Answers (1)

Qaz
Qaz

Reputation: 61910

I'm not sure what/where huge is, but the compiler can't find it in what you've given it (i.e. you're missing a header probably). As for farmalloc, that looks to be in <alloc.h>. Now about using these, there is an answer on another site for huge:

Keywords like near/far/huge were once used as memory models in the old MSDOS 
days when computers had a max of 640K memory.

Any machine built in the last 15 years does not have that restriction so 
unless you have a real issue where you have to use really obsolete hardware, 
I would not spend time with segmented memory model syntax.

huge, and probably farmalloc as well, seem to be deprecated by today's standards (just like far vs near pointers). Using just char * and malloc should be all you need; no strange, old headers.

Upvotes: 3

Related Questions