regcmp warning: improper pointer/integer combination: op "="

[jose_luis_fdez_diaz_news]

Hi,

If I don't include <libgen.h> I get then warnig below in regcmp call:

warning: improper pointer/integer combination: op "="

but if I include it the warning is not shown, but them program compiles
fine.

What is the warning shown ?

Thanks,
Jose Luis.

 

[jacob navia]

Hi,

If I don't include <libgen.h> I get then warnig below in regcmp call:

warning: improper pointer/integer combination: op "="

but if I include it the warning is not shown, but them program compiles
fine.

What is the warning shown ?

Thanks,
Jose Luis.

In C all functions return an int if the prototype is not known to the
compiler.

If you have a function that returns a pointer like:

char *fn(void);

you can do this in your code without problems:

char *a = fn();

Now, if the compiler doesn't see the prototype, the fn function is
assumed to return an integer, that gets assigned to char char pointer
a. Assignment of an integer to a pointer is not a very good idea,
even if "it works", so the compiler warns you about it.

Solution:

DO INCLUDE all necessary header files when compiling.

jacob

 

[CBFalconer]

If I don't include <libgen.h> I get then warnig below in regcmp call:

warning: improper pointer/integer combination: op "="

but if I include it the warning is not shown, but them program
compiles fine.

What is the warning shown ?

There is no such standard include file in C, nor is there any such
routine as regcmp. You will have to show the code for these to
receive any reasonable answer.

 

[Flash Gordon]

Hi,

If I don't include <libgen.h> I get then warnig below in regcmp call:

warning: improper pointer/integer combination: op "="

but if I include it the warning is not shown, but them program compiles
fine.

What is the warning shown ?

Well, without the source code one can only guess. However, I would
assume regcmp (which is not part of standard C) returns some kind of
pointer, and that you are assigning it to an appropriate pointer
variable. I further assume that the non-standard header libgen.h
provides a prototype for the non-standard regcmp function.

In C, if there is no declaration of a function in scope when it is used
it is assumed to return an int. The compiler is required to issue a
diagnostic (a warning in this case) when you assign an int directly to a
pointer, which is what is occurring without the prototype that libgen.h
probably provides.

So include the headers (I assume libgen.h) that the manuals (or man
pages) for your system tell you to include for the non-standard
functions you are using.

Of course, if you had asked about this on a group dedicated to your
system then the people answering would know if libgen.h was the correct
header to include. Here we deal with standard C not extensions provided
by specific implementations.

 

[Mark McIntyre]

There is no such standard include file in C, nor is there any such
routine as regcmp. You will have to show the code for these to
receive any reasonable answer.

No he doesn't - its perfectly possible to explain this without knowing
anything outside Standard C. Indeed jacob navia's answer was it.

CBF this is about the nth time you've unjustly posted in this vein. Is it
worth stepping back from the keyboard for a couple of days?

 

[CBFalconer]

No he doesn't - its perfectly possible to explain this without
knowing anything outside Standard C. Indeed jacob navia's answer
was it.

CBF this is about the nth time you've unjustly posted in this
vein. Is it worth stepping back from the keyboard for a couple
of days?

Color me stoopid, but I don't see any such diagnosis. It is just
one of many possibilities, and nobody can tell without seeing the
source.

 

[DHOLLINGSWORTH2]

Actually someone familliar with the error codes returned durring a build,
and for a particular platform, they can answer this question without seeing
any code.

and in the example

char *pc = fn();

if you know it should fit then:

char *pc = (char * ) fn();

makes it fit.

 

[Jens.Toerring]

Actually someone familliar with the error codes returned durring a build,
and for a particular platform, they can answer this question without seeing
any code.

and in the example

char *pc = fn();

if you know it should fit then:

char *pc = (char * ) fn();

makes it fit.

Looks like clc acquired another troll, top-posting, spewing misin-
formation dangerous for unsuspecting newbies and all...

To the OP: Never, ever mindlessly use a cast just to get rid of a
compiler warning. The warning indicates that the compiler found
something that looks fishy. But by casting you tell the compiler
"Shut up, I know what I am doing, get out of my way". Unless you
really mean it don't do that but try to understand why you get the
warning (and you posted here because you didn't, did you) and what
is the best way to avoid it. Use casts only after you understood
all implications and are sure it's the only and right thing to do.

And here, as "Flesh Gordon" explained perfectly well, a cast is
obviously not necessary (actually, it would be a bad thing to use)
since you only get it when you don't include the header file that
declares the (return type of the) function you're calling.

Regards, Jens

 

[DHOLLINGSWORTH2]

I'm glad to see that you DO agree with me on one or two points.

It's too bad you like to hear it from your own mouth.

As far as missinformation goes I've been writting programs since 1986.

And although you may not be familiar with a product, doesn't mean every body
else is just as ignorant.

To the OP: Never, ever mindlessly use a cast just to get rid of a
compiler warning. The warning indicates that the compiler found
something that looks fishy. But by casting you tell the compiler

Actually I agreed with the man that he doesn't need to see the code. And
aparently you, who hasn't seen the code, agrees with both of us.

But by casting you tell the compiler
"Shut up, I know what I am doing, get out of my way". Unless you
really mean it don't do that but try to understand why you get the

Is this not what I just said?

spewing misin-
formation dangerous for unsuspecting newbies and all...

You have confirmed every bit of information I spewed.
Thank you.

Looks like clc acquired another troll, top-posting,

Stick it in your ass!

 

[Flash Gordon]

And here, as "Flesh Gordon" explained perfectly well, a cast is

Actually, it is Flash Gordon. Flesh Gordon is my dirty minded twin

 

[Flash Gordon]

I'm glad to see that you DO agree with me on one or two points.

It's too bad you like to hear it from your own mouth.

As far as missinformation goes I've been writting programs since 1986.

That does not mean that you actually know what you are talking about or
that you are not giving misinformation.

And although you may not be familiar with a product, doesn't mean every body
else is just as ignorant.

This group does not deal with implementation specifics. There are plenty
of groups that do.

I happen to believe the CBF was over zealous since I believe a good
indication could be obtained from the diagnostic without knowing the
specific implementation. However, note that I still considered it worth
redirecting the OP because the function in question *is* on-standard so
it is only the diagnostic that gives us a clue as to what the problem was.

Actually I agreed with the man that he doesn't need to see the code. And
aparently you, who hasn't seen the code, agrees with both of us.

I was able to take a good guess and based on that give a standard C
answer about the probable problem. However, there are likely to be other
problems that the OP needs to address that we can't do here.

Is this not what I just said?

When a function actually returns a pointer, casting to get rid of the
warning due to not having the declaration in scope is NEVER the right
thing to do. As I almost said to the OP (but thought it too much
information) you actually invoke undefined behaviour and one REAL way
this fails on some implementations is the address being returned in
register A0 but the compiler reading from D0 (because it thinks an
integer is returned) and so storing garbage in the pointer variable
whilst ignoring the real pointer value. So whether you know "it should
fit" is not the question, the question is whether the compiler knows the
real return type. Also, I cannot think of any instances where it is
appropriate to have a function actually return an int and the program
then cast that to a pointer type and store it in a pointer.

You have confirmed every bit of information I spewed.
Thank you.

No, you suggested that casting might be an appropriate solution. It is
definitely NOT the correct solution.

<OT>
regcmp declared in libgen.h *does* return a pointer to char, so casting
would definitely invoke undefined behaviour and almost certainly cause
the program to fail on some real *nix implementations, it almost
certainly being a *nix program.

Stick it in your ass!

The *only* reason I'm not plonking you is that any further
misinformation you spew needs to be corrected to try to prevent people
who do not know any better from believing you.

 

[Jens.Toerring]

Actually, it is Flash Gordon. Flesh Gordon is my dirty minded twin

Oh, sorry. Didn't mean to do that (but I plead innocence, I had to
google to find out what's the difference between you two;-)

Regards, Jens

 

[Richard Bos]

Actually someone familliar with the error codes returned durring a build,
and for a particular platform, they can answer this question without seeing
any code.

Which is exactly what Mr. Gordon did, and correctly, which is more than
can be said for your answer.

and in the example

char *pc = fn();

if you know it should fit then:

char *pc = (char * ) fn();

makes it fit.

No, it doesn't. If there is no declaration for fn() in scope, the
implementation assumes it returns int. Casting this int to char * may,
but need not, result in the char * that was originally returned from
fn().
If, for example, the implementation optimises function calls by
returning scalars in registers rather than on the stack, and by using
separate address and integer registers where available, your cast is
going to result in a lot of random garbage being returned.

Just provide a proper declaration for all your functions, if at all
possible by #including the appropriate headers, and you'll never have to
worry about such bogus casts again.

Richard

 

[Flash Gordon]

Oh, sorry. Didn't mean to do that (but I plead innocence, I had to
google to find out what's the difference between you two;-)

Just as long as you did not do the googling from work. Your employer
might not understand ;-)

 

[DHOLLINGSWORTH2]

And I could pretend to be an ass and say that none of youtr examples work
becuase they have no main proc in them.

And I may be wrong, but Type casting is a no no, then why is it in the
STANDARD?

Bullocks

 

[Michael Mair]

And I could pretend to be an ass and say that none of youtr examples work
becuase they have no main proc in them.

Please quote enough of the message you refer to for those of us who
might not (yet) have found it yet on their newsservers.

And I may be wrong, but Type casting is a no no, then why is it in the
STANDARD?

As I do not know what you are referring to:
Typecasting is only necessary if the implicit conversions do not
or cannot achieve what you are trying to do. It is good style to
use typecasts only when they are necessary or, very seldom, when
they clarify your intent. The latter is almost never helpful, thus
"very seldom".
Unnecessary typecasting may lead to equally unnecessary errors or
misinterpretations, so one should avoid it.

Some examples where you may need typecasts:
- null pointer constants as arguments to variadic functions
- enforcing a certain precision for the result of a floating point
computation
- giving the left operand of a left shift the necessary width
- ...

Bullocks

I understand that this is either an unfortunate first name or a very
honest qualification of your writings or a very unfriendly closing
for your message.
None of that does look good for you.


- Michael

 

[Keith Thompson]

And I could pretend to be an ass and say that none of youtr examples work
becuase they have no main proc in them.

And I may be wrong, but Type casting is a no no, then why is it in the
STANDARD?

Type casting is in the standard because there are cases where it can
be used correctly and usefully. For example, if you want have a
pointer-to-int variable and you want to show its value, you can use:

int *ptr = <whatever>;
printf("ptr = %p\n", (void*)ptr);

This cast is necessary and appropriate because the call to printf()
doesn't provide a context that forces an implicit conversion.

In most other cases, though, C's implicit conversion rules make casts
unnecessary (and often dangerous).

The OP was asking about an implementation-defined function that
returns a char*; an implementation-defined header provides a prototype
for the function. If the header is not included, the compiler sees a
call and doesn't know what type it returns. In C90, the language
requires the compiler to assume (incorrectly in this case) that it
returns int, so it will generate code that assumes this. Casting the
result to char* doesn't fix the problem, it hides it. The result is
that the compiler generates code takes the (potentially nonexistent)
int result of the function and converts it to char*. This may happen
to work on some systems, but will fail on others.

For the call to work properly, the compiler must know that the
function returns a char*. The way to do this is to include the header
(or to declare the function explicitly, but it's almost always better
to include the header).

Your response suggested that casting the result would be a solution.
You were mistaken. Several people pointed out your error. This is
not being an "ass"; indeed, leaving your error uncorrected would have
been rude to you and to all the readers who might follow your advice.

Making mistakes isn't a horrible sin. I've made plenty myself, and
I'm glad when they're corrected. If someone points out that you've
made a mistake, don't take it personally.

And if you want to be taken seriously, I strongly suggest you stop
top-posting. We're not asking you this just to be annoying; your
posting style really does make your articles more difficult to read.
You've already been told in detail why top-posting is a bad idea.