«

writes:
> Keith Thompson wrote:
>> writes:
>> > James Kuyper wrote:
>> >> For a string not prefixed by "0x" or "0X", what happens to s if t==s at
>> >> the time the loop condition is evaluated?
>> >
>> > Then --s will evaluate to the address one before the pointer
>> > originally passed to the function. This would only cause a problem if
>> > the original pointer was to address 0, but in that case it would be a
>> > NULL pointer, which isn't allowed (the argument given to htoi must be
>> > a STRING).
>>
>> No, if the passed pointer points to the beginning of an object (as
>> opposed to the "-32"+1 example elsethread), then attempting to point
>> before the beginning of the object invokes undefined behavior. For
>> example, given:
>>
>> char *s = "hello";
>>
>> just evaluating (s-1), even without attempting to dereference it,
>> invokes UB.
>
> There are two ways to think about pointers. It's true that (s-1) isn't
> a "valid" pointer to char, because we don't (necessarily) own the
> memory before s.

It's not a valid pointer because it's outside the object, whether we
"own" the memory or not. The behavior of performing the subtraction
is not defined by the standard. (Behaving as you expect is one
possible consequence of undefined behavior -- arguably the worst,
because it makes it difficult to detect bugs.)

> However, if you think about a pointer as just an address in memory,
> then s-1 makes sense - it's just the location in memory before s.

But C (which is what we discuss here) doesn't define pointers as just
addresses in memory, and not all machines have the same addressing
structure. Most current machines have a simple linear address space,
and allocate objects within that space, but the C standard is
specifically designed to allow for conforming implementations on
hardware with other schemes.

Segmented architectures are not uncommon. In the extreme, an
implementation could even use a distinct segment for each individual
declared object, and cause a hardware trap if you try to compute an
address outside the object where you started.

See section 4 of the comp.lang.c FAQ, <http://c-faq.com/>.

>> Furthermore, address 0 is not necessarily the same as a null pointer.
>> (The FAQ, www.c-faq.com, has an entire section on null pointers.)
>>
>> It may be that some implementations will happen to behave as you say,
>> but that's not guaranteed by the standard.
>
> I think you are mistaken - I've definitely read that char *p=NULL; and
> char *p=0; are completely equivalent.

Yes, they are, but no, I'm not mistaken. Both NULL and 0 are null
pointer constants. (Quibble: NULL is a macro that expands to an
implementation-defined null pointer constant.) When a null pointer
constant is used in a pointer context, it's implicitly converted to a
null pointer, which *may or may not* be represented as all-bits-zero.

For example, if a null pointer is represented as 0xFFFFFFFF, then the
declaration
char *p = 0;
will set p's representation to 0xFFFFFFFF.

See section 5 of the comp.lang.c FAQ.

--
Keith Thompson (The_Other_Keith) <kst->
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:
> It's not a valid pointer because it's outside the object, whether we
> "own" the memory or not. The behavior of performing the subtraction
> is not defined by the standard. (Behaving as you expect is one
> possible consequence of undefined behavior -- arguably the worst,
> because it makes it difficult to detect bugs.)
>
> > However, if you think about a pointer as just an address in memory,
> > then s-1 makes sense - it's just the location in memory before s.
>
> But C (which is what we discuss here) doesn't define pointers as just
> addresses in memory, and not all machines have the same addressing
> structure. Most current machines have a simple linear address space,
> and allocate objects within that space, but the C standard is
> specifically designed to allow for conforming implementations on
> hardware with other schemes.
>
> Segmented architectures are not uncommon. In the extreme, an
> implementation could even use a distinct segment for each individual
> declared object, and cause a hardware trap if you try to compute an
> address outside the object where you started.
>
> See section 4 of the comp.lang.c FAQ, <http://c-faq.com/>.

OK, but I'm sure I remember reading that you're allowed to have
pointers to one-beyond and one-before your allocated memory, as long
as you don't dereference them. Hum.

> > I think you are mistaken - I've definitely read that char *p=NULL; and
> > char *p=0; are completely equivalent.
>
> Yes, they are, but no, I'm not mistaken. Both NULL and 0 are null
> pointer constants. (Quibble: NULL is a macro that expands to an
> implementation-defined null pointer constant.) When a null pointer
> constant is used in a pointer context, it's implicitly converted to a
> null pointer, which *may or may not* be represented as all-bits-zero.
>
> For example, if a null pointer is represented as 0xFFFFFFFF, then the
> declaration
> char *p = 0;
> will set p's representation to 0xFFFFFFFF.
>
> See section 5 of the comp.lang.c FAQ.

Interesting. So how do you create a pointer that actually points to
address 0?

On Tue, 04 Dec 2007 13:39:11 -0800, rajash wrote:
> Keith Thompson wrote:
>> writes:
>> > James Kuyper wrote:
>> >> For a string not prefixed by "0x" or "0X", what happens to s if t==s
>> >> at the time the loop condition is evaluated?
>> >
>> > Then --s will evaluate to the address one before the pointer
>> > originally passed to the function. This would only cause a problem if
>> > the original pointer was to address 0, but in that case it would be a
>> > NULL pointer, which isn't allowed (the argument given to htoi must be
>> > a STRING).
>>
>> No, if the passed pointer points to the beginning of an object (as
>> opposed to the "-32"+1 example elsethread), then attempting to point
>> before the beginning of the object invokes undefined behavior. For
>> example, given:
>>
>> char *s = "hello";
>>
>> just evaluating (s-1), even without attempting to dereference it,
>> invokes UB.
>
> There are two ways to think about pointers. It's true that (s-1) isn't a
> "valid" pointer to char, because we don't (necessarily) own the memory
> before s.
>
> However, if you think about a pointer as just an address in memory, then
> s-1 makes sense - it's just the location in memory before s.

You're assuming there is a location in memory before s. This is not
always the case. But even in those cases where there is, compiler
optimisations may interfere with your expectations. The behaviour is
undefined, so don't do it.

>> Furthermore, address 0 is not necessarily the same as a null pointer.
>> (The FAQ, www.c-faq.com, has an entire section on null pointers.)
>>
>> It may be that some implementations will happen to behave as you say,
>> but that's not guaranteed by the standard.
>
> I think you are mistaken - I've definitely read that char *p=NULL; and
> char *p=0; are completely equivalent.

You read correctly, but 0 is a null pointer constant, which is not
necessarily address 0.

raj...@thisisnotmyrealemail.com wrote:
....
> OK, but I'm sure I remember reading that you're allowed to have
> pointers to one-beyond and one-before your allocated memory, as long
> as you don't dereference them. Hum.

You either remember incorrectly, or what you were reading was
incorrect. Section 6.5.6p8 says:

"Moreover, if the expression P points to the last element of an array
object, the expression (P)+1 points one past the last element of the
array object, and if the expression Q points one past the last element
of an array object,
the expression (Q)-1 points to the last element of the array object.
If both the pointer operand and the result point to elements of the
same array object, or one past the last element of the array object,
the evaluation shall not produce an overflow; otherwise, the behavior
is undefined. If the result points one past the last element of the
array object, it shall not be used as the operand of a unary *
operator that is evaluated."

There is no comparable wording for the beginning of an array, so the
"otherwise" case applies to your code.

....
> Interesting. So how do you create a pointer that actually points to
> address 0?

I can't think of any valid reason for doing so. If you did need to do
it, the reason would be inherently non-portable. I would strongly
suspect that on any platform where you had a legitimate need to create
a pointer pointing at address 0, you could use either

void *p = 0;

or

memset(&p, 0, sizeof p)

On Tue, 04 Dec 2007 14:08:36 -0800, rajash wrote:
> OK, but I'm sure I remember reading that you're allowed to have pointers
> to one-beyond and one-before your allocated memory, as long as you don't
> dereference them. Hum.

Only one beyond, not one before.

>> > I think you are mistaken - I've definitely read that char *p=NULL;
>> > and char *p=0; are completely equivalent.
>>
>> Yes, they are, but no, I'm not mistaken. [snip explanation]
>>
>> See section 5 of the comp.lang.c FAQ.
>
> Interesting. So how do you create a pointer that actually points to
> address 0?

This is one of the questions in section 5 of the comp.lang.c FAQ.
Specifically, take a look at question 19.

Lew Pitcher wrote:
>
.... snip ...
>
> Ben, not meaning to jiggle your elbow, but...
>
> How is
> htoi("-32" + 1)
> different from
> htoi("32");

Here's one way:

[1] c:\c\junk>cat junk.c
#include <stdio.h>

void htoi(const char *p) {
fprintf(stdout, "%p\n", (void*)p);
} /* htoi */

/* ------------------- */

int main(void) {

htoi("-32" + 1);
htoi("32");
return 0;
} /* main, fcopylns */

[1] c:\c\junk>cc junk.c

[1] c:\c\junk>.\a
1651
1654

Alternatively:

[1] c:\c\junk>cat junk.c
#include <stdio.h>

void htoi(const char *p) {
fprintf(stdout, "%p\n", (void*)p);
} /* htoi */

/* ------------------- */

int main(void) {

const char *m32 = "-32";
const char *p32 = "32";

htoi(m32 + 1);
htoi(p32);
return 0;
} /* main, fcopylns */

[1] c:\c\junk>cc junk.c

[1] c:\c\junk>.\a
1651
1654

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



--
Posted via a free Usenet account from http://www.teranews.com