14 Dec, 2010, RoFAdmin wrote in the 1st comment:
Votes: 0
Hey everyone-

So in my boredom i decided to throw the -pedantic and -ansi flags into my makefile.
WHOOOOWEEEEE there are alot of warnings and errors. Most are pretty straight forward, a couple i have some questions on.

FIRST ONE:
warning: array type has incomplete element type

This one is going off like crazy for all the extern const structs in tables.h
From what i gather this is because the compiler doesnt know what size to expect. However my clan_table is defined as clan_type clan_table[MAX_CLAN] which does set a size obviously, and it still hates that one as well. Any suggestions?

SECOND ONE:
warning: overflow in implicit constant conversion
These are coming from comm.c on the following lines.

const char echo_off_str [] = { IAC, WILL, TELOPT_ECHO, '\0' };
const char echo_on_str [] = { IAC, WONT, TELOPT_ECHO, '\0' };
const char go_ahead_str [] = { IAC, GA, '\0' };

No clue as to this error, and my googling wasnt very helpful.

THIRD ONE:
implicit declartion of isascii and strdup

these funtions are actually no where in my code leading me to think they are in a library that is supposed to be included or something? Never got these warning without the -pedantic and -ansii flags so im not really sure here.

FOURTH ONE:
warning: pointer of type 'void *' used in arethmetic

ummmm, huh? These are in alloc_mem and free_mem


I have also been compiling with the -Wno-char-subscripts flag. This supresses a bunch of array subscript has type 'char' errors, but also apparently was suppressing some other errors that showed up when i took it out and compiled with the -pedantic -ansi. The other ones i was able to fix, but im not sure how to go about fixing the
array subscript errors. Any ideas? or should i just go back to using the -Wno-char-subscripts flag?


Thanks for the help in advance.

_-RofAdmin-_
14 Dec, 2010, quixadhal wrote in the 2nd comment:
Votes: 0
Your assumption is incorrect. The compiler knows exactly what to expect, but the sloppy code isn't it. :)

1) Incomplete element type probably means either clan_type hasn't been typedef'd at the point you're using it, or it might be that your initialization of the array has a typo where an element is missing from one entry. The message isn't one I'm familiar with.
2) IAC is character code 255. You're using signed characters, which have a range of -128 to 127.
3) Any time you get an implicit declaration, you are using a function without declaring a prototype. Those are probably used in macros somewhere in your header files. Use "man" and figure out which system headers to include for them, probably <ctype.h> and/or <unistd.h>.
4) The compiler will warn you if you try to use pointer arithmetic on a void pointer, because void had no size. Cast it as something appropriate for how you're using it.
15 Dec, 2010, Kaz wrote in the 3rd comment:
Votes: 0
RoFAdmin said:
FIRST ONE:
warning: array type has incomplete element type

This one is going off like crazy for all the extern const structs in tables.h
From what i gather this is because the compiler doesnt know what size to expect. However my clan_table is defined as clan_type clan_table[MAX_CLAN] which does set a size obviously, and it still hates that one as well. Any suggestions?


It's not about the size of the array itself, but about the size of the elements therein. Here's an example of some code that does this:

/* Declaration of struct foo */
typedef struct foo foo;

/* Definition of bar table */
static const foo bar[] =
{
{ 1, 2 }
};

/* Definition of struct foo */
struct foo
{
int a, b;
};


At the time the array called 'bar' is defined, only the name of struct foo is known, not its size. This is an incomplete type. Essentially, you need to ensure that the definition of the elements of an array occurs before the array itself. Note, this may include incomplete structures within the element's type. E.g.

typedef struct foo foo;
struct bar
{
int a;
struct foo baz;
};

static const struct bar quux[] =
{
{ 1, { 2, 3 } }
};


RoFAdmin said:
THIRD ONE:
implicit declartion of isascii and strdup


In C, you're allowed to make up functions on the spot. Try compiling the following code:

int main() { int p = gargle_mouthwash(); }


No problem. You'll get a linker error (because gargle_mouthwash doesn't exist), but it will have compiled the source happily. These are called implicitly declared functions. They are assumed to take any number of arguments, and return int (which was the source of your 'pointer from integer without cast' warning in your other thread). It's a better practice to have them declared before they're called. You can do that here by #including the relevant files:

/* for strdup */
#include <string.h>

/* for isascii */
#include <ctype.h>


RoFAdmin said:
these funtions are actually no where in my code leading me to think they are in a library that is supposed to be included or something? Never got these warning without the -pedantic and -ansii flags so im not really sure here.


My guess is that they are hidden away in a macro in a header file. A grep should yield them.

RoFAdmin said:
FOURTH ONE:
warning: pointer of type 'void *' used in arethmetic

ummmm, huh? These are in alloc_mem and free_mem


I'd have so see the code, but my guess is that it's doing exactly what the warning says it's doing.


RoFAdmin said:
I have also been compiling with the -Wno-char-subscripts flag. This supresses a bunch of array subscript has type 'char' errors, but also apparently was suppressing some other errors that showed up when i took it out and compiled with the -pedantic -ansi. The other ones i was able to fix, but im not sure how to go about fixing thearray subscript errors. Any ideas? or should i just go back to using the -Wno-char-subscripts flag?


I'd have to see source and error messages for that.
15 Dec, 2010, RoFAdmin wrote in the 4th comment:
Votes: 0
Heya-

Couple things to clarify.

1) Thank you for the clear answer and excellent example Kaz. Turned out the problem was simply a matter of placement of the externs.

2) Ill come back to this one at a later point.

3) Hehe, that was my bad for explaining improperly. I do have calls to those functions in my code, but the actual function were not. And i was fairly certain that they needed an include as you excellently stated. However i have a further problem. The needed includes are actually in place. Yet it is still an angry beaver. and yes i did indeed make sure that said functions were in said include library (string.h and ctype.h) yet the code is still un-pleased. I am unsure of how to continue on fixing this issue.
I have checked the man pages for isascii and it is indeed in ctype.h, and the include is in all the needed place in the code, but it buggers out still
I checked the man page for strdup, cygwin tells me bugger off dude we dont have a man page for that.
I have also determined that my warning of - array subscript has type 'char' - is caused by a call to isspace, which is also supposed to be in ctype.h and is included in all the needed places.

What i dont not understand is that these functions calls actually work, and even work how they are supposed to despite the fact the compiler would like to think they are not declared anywhere and acts as if i wasn't including the right files….

mmm also just noticed in the spam of warnings im getting the same error for function srandom….. grumble grumble

4) So as you suggested code for the arithmetic on void * error is below.
void *alloc_mem( int sMem )
{
void *pMem;
int *magic;
int iList;

sMem += sizeof(*magic);

for ( iList = 0; iList < MAX_MEM_LIST; iList++ )
{
if ( sMem <= rgSizeList[iList] )
break;
}

if ( iList == MAX_MEM_LIST )
{
bug( "Alloc_mem: size %d too large.", sMem );
exit( 1 );
}

if ( rgFreeList[iList] == NULL )
{
pMem = alloc_perm( rgSizeList[iList] );
}
else
{
pMem = rgFreeList[iList];
rgFreeList[iList] = * ((void **) rgFreeList[iList]);
}

magic = (int *) pMem;
*magic = MAGIC_NUM;
pMem += sizeof(*magic);

return pMem;
}


the offending line is pMem += sizeof(*magic);

and incase you are not familiar with, or dont know off hand MAGIC_NUM is #define MAGIC_NUM 52571214

Thanks again for the help guys, while im not a complete idiot and think very highly of myself and my coding skills, my knowledge of C is entirely self taught, and thus some of the finer intricacies of the language and are lost on me.

_-RoFAdmin-_
15 Dec, 2010, Kaz wrote in the 5th comment:
Votes: 0
RoFAdmin said:
1) Thank you for the clear answer and excellent example Kaz. Turned out the problem was simply a matter of placement of the externs.


It's a pleasure ;)

RoFAdmin said:
3) Hehe, that was my bad for explaining improperly. I do have calls to those functions in my code, but the actual function were not.


Yep, that's allowed. isascii and strdup are part of the C library that your compiler ships with, and are automatically linked in at the end of the compilation.

RoFAdmin said:
The needed includes are actually in place.


Sounds like an ordering issue. #include them earlier.

RoFAdmin said:
I have also determined that my warning of - array subscript has type 'char' - is caused by a call to isspace, which is also supposed to be in ctype.h and is included in all the needed places.


I looked that one up, since I've never come across it. It appears to be a warning for cases like this:

char index = 128;
foo[index] = 999;


Here, because char is (on your platform) a signed 8-bit value, foo[index] is actually foo[-127], which is almost always not what you want. Solution: don't use char indices (or subscripts, as it calls them).

RoFAdmin said:
What i dont not understand is that these functions calls actually work, and even work how they are supposed to despite the fact the compiler would like to think they are not declared anywhere and acts as if i wasn't including the right files….


C does magic like that. During compile time, when you call a function it didn't previously know about, it just guesses fills in the blanks (any number of arguments, returns int, like I said previously). Then, during link time, it scouts around for something with the correct name, and connects the code to that. In your case, the functions are part of the C library your compiler is shipped with, just like things like printf and fopen and such, so it links them in no problem. It's still better to have the right #includes in the right places, though.

RoFAdmin said:
4) So as you suggested code for the arithmetic on void * error is below.
void *pMem;
int *magic;



pMem += sizeof(*magic);


A reminder:

RoFAdmin said:
warning: pointer of type 'void *' used in arethmetic


Yup, that's exactly what happened: void* += int. :)

In an expression p += n, it grabs the value (n * sizeof(*p)) and adds that to the address that is p. Why? To make traversing arrays easier. If p is a pointer to an array of struct foo, and you call p += 1, you don't want to step one byte along, you want to step one foo along so that you can access the next foo in the array. However, since void has no size, incrementing a void* (and thus looking for (n * sizeof(void))) is almost certainly incorrect. As Quixadhal mentioned earlier, you probably want a proper cast to shut that up.

Probably something like:

pMem = (char*)pMem + sizeof(*magic);


Explanation: cast pMem into a byte representation (char*), add sizeof(*magic) (that's the same as sizeof(int)) bytes to it, and assign the result back to the void* pMem.

Untested, though. I would test that change in isolation to any other changes.
15 Dec, 2010, Tyche wrote in the 6th comment:
Votes: 0
RoFAdmin said:
I have checked the man pages for isascii and it is indeed in ctype.h, and the include is in all the needed place in the code, but it buggers out still
I checked the man page for strdup, cygwin tells me bugger off dude we dont have a man page for that.


The gcc compiler on cygwin uses newlibc as the standard C library. Man page documentation for it isn't complete.
I usually use the web.
This site is pretty good as it contains several different OS man pages: http://www.unix.com/apropos-man/All/0/ma...

RoFAdmin said:
What i dont not understand is that these functions calls actually work, and even work how they are supposed to despite the fact the compiler would like to think they are not declared anywhere and acts as if i wasn't including the right files….


You'll notice that even though these functions reside in external libraries the linker manages to find them.
That's because the gcc compiler collection has a specs file (configuration) that tells it which linker, assembler, what standard C library to use and where to find it all on your system.
On cygwin it's in "\lib\gcc\i686-pc-cygwin\3.4.4\specs"
You probably don't want to modify this file though.

Also you can install the gcc 4.3.4 compiler and run both side by side. If you do gcc will invoke the new compiler by default and gcc-3 invokes the old compiler.
15 Dec, 2012, Igabod wrote in the 7th comment:
Votes: 0
On the first one. I'm having the same error message pop up for a lot of different things as well. But I have no clue how to solve it. I have a rough idea from the information here that I need to change or add an "#include <blah.h>" to the top of the file but don't know which one. Could I get a bit more of an explanation?
15 Dec, 2012, Caius wrote in the 8th comment:
Votes: 0
The reason including ctype.h doesn't seem to work is because you're using -ansi and -pedantic to enforce the standard strictly. isascii() and strdup() aren't actually part of the C standard. You can work around it by adding the following to the top of the source file, above all the includes:

#ifdef __STRICT_ANSI__
#define _BSD_SOURCE
#endif
0.0/8