int pointing to char

[Gautam]

this piece of code assigns an int pointer(evident ) to a char,
and when i try to access the ascii value of the char through the
integer pointer(p) ,

what i get is a junk value or not i don't know !
'cause it shows consistent values for diff. chars , for eg.
c = 'a' ans=>-9119

c = 'b' ans=>-9118

c = 'c' ans=>-9117

... and so on
#include <stdio.h>

void main()
{
char c = 'a';
int * p;

p = &c; /*suspicious pointer conversion WARNING !*/
clrscr();
pf("\n%d", *p);
getch();
}

. . . . whats happening ?

Gautam

[pete]

James Hu wrote:

On 2004-03-04, Old Wolf <ol*****@inspir e.net.nz> wrote:

> this piece of code assigns an int pointer(evident ) to a char,
> and when i try to access the ascii value of the char through the
> integer pointer(p) ,
> what i get is a junk value or not i don't know !

> #include <stdio.h>
>
> void main()
> {
> char c = 'a';
> int * p;
>
> p = &c; /*suspicious pointer conversion WARNING !*/
> clrscr();
> pf("\n%d", *p);
> getch();
> }

> . . . . whats happening ?

You are lying to the compiler about what p is pointing to. Assuming
that pf() in your program is not #defined to be an empty statement,
your program results in undefined behavior, so anything could happen.

Actually, undefined behaviour is introduced by "void main()",

I generally ignore this, since it may be valid in a freestanding
environment.

and also by the line "p = &c;" (for example, it could produce
a hardware exception on a device which requires int pointers
to be correctly aligned).

What would such hardware do when presented with:

char c = 'a';
void *q = &c;
int *p = q;

?

It is UB to point a pointer to an object of an incompatible type.

I don't believe a constraint violation results in undefined behavior,
but IANACLL (xref: 6.5.16.1p1 and 4p1).

If a constraint is violated,
then you don't know what the code means,
and that's undefined behavior.

N869
3. Terms and definitions
3.6
[#1] constraints
restrictions, both syntactic and semantic, by which the
exposition of language elements is to be interpreted

--
pete

[Dan Pop]

In <84************ **************@ posting.google. com> ol*****@inspire .net.nz (Old Wolf) writes:

> this piece of code assigns an int pointer(evident ) to a char,
> and when i try to access the ascii value of the char through the
> integer pointer(p) ,
> what i get is a junk value or not i don't know !

> #include <stdio.h>
>
> void main()
> {
> char c = 'a';
> int * p;
>
> p = &c; /*suspicious pointer conversion WARNING !*/
> clrscr();
> pf("\n%d", *p);
> getch();
> }

> . . . . whats happening ?

You are lying to the compiler about what p is pointing to. Assuming
that pf() in your program is not #defined to be an empty statement,
your program results in undefined behavior, so anything could happen.

Actually, undefined behaviour is introduced by "void main()",
and also by the line "p = &c;"

Nope, this is a constraint violation and requires a diagnostic. Mere
undefined behaviour doesn't.
(for example, it could produce
a hardware exception on a device which requires int pointers
to be correctly aligned). It is UB to point a pointer to an
object of an incompatible type.

Only in certain cases, when the incompatible type has looser alignment
requirements. Character pointers (of all three types) can be pointed to
any object. Pointers to unsigned char can even be safely dereferenced
after that. A pointer to int can be safely made to point to a struct
whose first member has type int. It can be even dereferenced, if the
struct member has already been initialised.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <40***********@ mindspring.com> pete <pf*****@mindsp ring.com> writes:

James Hu wrote:

On 2004-03-04, Old Wolf <ol*****@inspir e.net.nz> wrote:

> It is UB to point a pointer to an object of an incompatible type.

I don't believe a constraint violation results in undefined behavior,
but IANACLL (xref: 6.5.16.1p1 and 4p1).

If a constraint is violated,
then you don't know what the code means,
and that's undefined behavior.

This is correct. The important point is that the constraint violation
*requires* a diagnostic, while a mere invocation of undefined behaviour
doesn't.

After the diagnostic is produced, there is no difference between the
two, because the standard doesn't specify the semantics of any code
that contains syntax errors or constraint violations.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[James Hu]

On 2004-03-04, Dan Pop <Da*****@cern.c h> wrote:

In <40***********@ mindspring.com> pete <pf*****@mindsp ring.com> writes:

James Hu wrote:

On 2004-03-04, Old Wolf <ol*****@inspir e.net.nz> wrote:

> It is UB to point a pointer to an object of an incompatible type.

I don't believe a constraint violation results in undefined behavior,
but IANACLL (xref: 6.5.16.1p1 and 4p1).

If a constraint is violated,
then you don't know what the code means,
and that's undefined behavior.

This is correct. The important point is that the constraint violation
*requires* a diagnostic, while a mere invocation of undefined behaviour
doesn't.

After the diagnostic is produced, there is no difference between the
two, because the standard doesn't specify the semantics of any code
that contains syntax errors or constraint violations.

Like I said, IANACLL, but my understanding was that the behavior of a
constraint violation is unspecified behavior, not undefined behavior.

A program can still be correct if it contains unspecified behavior
(xref: 4p3).

-- James

[James Hu]

On 2004-03-04, James Hu <jx*@despammed. com> wrote:

On 2004-03-04, Dan Pop <Da*****@cern.c h> wrote:

In <40***********@ mindspring.com> pete <pf*****@mindsp ring.com> writes:

James Hu wrote:

On 2004-03-04, Old Wolf <ol*****@inspir e.net.nz> wrote:

> It is UB to point a pointer to an object of an incompatible type.

I don't believe a constraint violation results in undefined behavior,
but IANACLL (xref: 6.5.16.1p1 and 4p1).
I should qualify that with "c.v. doesn't necessarily result in u'd.b.".
If a constraint is violated,
then you don't know what the code means,
and that's undefined behavior.

This is correct. The important point is that the constraint violation
*requires* a diagnostic, while a mere invocation of undefined behaviour
doesn't.

After the diagnostic is produced, there is no difference between the
two, because the standard doesn't specify the semantics of any code
that contains syntax errors or constraint violations.

Like I said, IANACLL, but my understanding was that the behavior of a
constraint violation is unspecified behavior, not undefined behavior.

Since I have only be looking at the assignment operator, this statement
should be restricted to the assignment in question:

char c = 'a';
int *p = &a;

-- James

[Dan Pop]

In <N7************ ********@comcas t.com> James Hu <jx*@despammed. com> writes:

On 2004-03-04, Dan Pop <Da*****@cern.c h> wrote:

In <40***********@ mindspring.com> pete <pf*****@mindsp ring.com> writes:

James Hu wrote:

On 2004-03-04, Old Wolf <ol*****@inspir e.net.nz> wrote:

> It is UB to point a pointer to an object of an incompatible type.

I don't believe a constraint violation results in undefined behavior,
but IANACLL (xref: 6.5.16.1p1 and 4p1).

If a constraint is violated,
then you don't know what the code means,
and that's undefined behavior.
This is correct. The important point is that the constraint violation
*requires* a diagnostic, while a mere invocation of undefined behaviour
doesn't.

After the diagnostic is produced, there is no difference between the
two, because the standard doesn't specify the semantics of any code
that contains syntax errors or constraint violations.

Like I said, IANACLL, but my understanding was that the behavior of a
constraint violation is unspecified behavior, not undefined behavior.

3.4.4
1 unspecified behavior
behavior where this International Standard provides two or more
possibilities and imposes no further requirements on which is
chosen in any instance

When a constraint is violated, the standard doesn't provide *any*
possibilities the implementation can choose from, either explicitly or
implicitly.

For example:

6.5.2.1 Array subscripting

Constraints

1 One of the expressions shall have type ``pointer to object type'',
the other expression shall have integer type, and the result
has type ``type''.

What are the allowed possibilities for the type of a[b] when both a and b
have type double?
A program can still be correct if it contains unspecified behavior
(xref: 4p3).

But a program CANNOT be correct if it violates a constraint. That's why
they're called "constraint s" in the first place.

A correct C program (from the standard's POV) is a program that
doesn't require any diagnostic and doesn't invoke undefined behaviour.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <Uo************ ********@comcas t.com> James Hu <jx*@despammed. com> writes:

On 2004-03-04, James Hu <jx*@despammed. com> wrote:

On 2004-03-04, Dan Pop <Da*****@cern.c h> wrote:

In <40***********@ mindspring.com> pete <pf*****@mindsp ring.com> writes:

James Hu wrote:
>
> On 2004-03-04, Old Wolf <ol*****@inspir e.net.nz> wrote:
>
> > It is UB to point a pointer to an object of an incompatible type.
>
> I don't believe a constraint violation results in undefined behavior,
> but IANACLL (xref: 6.5.16.1p1 and 4p1).
I should qualify that with "c.v. doesn't necessarily result in u'd.b.".
If a constraint is violated,
then you don't know what the code means,
and that's undefined behavior.

This is correct. The important point is that the constraint violation
*requires* a diagnostic, while a mere invocation of undefined behaviour
doesn't.

After the diagnostic is produced, there is no difference between the
two, because the standard doesn't specify the semantics of any code
that contains syntax errors or constraint violations.

Like I said, IANACLL, but my understanding was that the behavior of a
constraint violation is unspecified behavior, not undefined behavior.

Since I have only be looking at the assignment operator, this statement
should be restricted to the assignment in question:

char c = 'a';
int *p = &c;

The C standard doesn't classify constraint violations in several
categories. ALL of them have the same effect: a diagnostic is required
after which there are no more requirements from the implementation.
An implementation aborting the translation process after issuing a
required diagnostic would be perfectly conforming.

If all C compilers failed to translate code *requiring* a diagnostic,
C would be a better known language. Far too many incompetents discard
ALL the warnings by default, without trying to understand if they signal
a real problem or not. If the program appears to work as expected, it
*must* be correct.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Old Wolf]

> >> > char c = 'a';

> int * p;
>
> p = &c; /*suspicious pointer conversion WARNING !*/ [snips] > . . . . whats happening ?

You are lying to the compiler about what p is pointing to. Assuming
that pf() in your program is not #defined to be an empty statement,
your program results in undefined behavior, so anything could happen.
Actually, undefined behaviour is introduced by "void main()",

I generally ignore this, since it may be valid in a freestanding
environment.

I generally ignore freestanding environments, as you could raise
the objection "it may be valid in a f.e." to just about anything
posted on c.l.c.
FWIW, void main() may be valid in a hosted environment too.

and also by the line "p = &c;" (for example, it could produce
a hardware exception on a device which requires int pointers
to be correctly aligned).

What would such hardware do when presented with:

char c = 'a';
void *q = &c;
int *p = q;

The same thing. You may be thinking of the requirement that a pointer
to object type may be cast to (void *) and back again later _to the
original type_. That is not happening in this situation.

I program in an environment where this does generate a hardware exception
(but that does not resolve this argument, as it could just be that
this environment is non-conforming)
I don't believe a constraint violation results in undefined behavior,
but IANACLL (xref: 6.5.16.1p1 and 4p1).

It seems to me that the Standard only has something to say on topics
where its constraints are met, so this case is outside of the Standard's
scope, therefore UB. IANACLL either though :)

[Old Wolf]

> >> > char c = 'a';

> int * p;
>
> p = &c; /*suspicious pointer conversion WARNING !*/

Actually, undefined behaviour is introduced by "void main()",
and also by the line "p = &c;"

Nope, this is a constraint violation and requires a diagnostic. Mere
undefined behaviour doesn't.

This sentence seems to imply that constraint violations
are all UB (otherwise, I fail to understand your use of 'mere')
(for example, it could produce
a hardware exception on a device which requires int pointers
to be correctly aligned). It is UB to point a pointer to an
object of an incompatible type.

Only in certain cases, when the incompatible type has looser alignment
requirements. Character pointers (of all three types) can be pointed to
any object. Pointers to unsigned char can even be safely dereferenced
after that. A pointer to int can be safely made to point to a struct
whose first member has type int. It can be even dereferenced, if the
struct member has already been initialised.

I agree totally, but the case in point (pointer to int being made to
point to a char) is not in your list of acceptable pointings.

[James Hu]

On 2004-03-04, Dan Pop <Da*****@cern.c h> wrote:

In <Uo************ ********@comcas t.com> James Hu <jx*@despammed. com> writes:

On 2004-03-04, James Hu <jx*@despammed. com> wrote:

>> [snip]>> I don't believe a constraint violation results in undefined behavior,
>> but IANACLL (xref: 6.5.16.1p1 and 4p1).
I should qualify that with "c.v. doesn't necessarily result in u'd.b.".
[snip]

Like I said, IANACLL, but my understanding was that the behavior of a
constraint violation is unspecified behavior, not undefined behavior.

Since I have only be looking at the assignment operator, this statement
should be restricted to the assignment in question:

char c = 'a';
int *p = &c;

BTW, if it wasn't clear before, my xref's are against C99.

The C standard doesn't classify constraint violations in several
categories. ALL of them have the same effect: a diagnostic is required
after which there are no more requirements from the implementation.
An implementation aborting the translation process after issuing a
required diagnostic would be perfectly conforming.
I think this is true of C89. But, C99 seems to have changed things.

For one thing:

xref 4p2: If a "shall" or "shall not" requirement that appears
outside of a constraint is violated, the behavior is undefined.

And this sentence is repeated in the Appendix the summarizes
undefined behaviors. If a constraint violation implied undefined
behavior, I believe the standard would not have bothered to state
this exception.

As to the particular assignment, there is a curious example in the
standard:

xref 6.5.16.1p6: EXAMPLE3: Consider the fragment:

const char **cpp;
char *p;
const char c = 'A';

cpp = &p; // constraint violation
*cpp = &c; // valid
*p = 0; // valid

The first assignment is unsafe because it would allow the
following valid code to attempt to change the value of the
const object c.

It seems the standard is implying the statement with the constraint
violation still has valid semantics.
If all C compilers failed to translate code *requiring* a diagnostic,
C would be a better known language.
Better known? Perhaps just better...
Far too many incompetents discard
ALL the warnings by default, without trying to understand if they signal
a real problem or not.

This point cannot be made often enough.

-- James