set and reset the least significant bit of a address

[onsbomma]

I want to set and reset the least significant bit of a address (where a
pointers points to).
I tried this, but it is not correct:
#define BIT 0x1

void foo(){
void *p;
*p = *p & ~BIT
}

[Dan Pop]

In <42************ ***********@new s.wanadoo.fr> jacob navia <ja***@jacob.re mcomp.fr> writes:

Flash Gordon wrote:

Unless someone has gone around deleting all copies of the old standard
it still exists. It just is not the official current standard, only the
standard that actually is implemented.

Of course you and the old standard exist.
I wouldn't discuss that.

But "standard C" then, makes no sense.

What you fail to realise is that "standard C" has a context-dependent
meaning, because the *relevant* C standard is different in different
contexts. There is no question that the relevant C standard for
comp.std.c is C99. OTOH, c.l.c is dedicated to portable programming
in the real world, where the C99 standard is still a pipe dream (with
insignificant exceptions).

Furthermore, optional C99 features cannot be used in portable C99
programs, either.

Since, as you have been told before, we deal with portable C it is
important to know which version of the standard is applicable when it is
not the most commonly implemented one.

Ahh not standard C but portable C.

It is adherence to a C standard that makes C code portable.
OK. Then how would you implement portably

<inttype> p = (void *)p;

?????????

By issuing the diagnostic *required* by the (C89/C99) standard.

BTW, implementations need not be portable (and I'm not aware of
any portable implementations , merely of implementations that can be
easily ported).

Dan
--
Dan Pop <Da*****@ifh.de >

[Richard Tobin]

In article <42************ *********@news. wanadoo.fr>,
jacob navia <ja***@jacob.re mcomp.fr> wrote:

If the construction code changed the standards for nails
and my appartment has the old nails, my appartment is then
NOT STANDARD, and when I sell it, or for the insurance claims
I am supposed to change the nails.

That's certainly not the case in this country.

-- Richard

[Walter Roberson]

In article <42************ ***********@new s.wanadoo.fr>,
jacob navia <ja***@jacob.re mcomp.fr> wrote:
:Ahh not standard C but portable C.

:OK. Then how would you implement portably

: <inttype> p = (void *)p;

You don't.

I must admit that I fail to understand the point. Even supposing there
is a portable, standards-conforming way to reversibly convert between
an void* and an integral type, as soon as one modifies even a single bit
of the integral representation, one loses all guarantees that the
back-conversion will point to anything. Clearing the last bit of
a pointer could result in a pointer to something before the object
(e.g., a char with automatic storage class is not necessarily stored
at an even address); the resulting pointer would be completely
unusable as far as C is concerned. Setting the last bit of the
integral type and back-converting could result in a pointer
past the object (which cannot be derefenced, but at least can be
compared in some circumstances.)

And of course there is the possibility that the integral representation
of the pointer could be an opaque token. The verbage in the standard
about increasing addresses within an object does -not- imply that
pointers to successive values will have values that are numerically
related to each other. It would, for example, be valid for the
numeric representation of a pointer to be bit reversed and for there
to be segment or type information suffixed. The requirement even when
the conversion exists is only that the conversion be reversible, not
that the converted value have any particular internal structure.
--
Warning: potentially contains traces of nuts.

[Flash Gordon]

jacob navia wrote:

Flash Gordon wrote:

Unless someone has gone around deleting all copies of the old standard
it still exists. It just is not the official current standard, only
the standard that actually is implemented.

Of course you and the old standard exist.
I wouldn't discuss that.

But "standard C" then, makes no sense.

You want YOUR particular view of the standard, as you would like
it to be.

No, the standards as published by ISO and ANSI. Also, on rare occasions,
C as it was before the ANSI standard was published.
When implementing the extensions of lcc-win32 I cared to
remain compatible with the standard. But when I discuss them
a holy alliance of people like you start crying

"Standard C, Standard C"

Now, the same people write:

The standard is what I want it to be. I will use this
standard, that standard, etc.
This group allowing discussions of all versions of the standard, and
both hosted and non-hosted implementations , is nothing new. The
difference is that *your* extensions are not covered by *any* C standard
that has been published or by what C was before the first ANSI standard
was published.

Since, as you have been told before, we deal with portable C it is
important to know which version of the standard is applicable when it
is not the most commonly implemented one.

Ahh not standard C but portable C.

C89 is still a standard, just not the latest version of the standard.
OK. Then how would you implement portably

<inttype> p = (void *)p;

?????????

Obviously I have absolutely no idea what it is intended to do since it
is just a syntax error in C.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Chris Croughton]

On Wed, 16 Mar 2005 05:52:02 -0500, no*@given.out
<no*@given.ou t> wrote:

Yes, compilers, languages, even some user stuff, should be held to something
of a standard. But shouldn't that standard be a _minimum_ instead of an
exact target? If we all adhere to C-89 where's the growth and improvement
in the language and, by extension, our code? It makes far more sense to me
for compiler writers (and I'm not one) to push the limits always seeking
newer and better ways of doing things. So long as that minimum standard is
met, what's the problem?
The problem is that anyone using the extensions is then locked-in to
that compiler, unless the compiler writer can persuade other compiler
writers to use it.

Take, as an example, GCC's implementation of macros with variable
numbers of arguments. It was a great extension, allowing you to write
things like:

#define eprintf(format, args...) fprintf (stderr, format , ## args)

eprintf("stuff\ n");
eprintf("stuff= %d\n", 42);

The only trouble is, if you try to compile that with any other compiler
(MS, Borland, Intel, etc.) it will fail to compile, because it isn't
standard. In practice, a lot of code uses it because GCC is one of few
compilers with a lot of ports on different platforms and targetting many
processors, but that doesn't mean that it will always be there even in
that compiler (with the C99 __VA_ARGS__ feature the GCC one may become
obsoleted). Or case ranges (a useful feature which didn't get into
C99).
For example... I would love to see a C implementation (not c++ or C#...
basic C99) with real string variables. And why not? So long as the
compiler meets some agreed minimum standard, what's wrong with going beyond
that?

As long as you know that (a) your code is never going to be used on
another compiler and (b) the compiler you use is always going to be
around for as long as that code needs to be compilers, there's nothing
wrong with it. But compilers go out of date and are dropped or not
ported to a modern platform (especially when they are proprietary source
code so if the original maintainer drops it -- or in some cases drops
dead -- it is lost), and you are stuck with source which no longer
compiles because it is using extensions to the language. Or which no
longer compiles for the new processor.

People who use the extensions of a particular compiler tend to forget
after a while that they are extensions, and so become less good at
writing standard-conforming programs (writing C++, for instance, does
this as well, I'm always doing things like trying to declare variables
in the middle of code).

Chris C

[jacob navia]

no*@given.out wrote:

For example... I would love to see a C implementation (not c++ or C#...
basic C99) with real string variables. And why not? So long as the
compiler meets some agreed minimum standard, what's wrong with going beyond
that?

Lcc-win32 supports a "real" string package, with length delimited
strings, but it needs one extension: operator overloading.

Otherwise, the functions are almost the same:
Strcat, Strcmp, etc.

jacob

[CBFalconer]

no*@given.out wrote:

jacob navia <ja***@jacob.re mcomp.fr> wrote:

Lcc-win32 supports a "real" string package, with length delimited
strings, but it needs one extension: operator overloading.

Yep, saw that in my travels... but alas it also lacks a function I
need in my day to day work... there is no try-finally construct
(or, more accurately, there is no *documented* try-finally
construct).

Then what are you doing here? C doesn't support those either. You
may want either Ada or C++.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[jacob navia]

no*@given.out wrote:

On Thu, 17 Mar 2005 00:40:31 GMT, CBFalconer <cb********@yah oo.com> wrote:

Then what are you doing here?

Mostly, I'm reading and learning. Is that a problem?

Or have I perhaps enfringed on someone's protectorate?

But not to worry... I'm not fond of handing around places where people have
the wagons so tightly circled that even a wrong nod can get one into
trouble.

Unsubscribing now.

Well, Chuck is special... he doesn't mind it as an offense.

Just do not overreact.

[onsbomma]

Peter Nilsson wrote:

onsbomma wrote:
.> I want to set and reset the least significant bit of a address
.> (where a pointers points to).
.> I tried this, but it is not correct:
.>
.> #define BIT 0x1
.>
.> void foo(){
.> void *p;
.> *p = *p & ~BIT

Ignoring that p is not initialised, dereferencing a void pointer
is a constraint violation. Use a pointer to unsigned char if you
want to modify a byte.

And how should I do that??
Just making it
void foo(){
char* p;
p = p & ~BIT
}

won't work

[Walter Roberson]

In article <11************ ***@seven.kulne t.kuleuven.ac.b e>,
onsbomma <on******@hotma il.com> wrote:
:Peter Nilsson wrote:
:>>onsbomma wrote:
:>>.> void foo(){
:>>.> void *p;
:>>.> *p = *p & ~BIT

:> Ignoring that p is not initialised, dereferencing a void pointer
:> is a constraint violation. Use a pointer to unsigned char if you
:> want to modify a byte.

:And how should I do that??
:Just making it
: void foo(){
: char* p;
: p = p & ~BIT
: }

:won't work

In the first version, you had *p = something so you were dereferencing the
pointer. In this newer version, you are modifying the pointer instead of
what it points to.

It isn't at all clear to me what you are trying to do, since it is
not apparent in the code snippet that p has a value (just declaring
it on the stack doesn't give it a value), and it is not apparently
how you are testing whether changing it has done anything or not.
I don't think that snippet would even compile, since '&' is not a
defined operator on pointers.

If you want to modify a pointer itself in ways other than can
be done by using ++ or -- or += or -=, then you need to convert
the pointer into an arithmetic type. As I discussed earlier, the
C language makes no promise that the converted pointer will have
any resemblence to a meaningful address: at most (C99) it promises
that the conversion is "reversable ". C89 does not even promise that
(though K&R2 does.) The only reversable pointer operation defined
in C89 that I could find, is printing and scaning a pointer with %p
format.

There is, though, one portable thing you can do: if the
object being worked with is a pointer returned by malloc() then
the pointer will be aligned for use with native objects with the
tightest alignment requirements. If you take a copy of that
initial pointer, and later take the difference of that
pointer and the test pointer ('p' in your code), both cast
to (char *), then the difference will be in bytes and the
difference can be tested for evenness or oddness. That will
tell you whether the test pointer is logically even or odd
*if* the platform constrains even one of the primitive types
to even addresses. However, if the platform happens to be
one in which there -are- no alignment restrictions on the
native types, then malloc() could return an odd value and
examining the difference would not be useful.
--
Would you buy a used bit from this man??