Why compiler not generating any warning ?

[junky_fellow]

Consider the following piece of code:

struct junk {
int i_val;
int i_val1;
char c_val;
};

int main(void)
{
struct junk str_junk;
int * i_ptr;
struct junk * pstr_junk;
pstr_junk = &str_junk;
i_ptr = (int *)pstr_junk + 1; /* shouldn't the compiler
give warning here ? */
}

On compiling this program: cc -c99 -check -portable test.c
I don't get any warning.
However, the statement
i_ptr = (int *)pstr_junk + 1; seems to be incorrect to me.

Here, pstr_junk is a pointer to structure and it is being typecasted to
"int *" which may cause undefined behaviour.
But on compilation I don't get any warning message.
So, what is the way to cacth these type of bugs ? Is there
any other tool that may find out all undefined, unportable
behaviour ?
I tried *lint* as well but it also didn't warned for this.

Only, the typecasting to "char *" should be allowed which is
*guaranteed* to point to the lowest addressed byte of the structure.

[pete]

ju**********@ya hoo.co.in wrote:

But on compilation I don't get any warning message.
So, what is the way to cacth these type of bugs ?

Learn more C.

--
pete

[Jens.Toerring]

ju**********@ya hoo.co.in wrote:

Consider the following piece of code: struct junk {
int i_val;
int i_val1;
char c_val;
}; int main(void)
{
struct junk str_junk;
int * i_ptr;
struct junk * pstr_junk;
pstr_junk = &str_junk;
i_ptr = (int *)pstr_junk + 1; /* shouldn't the compiler
give warning here ? */
} On compiling this program: cc -c99 -check -portable test.c
I don't get any warning.
However, the statement
i_ptr = (int *)pstr_junk + 1; seems to be incorrect to me. Here, pstr_junk is a pointer to structure and it is being typecasted to
"int *" which may cause undefined behaviour.
You will also get undefined behaviour when you write past the end of
an array, if you use a pointer to already deallocated memory etc. ect.
but the compiler won't warn about that.
But on compilation I don't get any warning message.
Well, you tell the compiler "convert this pointer to a pointer of
a different type". So the compiler does, and since you explicitely
told it to do that why should it doubt the wisdom of your commands?
If you cast you basically say "I know what I am doing, don't tell
me I shouldn't, if I would like you to warn me I wouldn't use that
[expletive censored] cast". And afterwards you tell it "assign to
a pointer from a pointer of the same type" which is 100% legal and
not dangerous at all.
So, what is the way to cacth these type of bugs ? Is there
any other tool that may find out all undefined, unportable
behaviour ?
The best tool is probably between your ears;-) View all casts as
being suspicious until you're satisifed that they are ok. Finding
all instances of undefined behaviour would be impossible, it might
only happen at runtime - the compiler can't typically know in ad-
vance if e.g. in an access of an array element the index is going
to be within the bounds of the array. And undefined behaviour is
not something evil in itself, it's just something the C standard
does not define. And in most programs you actually rely on unde-
fined behaviour to work out fine, e.g. when you call a function
in a third-party library - while a strictly conforming program may
use only those features of the language and library specified in
the C standard you very often need more than just that.
Only, the typecasting to "char *" should be allowed which is
*guaranteed* to point to the lowest addressed byte of the structure.

In this case maybe yes. But there can be situations where you
know what's going to happen on the platform you're working on
(because it's well-documented) and where you have to explicitely
invoke undefined behaviour in order to get things done.

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@p hysik.fu-berlin.de
\______________ ____________ http://www.toerring.de

[jacob navia]

pete wrote:

ju**********@ya hoo.co.in wrote:

But on compilation I don't get any warning message.
So, what is the way to cacth these type of bugs ?

Learn more C.

What is the point of this reply?

He is exactly trying to learn more C and asks in this
discussion group a question.

Of course *you* never asked any questions when you were learning C.

Why being rude to newcomers?

If you do not feel like answering or you think the question is silly
just do not reply.

jakob

[pete]

jacob navia wrote:

pete wrote:

ju**********@ya hoo.co.in wrote:

But on compilation I don't get any warning message.
So, what is the way to cacth these type of bugs ?

Learn more C.

What is the point of this reply?

The only way that you catch undefined behavior
that your compiler warnings miss, is by knowing enough C.
That's pretty much the whole point of reading this newsgroup.

--
pete

[Ed Vogel]

<ju**********@y ahoo.co.in> wrote in message

On compiling this program: cc -c99 -check -portable test.c
I don't get any warning.
However, the statement
i_ptr = (int *)pstr_junk + 1; seems to be incorrect to me.

Here, pstr_junk is a pointer to structure and it is being typecasted to
"int *" which may cause undefined behaviour.
But on compilation I don't get any warning message.

From the switches used, I'll guess you're using the HP C compiler
on Tru64. If that's the case, you can get the compiler to
emit a diagnostic for this case.

Using -check enables most messages, but not all. To enable
all messages use the -msg_enable all option. To get the
specific message for this case, use -msg_enable ansialiascast.

Ed Vogel
HP/Compaq/DEC C/C++ Engineering

[Robert Gamble]

On Fri, 03 Jun 2005 04:03:17 -0700, junky_fellow wrote:

Consider the following piece of code:

struct junk {
int i_val;
int i_val1;
char c_val;
};

int main(void)
{
struct junk str_junk;
int * i_ptr;
struct junk * pstr_junk;
pstr_junk = &str_junk;
i_ptr = (int *)pstr_junk + 1; /* shouldn't the compiler
give warning here ? */
}

On compiling this program: cc -c99 -check -portable test.c I don't get
any warning.
However, the statement
i_ptr = (int *)pstr_junk + 1; seems to be incorrect to me.

Here, pstr_junk is a pointer to structure and it is being typecasted to
"int *" which may cause undefined behaviour.
You can safely convert a pointer to a structure to a pointer to the first
element of the structure, no undefined behavior. What is dangerous is the
pointer arithmetic you perform after the conversion. You might expect
i_ptr to point to the second member in the structure but since there may
be padding between the two integers, dereferencing the pointer would
invoke UB.
But on compilation I don't get any warning message.
I don't see anything that requires such a message.
So, what is the way to cacth these type of bugs ? Is there any other
tool that may find out all undefined, unportable behaviour ?
Nothing to add to pete and Jens responses.
I tried *lint* as well but it also didn't warned for this.
Okay.
Only, the typecasting to "char *" should be allowed which is
*guaranteed* to point to the lowest addressed byte of the structure.

Nope. In addition to this and the case I described above, a pointer to a
structure may safely be converted to a pointer to any other structure and
back again.

Robert Gamble

[Jonathan Bartlett]

> struct junk str_junk;

int * i_ptr;
struct junk * pstr_junk;
pstr_junk = &str_junk;
i_ptr = (int *)pstr_junk + 1; /* shouldn't the compiler
give warning here ? */

Why? You casted pstr_junk to an integer pointer. Since you are doing
an explicit cast, the compiler assumes that you know what you are doing.
Then you told the integer pointer to advance one, which is a perfectly
valid thing for an integer pointer to do (though, because it's from the
cast, the results are undefined, but since you did an explicit cast, the
compiler won't complain). Then you assigned your new integer pointer to
i_ptr, which is of type int *.

What did you expect the compiler to complain about?

Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017

[Mark McIntyre]

On 3 Jun 2005 04:03:17 -0700, in comp.lang.c ,
ju**********@ya hoo.co.in wrote:

However, the statement
i_ptr = (int *)pstr_junk + 1; seems to be incorrect to me.
it /is/ incorrect. But you lied to the compiler, by putting in the
cast. This says "shut up, I know what I'm doing" to the compiler.
Hence no warning.
So, what is the way to cacth these type of bugs ?
Avoid casts, which are almost never needed in C, unless you're trying
to do naughty things. Or programme better...
I tried *lint* as well but it also didn't warned for this.
It can't since you already lied and told us that you knew what you
were doing....
Only, the typecasting to "char *" should be allowed which is
*guaranteed* to point to the lowest addressed byte of the structure.

You need to understand the difference between a conversion and a cast.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On Fri, 03 Jun 2005 12:42:44 GMT, in comp.lang.c , pete
<pf*****@mindsp ring.com> wrote:

jacob navia wrote:

pete wrote:

> ju**********@ya hoo.co.in wrote:
>
>
>>But on compilation I don't get any warning message.
>>So, what is the way to cacth these type of bugs ?
>
>
> Learn more C.
>

What is the point of this reply?

The only way that you catch undefined behavior
that your compiler warnings miss, is by knowing enough C.
That's pretty much the whole point of reading this newsgroup.

To be fair though, you could have explained *why* the compiler didn't
grumble, and why using casts is a bad idea.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----