Keith Thompson said:
Tim Rentsch said:
First let's see if we can fix the definite bugs (not counting any
possible problems with casting a pointer to an unsigned int, I count
at least three), and clean the code up a bit:
[snip]
[snip]
if( (unsigned int)s % K == 0 ){
Now let's return to the question at the start of the posting.
Even though the method of testing pointer alignment in the code above
isn't guaranteed to work, the fact is that it will work on many
architectures (probably most architectures, but I expect that depends
on how the counting is done). Since this is so, why not provide a
standard means of checking for it? There could be a C preprocessor
symbol, eg, SINGLE_LINEAR_ADDRESS_SPACE, that could be used to mean
that pointers look like integers. Something along these lines could
be written into the standard to provide a conformant means of writing
code to do this kind of pointer manipulation. Make sense?
I suspect that would encourage programmers to write code that only
works if SINGLE_LINEAR_ADDRESS_SPACE is true. (Too many programmers
do that already, of course.)
Notice the argumentative sleight-of-hand. An opinion is presented
without any reasoning or supporting evidence, then subsequent
discussion implicitly gives the opinion the status of fact.
On the contrary - if something like SINGLE_LINEAR_ADDRESS_SPACE were
written into the standard, then the sort of people who know about such
things would likely provide a specialized implementation for those
systems that had it defined as 1, and a more mundane implementation
(or just an outright error) for those systems that had it defined
as 0. And of course people who didn't know about it wouldn't change
their behavior. In either case the situation is no worse off then
before, unless of course someone thinks that people knowing about
the flag will be encouraged to write code that depends on it being
true and NOT checking for it. That seems a little silly.
Moreover, the presence of such a standard-defined flag would mean
that a system could give a diagnostic for code that seems to make
such assumptions on a system where SINGLE_LINEAR_ADDRESS_SPACE is
defined to be 0. For that matter, compilers could give a diagnostic
for code on *any* system that has code using SLAS-specific behavior
and not wrapped in a '#if' or 'if' testing SINGLE_LINEAER_ADDRESS_SPACE.
I'm not suggesting that such tests be made mandatory, only that they
could be put in place if some compiler writers chose to - and surely
that would *raise* consciousness about what assumptions are reasonable
to make when trying to write portable C code.
Of course you can implement such a preprocessor symbol yourself, and
configure it for each system. It's a little extra work, but frankly
it probably should be.
Another unsupported opinion, and a statement that's just plain false.
It's not a little extra work, it's quite a bit of work, and
furthermore one that most people simply don't have the resources to
support. I for one do not have access to many of the different,
unusual machine architectures to know how they should be labelled;
I doubt most people reading this newsgroup do either. (For the
record that last statement was my opinion - I welcome people who
do have such access to chime in with some evidence.)
Currently, if I write portable code that will work even for a
non-linear address space, I can recompile and run it on a
"non-lineary" system and it should work.
The presence of a standard-imposed definition of SLAS wouldn't change
that. It would give you the option of writing specialized code that
ran only on such systems, presumably with some performance gain, and
using the non-SLAS code as fallback on other systems. And your code
would still be portable to all the machines it was before.
An example of a system where SINGLE_LINEAR_ADDRESS_SPACE would be
undefined is a Cray vector system, where a machine address points to a
64-bit word. The C compiler has CHAR_BIT==8 to allow for code
portability, but a char* pointer has a 3-bit offset in the top of the
word. Well written portable code works just fine. Code that makes
assumptions about how pointers are represented doesn't. (The systems
run a Unix-based OS, and most Unix-based software compiles and runs
correctly, so the lack of ability to do that kind of low-level pointer
manipulation hasn't been much of a problem.)
What bugs me here is the phrase "code that makes assumptions....".
The whole point of an SLAS-like proposal is to provide a means whereby
code doesn't "make assumptions" but relies on some standard-defined
behavior to enable certain kinds of code in some situations.
Incidentally, the description of the Cray character addresses is
perhaps interesting, but not especially relevant after the first
sentence. If SLAS were "off" on the Cray, then code that depended
on SLAS being "on" wouldn't be present.
Of course something like memcpy() can be made much more efficient if
it can detect pointer alignment and copy word-by-word whenever
possible. That's why memcpy() is in the standard library, where it
can be implemented with non-portable code.
There are basically two paths we can think about going down here.
One, we can relegate all system-specific behavior to library
functions, and make the library ever larger as more and more functions
are argued about and agreed to in the standards committee. Or, two,
we can try to provide some definitions in the language environment
that allow some system-specific -- but still universally conformant --
code to be written without having to wait for the right library
function to appear. Whether it is a SINGLE_LINEAR_ADDRESS_SPACE
symbol or some other similar mechanism, the second path seems better
than the first path.
Perhaps this should have been posted on comp.std.c rather than
comp.lang.c (or perhaps both). It seemed better to continue
the thread in the group it started, and comp.lang.c seems
at least reasonably appropriate. If anyone has some comments
on that, please feel free to send them to me directly in email.
thanks.
There is the modified one,