convert 16 bit port to Char

CBFalconer wrote:
> Hans-Bernhard Br�ker wrote:

>> I'll call.  Show why exactly this would be an error.  And no,
>> examples of compilers that refuse to accept this don't count as
>> evidence.

> Because the 'address of PORTD' isn't a valid pointer in standard
> C.  

Yes.  But C does have implicit conversions from integers to pointers. 
So, while it's not certainly not portable, it's not strictly an error 
either.

On Sat, 05 Jul 2008 20:59:16 +0200, Hans-Bernhard Br�ker
<HBBroeker@t-online.de> wrote:

>CBFalconer wrote:
>> Hans-Bernhard Br&#4294967295;ker wrote:
>
>>> I'll call.  Show why exactly this would be an error.  And no,
>>> examples of compilers that refuse to accept this don't count as
>>> evidence.
>
>> Because the 'address of PORTD' isn't a valid pointer in standard
>> C.  
>
>Yes.  But C does have implicit conversions from integers to pointers. 
>So, while it's not certainly not portable, it's not strictly an error 
>either.

I don't have the text of C99 here but from the earlier C89 standard:

6.3.4
Conversions that involve pointers (other than as permitted by the
constraints of 6.3.16.1) shall be specified by means of an explicit cast

and in 6.3.16.1 Simple Assignment
Constraints
One of the following shall hold:
...
- both operands are pointers to qualified or unqualified versions of
compatible types
- one operand is a pointer to an object or incomplete type and the other
is a pointer to a qualified or unqualified version of void ...
- the left operand is a pointer and the right is a null pointer constant

The Rationale from both C89 and C99 state that:

"Since pointers and integers are now considered incommensurate, the only
integer value that can be safely converted to a pointer is a constant
expression with the value 0. The result of converting any other integer
value, including a non-constant expression with the value 0, to a
pointer is implementation-defined."

So it sounds like a conforming implementation is not required to accept
an assignment expression where the left-hand side is a pointer type and
the right-hand side is an integer type without an explicit cast.

-- 
Rich Webb     Norfolk, VA

Hans-Bernhard Br�ker wrote:
> CBFalconer wrote:
>> Hans-Bernhard Br�ker wrote:
> 
>>> I'll call.  Show why exactly this would be an error.  And no,
>>> examples of compilers that refuse to accept this don't count as
>>> evidence.
> 
>> Because the 'address of PORTD' isn't a valid pointer in standard
>> C.
>>    An address or pointer can involve all sorts of things, such as
>> disks, tapes, segments, whatever.  If your system has provisions
>> to accept such things and convert them to 'pointers' then that
>> provision is peculiar to that system.  It is NOT portable.
> 
> Yes.  But C does have implicit conversions from integers to pointers.
> So, while it's not certainly not portable, it's not strictly an error
> either.

Which is what I said, in one form or another, and which you
snipped.  I have restored the 2nd, 3rd, and 4th sentences of my
message above.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

Rich Webb wrote:

> I don't have the text of C99 here but from the earlier C89 standard:
> 
> 6.3.4
> Conversions that involve pointers (other than as permitted by the
> constraints of 6.3.16.1) shall be specified by means of an explicit cast
> 
> and in 6.3.16.1 Simple Assignment
> Constraints
> One of the following shall hold:
> ...
> - both operands are pointers to qualified or unqualified versions of
> compatible types
> - one operand is a pointer to an object or incomplete type and the other
> is a pointer to a qualified or unqualified version of void ...
> - the left operand is a pointer and the right is a null pointer constant

Now the question is: do these constraints apply before, or after the 
semantics of 6.3.16.1 (C99: 6.5.16.1) have been taken care of?  These 
semantics are:

In simple assignment (=), the value of the right operand is converted to 
the type of the assignment expression and replaces the value stored in 
the object designated by the left operand.

The conversion of an integer to a pointer is explicitly allowed earlier 
(C99: 6.3.2.3p5).  So once that's happened, we're looking at an 
assignment among pointers to compatible types, and all's fine.

> The Rationale from both C89 and C99 state that:
> 
> "Since pointers and integers are now considered incommensurate, the only
> integer value that can be safely converted to a pointer is a constant
> expression with the value 0. The result of converting any other integer
> value, including a non-constant expression with the value 0, to a
> pointer is implementation-defined."

It's implementation-defined, and thus not "safe".  But that's not the 
same as being an error.  It means that the program isn't fully 
compliant, i.e. it won't be portable.

> So it sounds like a conforming implementation is not required to accept
> an assignment expression where the left-hand side is a pointer type and
> the right-hand side is an integer type without an explicit cast.

I don't see how that follows from the quoted definitions. Please note 
that "implementation-defined result" does _not_ include a compiler 
refusing to translate the source.
>