Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > 2D arrays, pointers, and pointer arithmetic: question

Reply
Thread Tools

2D arrays, pointers, and pointer arithmetic: question

 
 
Eric Sosman
Guest
Posts: n/a
 
      08-28-2012
On 8/28/2012 3:06 PM, Adrian Ratnapala wrote:
> On 2012-08-27, James Kuyper <(E-Mail Removed)> wrote:
>> On 08/27/2012 04:35 PM, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>> ...
>>> printf ( "The address for a[%d][%d] is %p\n", i, j, &a[i][j] );

>>
>> Whenever you print a pointer using "%p", the expression you print should
>> have the type 'void*'. In all cases in this code, that would require a

>
> Is there really any reason to cast an (int *) into a (void *). The only
> reason I could imagine is to keep your compiler quiet.


This is Question 5.17 at the comp.lang.c Frequently Asked
Questions (FAQ) page, <http://www.c-faq.com/>.

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      08-28-2012
On 08/28/2012 03:06 PM, Adrian Ratnapala wrote:
> On 2012-08-27, James Kuyper <(E-Mail Removed)> wrote:
>> On 08/27/2012 04:35 PM, (E-Mail Removed) wrote:
>> ...
>>> printf ( "The address for a[%d][%d] is %p\n", i, j, &a[i][j] );

>>
>> Whenever you print a pointer using "%p", the expression you print should
>> have the type 'void*'. In all cases in this code, that would require a

>
> Is there really any reason to cast an (int *) into a (void *). The only
> reason I could imagine is to keep your compiler quiet.


The standard says that the behavior is undefined. It does so because
there are real platforms out there where void* is incompatible with
int*. For instance, on platforms where the word size is larger than than
a byte, a void* must include information identifying the particular byte
within a word where an object starts, because it might be required to
point at an object smaller than a word. However, for word-aligned types,
the pointer need only identify which word it starts at. There have been
real machines where pointers to word-aligned types have been smaller
than pointers to smaller types, for precisely this reason.
It's also permissible for pointers of the same size to use different
representations. I don't know of any examples, but I wouldn't recommend
ruling out that possibility.

Is that a good enough reason for you? If you're certain your code will
never be used on such machines, you can ignore the issue - in which case
someone, not necessarily you, will pay the price if your certainty turns
out to be unjustified. If you do this, you'll have plenty of company.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      08-28-2012
James Kuyper <(E-Mail Removed)> writes:
> On 08/28/2012 03:06 PM, Adrian Ratnapala wrote:

[...]
>> Is there really any reason to cast an (int *) into a (void *). The only
>> reason I could imagine is to keep your compiler quiet.

>
> The standard says that the behavior is undefined. It does so because
> there are real platforms out there where void* is incompatible with
> int*.

[...]

Strictly speaking, void* and int* are incompatible types regardless of
the platform (the standard has its own definition of compatibility for
types). The point, of course, is that they can have different
representations.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      08-28-2012
On 08/28/2012 05:11 PM, Keith Thompson wrote:
> James Kuyper <(E-Mail Removed)> writes:
>> On 08/28/2012 03:06 PM, Adrian Ratnapala wrote:

> [...]
>>> Is there really any reason to cast an (int *) into a (void *). The only
>>> reason I could imagine is to keep your compiler quiet.

>>
>> The standard says that the behavior is undefined. It does so because
>> there are real platforms out there where void* is incompatible with
>> int*.

> [...]
>
> Strictly speaking, void* and int* are incompatible types regardless of
> the platform (the standard has its own definition of compatibility for
> types). The point, of course, is that they can have different
> representations.


I should have said "have incompatible representations". I didn't mean to
bring C's definition of compatible types into the discussion.
Incompatible representations is a sufficient, but not necessary,
condition for types to be incompatible.

 
Reply With Quote
 
Adrian Ratnapala
Guest
Posts: n/a
 
      08-29-2012
In comp.lang.c, you wrote:
>>
>> Is there really any reason to cast an (int *) into a (void *). The only
>> reason I could imagine is to keep your compiler quiet.

>
> The standard says that the behavior is undefined. It does so because
> there are real platforms out there where void* is incompatible with
> int*. For instance, on platforms where the word size is larger than than

<snip>

> Is that a good enough reason for you? If you're certain your code will

That's a good enough reason.

I had mistakenly thought the (void *) requirement was mere pedanticism,
because I thought pointers always had the same size unless explictly
modified by something like "near/far". And I agree "always, on the
machines you know about is a far, far cry from "always".

BTW: I don't know if my misconception is "frequent" enough to warrant an
FAQ change, but it doesn't look like the FAQ covers this. Contra Eric,
5.17 is about something else; 4.17 / 19.40 are closer but not quite
relevant.

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      08-29-2012
On 08/29/2012 03:20 AM, Adrian Ratnapala wrote:
> In comp.lang.c, you wrote:
>>>
>>> Is there really any reason to cast an (int *) into a (void *). The only
>>> reason I could imagine is to keep your compiler quiet.

>>
>> The standard says that the behavior is undefined. It does so because
>> there are real platforms out there where void* is incompatible with
>> int*. For instance, on platforms where the word size is larger than than

> <snip>
>
>> Is that a good enough reason for you? If you're certain your code will

> That's a good enough reason.
>
> I had mistakenly thought the (void *) requirement was mere pedanticism,


Almost every seemly pedantic issue associated with the standard exists
because there are implementations where the issue is relevant, or at
least there were such implementations at the time the rule was created.
There's a few that exist just because the committee didn't see any need
to impose a requirement on future implementations just because every
current implementation satisfies that requirement, but those are rare.

> because I thought pointers always had the same size unless explictly
> modified by something like "near/far". ...


In general, pointers to different types can, in principle, have
different representations, alignment requirements, or even sizes. The
word-size issue is the only one I'm aware of that actually comes up on
real implementations, but there's probably other reasons I'm unaware of.
There's only a few exceptions:

Pointers to void have the same representation and alignment requirements
as pointers to character types (6.2.5p26.

Identically-qualified pointers to compatible types are compatible
(6.7.6.1p2), and pointer types that differ only in the way that they are
qualified have the same representation and alignment (6.2.5p26).

> ... And I agree "always, on the
> machines you know about is a far, far cry from "always".


Good - I'd thought your comment reflected a more casual attitude toward
portability issues. The tone of my reply reflected my disdain for people
with such attitudes; I apologize for that.

> BTW: I don't know if my misconception is "frequent" enough to warrant an
> FAQ change, but it doesn't look like the FAQ covers this. Contra Eric,
> 5.17 is about something else;


5.17 is also about other things, but it mentions systems which use
multiple different (and presumably incompatible) pointer types: the
Eclipse MV series from Data General, the HP 3000, "several of the
machines above" (which is a little vague), and some 64-bit Cray
machines. All three of the specific example involve word pointers vs.
byte pointers.
--
James Kuyper
 
Reply With Quote
 
Adrian Ratnapala
Guest
Posts: n/a
 
      08-29-2012

>> BTW: I don't know if my misconception is "frequent" enough to warrant an
>> FAQ change, but it doesn't look like the FAQ covers this. Contra Eric,
>> 5.17 is about something else;

>
> 5.17 is also about other things, but it mentions systems which use
> multiple different (and presumably incompatible) pointer types: the


All true, but it doesn't directly tackle my error, only the consequences
of it. That's fine in an FAQ, since it could be that many people are
confused about NULL pointers while not so many have specific wrong ideas
about pointer representations.

On the other hand, if my error *is* common. Or at least if people often
ask that turn out to involve pointer representations, then the FAQ
should probably include something similar to what you just wrote.

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      08-29-2012
On 8/29/2012 3:20 AM, Adrian Ratnapala wrote:
> [... about converting int* to void* for "%p" conversion ...]
> BTW: I don't know if my misconception is "frequent" enough to warrant an
> FAQ change, but it doesn't look like the FAQ covers this. Contra Eric,
> 5.17 is about something else; 4.17 / 19.40 are closer but not quite
> relevant.


5.17 is mostly about representations of null pointers, but
not entirely. If you'll read the entire thing, you'll find two
specific mentions of different pointer formats, plus a link to
further examples.

14.17 and 19.40(d) are about `near' and `far', whose
connection to the matter at hand eludes me.

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-29-2012
Eric Sosman <(E-Mail Removed)> writes:
> On 8/29/2012 3:20 AM, Adrian Ratnapala wrote:
>> [... about converting int* to void* for "%p" conversion ...]
>> BTW: I don't know if my misconception is "frequent" enough to warrant an
>> FAQ change, but it doesn't look like the FAQ covers this. Contra Eric,
>> 5.17 is about something else; 4.17 / 19.40 are closer but not quite
>> relevant.

>
> 5.17 is mostly about representations of null pointers, but
> not entirely. If you'll read the entire thing, you'll find two
> specific mentions of different pointer formats, plus a link to
> further examples.
>
> 14.17 and 19.40(d) are about `near' and `far', whose
> connection to the matter at hand eludes me.


`near` and `far`, which are of course non-standard, can result in
different pointer types having different sizes. Passing a `near`
or `far` pointer to printf with a "%p" format is likely to give
bad results in practice.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Edward Rutherford
Guest
Posts: n/a
 
      08-29-2012
Keith Thompson wrote:
> `near` and `far`, which are of course non-standard, can result in
> different pointer types having different sizes. Passing a `near` or
> `far` pointer to printf with a "%p" format is likely to give bad results
> in practice.


Using near or far pointers in any way at all will invoke an undefined
behavior, so I think it's safe to say bad results are likely with or
without attempts to printf() such pointers!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
pointer to an array vs pointer to pointer subramanian100in@yahoo.com, India C Programming 5 09-23-2011 10:28 AM
Pointer to pointer or reference to pointer A C++ 7 07-05-2011 07:49 PM
Pointer to pointer Vs References to Pointer bansalvikrant@gmail.com C++ 4 07-02-2009 10:20 AM
passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer jimjim C Programming 16 03-27-2006 11:03 PM
Pointer-to-pointer-to-pointer question masood.iqbal@lycos.com C Programming 10 02-04-2005 02:57 AM



Advertisments