addresses and integers

[CBFalconer]

Except, of course, when you are trying to do system-dependent things,
such as really fast memory-copy functions, in which case you will .... snip ...

None of this code is very portable, of course, but most programs are
not written to be universally portable in the first place.

Except in c.l.c we deal with portable code, and leave those things
to system specific newsgroups.

 

[Dan Pop]

Non-portably, of course.

Conversions between pointers and integers provide a fairly portable way
(not absolutely portable, of course) that is also blessed by the C
standard (no extensions are needed at all). It works on most hosted
implementations in current use and you'll have to resort to things like
AS/400 for exceptions.

Dan

 

[Keith Thompson]

(e-mail address removed) (Dan Pop) writes: [...]

How do you check that the pointer is aligned for an integer access?
If it isn't, how do you align it?

Non-portably, of course.

Conversions between pointers and integers provide a fairly portable way
(not absolutely portable, of course) that is also blessed by the C
standard (no extensions are needed at all). It works on most hosted
implementations in current use and you'll have to resort to things like
AS/400 for exceptions.

Or Cray vector systems.

The conversions themselves are "blessed by the C standard"; the
semantics of using them to check alignment are not, even by
implication.

 

[David R Tribble]

Except in c.l.c we deal with portable code, and leave those things
to system specific newsgroups.

Sure, our primary focus is on standard-conforming code, but we don't
limit our discussion to such code alone. We also discuss existing practice
a great deal, and we certainly don't ignore the fact that most existing
C code is, in fact, not written to be portable.

Statements such as "most implementations provide reasonable and expected
conversions between pointers and integers" are entirely relevant to this
newsgroup [comp.std.c], even though it obviously doesn't cover all
conforming implementations.

In fact, discussions of implementations that don't fit the most common
model provide support for many of the decisions in, and limitations of,
ISO C.

-drt
[posting to news:comp.std.c]

 

[Dan Pop]

(e-mail address removed) (Dan Pop) writes: [...]
How do you check that the pointer is aligned for an integer access?
If it isn't, how do you align it?

Non-portably, of course.

Conversions between pointers and integers provide a fairly portable way
(not absolutely portable, of course) that is also blessed by the C
standard (no extensions are needed at all). It works on most hosted
implementations in current use and you'll have to resort to things like ^^^^^^^^^^^^^^
AS/400 for exceptions.

Or Cray vector systems.

Are they still "in current use"?

The conversions themselves are "blessed by the C standard"; the
semantics of using them to check alignment are not, even by
implication.

It's a quality of implementation issue: if the conversions can be
meaningfully supported, the implementors do the right thing. And on most
hosted implementations *in current use* the conversions are as trivial as
conversions between char pointers and void pointers: a bit pattern is
given a different type.

Dan

 

[Keith Thompson]

(e-mail address removed) (Dan Pop) writes: [...]
How do you check that the pointer is aligned for an integer access?
If it isn't, how do you align it?

Non-portably, of course.

Conversions between pointers and integers provide a fairly portable way
(not absolutely portable, of course) that is also blessed by the C
standard (no extensions are needed at all). It works on most hosted
implementations in current use and you'll have to resort to things like ^^^^^^^^^^^^^^
AS/400 for exceptions.

Or Cray vector systems.

Are they still "in current use"?

Yes. We don't have any at SDSC, but I have accounts on a couple of
SV1s at other sites.

It's a quality of implementation issue: if the conversions can be
meaningfully supported, the implementors do the right thing. And on most
hosted implementations *in current use* the conversions are as trivial as
conversions between char pointers and void pointers: a bit pattern is
given a different type.

Conversions between pointers and integers are just reinterpretations
of bit patterns on Cray vector systems too, which means you're going
to shoot yourself in the foot if you treat the result as if it were an
index into a byte array.

(A reminder for those just tuning in: on a Cray vector system, a
machine address points to a 64-bit word. The C compiler uses
CHAR_BIT==8 for compabitility. A char* pointer consists of a word
pointer with a byte offset in the otherwise unused high-order 3 bits;
byte accesses are handled in software.)

Certainly the vast majority of hosted implementations incurrent use
aren't AS/400s, Cray vector systems, or anything else as exotic. But
my guess is that systems on which a char* converted to an integer
can't be tested for alignment by examining the low-order bits are
roughly as common as systems on which a null pointer is something
other than all-bits-zero. I wouldn't use memset() to set a bunch of
pointers to null unless I had a very good reason, and I'd carefully
document that the code is non-portable. I wouldn't use the low-order
bits of the result of a pointer-to-integer conversion to check the
pointer's alignment unless I had a very good reason, and I'd carefully
document that the code is non-portable.

I'm not arguing against non-portable code, but it's important to
recognize that it's non-portable, even if it works on 99.9% of current
systems.

I suspect we're actually in agreement on most or all of this.

 

[Mark McIntyre]

Except in c.l.c we deal with portable code, and leave those things
to system specific newsgroups.

Statements such as "most implementations provide reasonable and expected
conversions between pointers and integers" are entirely relevant to this
newsgroup [comp.std.c],

Maybe. But CBF was (and I am) reading this in comp.lang.c, where such
discussion is NOT topical. CBF even noted in his reply where he was reading
it.

 

[Dan Pop]

Conversions between pointers and integers are just reinterpretations
of bit patterns on Cray vector systems too, which means you're going
to shoot yourself in the foot if you treat the result as if it were an
index into a byte array.

(A reminder for those just tuning in: on a Cray vector system, a
machine address points to a 64-bit word. The C compiler uses
CHAR_BIT==8 for compabitility. A char* pointer consists of a word
pointer with a byte offset in the otherwise unused high-order 3 bits;
byte accesses are handled in software.)

There are two different approaches used by C implementations on Cray
vector processors. The second one has the byte offset in the 3 least
signficant bits of the pointer, thus emulating a platform with genuine
byte address support. It simplifies pointer arithmetic on character
pointers and it makes pointer to integer conversions meaningful on
that platform, too. I think Dennis Ritchie mentioned it in a comp.std.c
post.

I'm not arguing against non-portable code, but it's important to
recognize that it's non-portable, even if it works on 99.9% of current
systems.

And, since I wrote "as portable as reasonably possible" upthread, I fail
to see your point: I neither claimed nor implied that such code is
absolutely portable.

Dan