strlen() argument warning

[Tydr Schnubbis]

/* my declarations */
struct bitmap_set {
char *filename;
int n_files;
};

struct bitmap_set bitmap_sets[] = {
/* <filename>, <n_files> */
{ "player_00g.bmp", 1 },
{ "player_00.bmp", 1 },
/* ... snip ...*/
{ NULL, 0 } /* sentinel */
};

/* in a function in the same file: */
ASSERT(strlen(GRAPHICS_DIR) + strlen(OTHER_PATH_SEPARATOR)
+ strlen(bitmap_sets[set_i].filename) /* LINE 71 */
<= MAX_PATH_LENGTH);

/* no warning for this: */
size_t len = strlen(bitmap_sets[set_i].filename);


Compiler message:
gcc -Wall -W -Wno-unused -Wredundant-decls -Winline -ffast-math -O2 -g
-c -o files.o files.c
files.c: In function `files_load_bitmaps':
files.c:71: warning: passing arg 1 of `strlen' makes pointer from
integer without a cast

What's wrong here?

strlen(bitmap_sets[set_i].filename)

is okay in the assignment, but not in the ASSERT().
What am I not seeing here?

Tor

 

[Alexander Bartolich]

begin followup to Tydr Schnubbis:

What am I not seeing here?

Sure about the line number?
What about GRAPHICS_DIR and OTHER_PATH_SEPARATOR?

 

[Tydr Schnubbis]

begin followup to Tydr Schnubbis:



Sure about the line number?
What about GRAPHICS_DIR and OTHER_PATH_SEPARATOR?

I added backslashes at the end of the lines, like this:

ASSERT(strlen(GRAPHICS_DIR) + strlen(OTHER_PATH_SEPARATOR) \
+ strlen(bitmap_sets[set_i].filename) \
<= MAX_PATH_LENGTH);

Now the compiler says that the error is in the first line of the
ASSERT() statement instead of the second. Sure had me fooled!

So I discovered that OTHER_PATH_SEPARATOR is in fact a char,
not a char *...

Looks like GCC only reports errors at the line where the statement ends,
in my code it looked like this:
ASSERT(strlen(GRAPHICS_DIR) + strlen(OTHER_PATH_SEPARATOR)
+ strlen(bitmap_sets[set_i].filename) <= MAX_PATH_LENGTH);

The compiler reported the error in the second line, when it was really
in the first. Adding the backslashes makes the preprocessor turn the
statement into a single line before the compiler sees it.

 

[Servé La]

/* in a function in the same file: */

ASSERT(strlen(GRAPHICS_DIR) + strlen(OTHER_PATH_SEPARATOR)
+ strlen(bitmap_sets[set_i].filename) /* LINE 71 */
<= MAX_PATH_LENGTH);

maybe OTHER_PATH_SEPARATOR is defined as '/' instead of "/"

 

[Alexander Bartolich]

begin followup to Tydr Schnubbis:

Looks like GCC only reports errors at the line where the statement
ends, in my code it looked like this:
ASSERT(strlen(GRAPHICS_DIR) + strlen(OTHER_PATH_SEPARATOR)
+ strlen(bitmap_sets[set_i].filename) <= MAX_PATH_LENGTH);

I guess that ASSERT is a macro. Option -E of gcc can show you the
intermediate output of the pre-processor. It is typicall much longer
than the original file, with #line statements trying to maintain the
illusion. And the nature of #line makes it necessary to give the
whole macro expansion a single number.

 

[Peter Nilsson]

/* my declarations */
struct bitmap_set {
char *filename;
int n_files;
};

struct bitmap_set bitmap_sets[] = {
/* <filename>, <n_files> */
{ "player_00g.bmp", 1 },
{ "player_00.bmp", 1 },
/* ... snip ...*/
{ NULL, 0 } /* sentinel */
};

/* in a function in the same file: */
ASSERT(strlen(GRAPHICS_DIR) + strlen(OTHER_PATH_SEPARATOR)
+ strlen(bitmap_sets[set_i].filename) /* LINE 71 */
<= MAX_PATH_LENGTH);

/* no warning for this: */
size_t len = strlen(bitmap_sets[set_i].filename);


Compiler message:
gcc -Wall -W -Wno-unused -Wredundant-decls -Winline -ffast-math -O2 -g
-c -o files.o files.c
files.c: In function `files_load_bitmaps':
files.c:71: warning: passing arg 1 of `strlen' makes pointer from
integer without a cast

What's wrong here?

Almost certainly, your real problem is with...

strlen(OTHER_PATH_SEPARATOR)

....where I'm betting your macro is a character constant like '/'.

 

[CBFalconer]

.... snip ...

The compiler reported the error in the second line, when it was
really in the first. Adding the backslashes makes the preprocessor
turn the statement into a single line before the compiler sees it.

Tip: when you are having problems seeing where the error lies, see
what splint (and/or pclint) has to say about it. They should find
the same errors, and possibly many more, but the reports are often
much more detailed. Splint is not overpriced at 0 (currency of
choice).