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
}

[Flash Gordon]

jacob navia wrote:

Peter Nilsson wrote:

The conversion to and from intptr_t is implementation defined.
This method may well fail to do what's expected on some (real)
machines.

The C standard says (page 256)
<<
The following type designates a signed integer type with the
property that any valid pointer to void can be converted to
this type, then converted back to pointer to void,
and the result will compare equal to the original pointer:

intptr_t

<<

1) It is *not* optional.
2) If it fails to do what is specified this is a broken
implementation.

Has this changed from N869 then, which goes on to say "These types are
optional." ?
The current C standard is C99. Of course there are people
that want to destroy C and make it go back to 1969
when it didn't exist. I hope you are not one of them.
Wanting people to know that almost all compilers do not support the
latest standard is not the same as wanting the language to die.
What I fail to understand are the people that always
speak about "Standard C" but they mean some inexistent
standard. The C89 Standard doesn't exist any more.

It was replaced by the current one.

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.

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.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[jacob navia]

Christian Bau wrote:

2) If it fails to do what is specified this is a broken
implementation.

Apparently not.

Very easy.

Just say

"apparently not".

Not that you would bother to give any
ARGUMENTS why intptr_t would be OK when not doing what
it should do or in which machine/implementation that
doesn't work.

Maybe in a ternary machine using 45.87bits per byte
where sizeof char is 7.9 that would not work isn't it?

[jacob navia]

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.

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.

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.

OK. Then how would you implement portably

<inttype> p = (void *)p;

?????????

[jacob navia]

Richard Tobin wrote:

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

What I fail to understand are the people that always
speak about "Standard C" but they mean some inexistent
standard. The C89 Standard doesn't exist any more.

Standards are for our benefit, not the standards bodies'. If we
continue to use C89, it still exists.

Of course. It is not standard C though.

It is obsolete C.

But you are free to use it. Microsoft Corp has the same
view.

[jacob navia]

Walter Roberson wrote:

In article <42************ *********@news. wanadoo.fr>,
jacob navia <ja***@jacob.re mcomp.fr> wrote:
:The current C standard is C99. Of course there are people
:that want to destroy C and make it go back to 1969
:when it didn't exist. I hope you are not one of them.

:What I fail to understand are the people that always
:speak about "Standard C" but they mean some inexistent
:standard. The C89 Standard doesn't exist any more.

:It was replaced by the current one.

Tell me, did your house / apartment stop existing when they
last revised the relevant Construction Code [e.g., required
that certain kinds of nails be 1mm thicker] ?

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.

Of course I can go on living in my house without bothering about
standards. Only if I got a problem, the insurance could argue that
I was using a non-standard nail size and if my roof collapses
that is not covered by their contract.

[jacob navia]

Keith Thompson wrote:

You're complaining about someone mentioning that intptr_t is specific
to C99. Would you prefer that we post answers that assume everyone
has a C99 compiler, so they can come back and ask us what's wrong when
it doesn't work with their C90 compilers?

You are to a certain point right. I should have mentioned this in my answer.

What I fail to understand are the vague suppositions like:

"It may not work in some machines", without any qualifiers.

Besides, this stuff starts to become a self-fullfiling
prophecy. If everyone says the C99 standard is dead, it may
very well be.

It is implemented in several compilers. You can have under
linux gcc, and under windows you get lcc-win32 or Intel,
as far as I know. So, for many desktops machines this can
be solved. For the embedded systems this is another story.

jacob

[Mark F. Haigh]

jacob navia wrote:

Christian Bau wrote:

2) If it fails to do what is specified this is a broken
implementation.

Apparently not.

Very easy.

Just say

"apparently not".

Not that you would bother to give any
ARGUMENTS why intptr_t would be OK when not doing what
it should do or in which machine/implementation that
doesn't work.

Now, now, let's take a deep breath, and quit being so hostile.
*Apparently* an implementation that does not define intptr_t is *not*
broken.

Thus, "Apparently not". Capische? Is that so terrible?
Maybe in a ternary machine using 45.87bits per byte
where sizeof char is 7.9 that would not work isn't it?

No need to get uppity. Christian's regular and generally accurate
posts are undeserving of your sarcastic disregard.
Mark F. Haigh
mf*****@sbcglob al.net

[Mark F. Haigh]

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.

<snip>

Yeah, it does. "Foo" is valid C89. "Bar" is valid C99. What's so
hard to understand about that?

In theory you may be right. In practice, it's nowhere near as
difficult as you make it out to be.
Mark F. Haigh
mf*****@sbcglob al.net

[Walter Roberson]

In article <42************ *********@news. wanadoo.fr>,
jacob navia <ja***@jacob.re mcomp.fr> wrote:
:Walter Roberson wrote:
:> Tell me, did your house / apartment stop existing when they
:> last revised the relevant Construction Code

: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.

It isn't uncommon for the Construction Code to change every few months.
National fire code, state/provincial codes, municipal codes, some set
forth in the form of laws and others merely in the form of regulations
that can be changed by a staff member at City Hall.

Except in rare instances, changes in the Construction Code do *not*
require renovations, because most changes are "grandfathe red" --
meaning that they only apply to -new- work done.

Retrofitting is usually only required for serious health threats, such
as asbestos; urea formaldehide foam (and even that stayed legal in
sealed installations); dioxin-filled transformers; or the use of very
thin aluminium wiring.

--
Usenet is like a slice of lemon, wrapped around a large gold brick.

[Walter Roberson]

In article <7k************ *************** *****@4ax.com>,
<no*@given.ou t> 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?

If one writes a program that requires the extensions, then the program
is only as portable as the compiler is.

If one programs without the extensions, then the extensions were not
needed.

The point of standards is to have a common base, and that any program
that meets the standard (and which takes into account implicit hardware
dependancies such as characters not always being 8 bits) can be used
without change elsewhere, saving the time necessary to adapt, re-write,
and re-test.
--
Walter Roberson is my name,
And Usenet is my nation.
Cyber space is my dwelling pace,
And flames my destination.