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
}

[Keith Thompson]

Chris Croughton <ch***@keristor .net> writes:
[...]

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.

Actually, it will compile with Intel's compiler (at least with release
8.0 on Linux/IA64), because Intel has chosen to make their compiler
compatible with gcc.

This does not, of course, contradict your point.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

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

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.

Some things are implementation-dependent in various ways, even
assuming full compliance to the C99 standard. In such cases, it's
perfectly appropriate to point out that a construct is non-portable,
even without necessarily saying which platforms it will or won't work
on.

For example, the standard (either C90 or C99) does not guarantee that
there's an integer type large enough to hold a pointer value, so any
code that assumes there is such a type is non-portable -- but I
couldn't name an existing implementation that doesn't have such a
type. (AS/400, maybe?)

On the other hand, some things are supported by C99 but not by C90 --
and, like it or not, there are plenty of compilers in common use that
don't support all of C99. If someone asks about int32_t, it is
absolutely worth pointing out that it's a C99 feature (that some, but
not all, pre-C99 implementations may support as an extension); it's
also worth pointing out that not all full C99 implementations
necessarily support it (it's optional; see C99 7.18.1.1p3).

Now if someone says that something "may not work in some machines"
without any qualifiers, you might have something to complain about.
It's important to undertand why something isn't necessarily portable.
But I don't recall anyone making such a statement -- in particular,
the statement you complained about in this thread was qualified.
Besides, this stuff starts to become a self-fullfiling
prophecy. If everyone says the C99 standard is dead, it may
very well be.
"Everyone" does not say that C99 is dead. A few people here may make
statements that almost approach that; most of us merely acknowledge
the reality that the C99 standard hasn't caught on as quickly as the
C90 standard did. Please stop exaggerating.
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.

gcc does not support all of C99. groups.google.c om indicates that the
URL <http://gcc.gnu.org/c99status.html> has been posted to comp.lang.c
27 times. I don't know the conformance status of lcc-win32 or Intel's
compiler; the former is Windows-specific, and I don't believe the
latter is freeware.

Incidentally, I can think of several reasons why the C99 standard has
not caught on as quickly as the C90 standard. In 1990, C was a more
dominant language than it is today; today, vendors probably expend
relatively more effort on C++ and other languages. The C89/C90
standard introduced protypes, which were (IMHO) a great improvement
over old-style function declarations; C99 doesn't have anything that's
such a clear improvement. ANSI C89 was the first C standard, and it
made it much easier to write reasonably portable code; C99 is
replacing an earlier standard, not filling a void.

Having said that, I personally would *like* to see C99 catch on. And
if nothing else, it provides a direction for compiler development;
anyone implementing support for complex numbers, for example, in a C
compiler is likely to follow the C99 definition rather than invent
something new.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris Croughton]

On Fri, 18 Mar 2005 05:49:49 GMT, Keith Thompson
<ks***@mib.or g> wrote:

Chris Croughton <ch***@keristor .net> writes:
[...]

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.
Actually, it will compile with Intel's compiler (at least with release
8.0 on Linux/IA64), because Intel has chosen to make their compiler
compatible with gcc.

Ah, a later version than I'd used. I should have said "may well fail",
Intel isn't the only compiler with explicit support for gccisms (MS and
Borland don't, though nor as I remember does the Metroworks one).
This does not, of course, contradict your point.

Indeed, but I could have phrased it better.

Chris C

[Dan Pop]

In <7k************ *************** *****@4ax.com> no*@given.out writes:

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?

Nothing, as long as:

1. The extensions don't intrude the user's name space when the compiler
is invoked in conforming mode. In other words, they don't break any
existing, portable code.

2. They are NOT discussed/advocated in a newsgroup dedicated to
*portable* C programming.

Practically all of us are using extensions of one kind or another in our
real life C programs (for reasons more important than mere convenience),
yet we don't discuss them here. For actual extensions, there are
newsgroups dedicated to programming on the platforms supporting them,
for proposed extensions, there is comp.std.c.

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

[Walter Roberson]

In article <u4************ *************** *****@4ax.com>,
<no*@given.ou t> wrote:
|On 16 Mar 2005 11:08:42 GMT, ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson)
|wrote:

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

|If one writes a program that requires the extensions --> without considering
|portability <-- then the program is only as portable as the compiler is.

|Just because an extension is present in the language, doesn't mean we can't
|"write down" to a platform/compiler that doesn't support the extension.

If you -can- "write down" to a portable version, then the program did
not -require- the extension, and so the extension need not have been
present in the first place. One might as well write in the portable form
except perhaps for some isolated sections in which going with the
more intrinsic form brings sufficient optimization as to be worth the
trouble.
--
Ceci, ce n'est pas une idée.

[CBFalconer]

no*@given.out wrote:

On 19 Mar 2005 01:25:23 GMT, Da*****@cern.ch (Dan Pop) wrote:

2. They are NOT discussed/advocated in a newsgroup dedicated to
*portable* C programming.

Where does it say this is a group for *portable* C programming only.

One does not get that impression from the group name, nor have I
seen anything resembling a Charter that says so.... shouldn't this
be comp.lang.c.por table?

I mean no offense here, but all I've seen is a bunch of "get lost"
messages posted over and over by the same small group of people,
and most often in response to questions the group name would
suggest are completely on-topic. Unlike a lot of other newsgroups
it seems people here play along with this ultra-narrow focus, even
though there really doesn't seem to be a general purpose C
discussion group anywhere on Usenet.

Can someone enlighten me, please?

A fair enough question. The newsgroup existed long before
'charters' were dreamed up. The group needs some limitation as to
subject, and C is a slippery thing, unless we resort to the
published international standards (and even the predecessor of
those, K&R1). By doing this we all know what we are talking about
(at least in theory :-). The consensus of the users of this group
has been and will be to maintain that narrow focus.

There are usually adequate specialized newsgroups for particular
systems, where the inhabitants do know (and agree about) what the
frogbuster() function does, and more importantly, where answers
that misuse frogbuster will be caught and corrected.

In general, if the system/compiler/hardware matters, it is off
topic here.

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

Unlike a lot of other newsgroups it seems people here play along with this
ultra-narrow focus, even though there really doesn't seem to be a general
purpose C discussion group anywhere on Usenet.

There is the minority view. I have received a lot of flames because of
this, but I go on believing that this group should discuss C beyond the
"portable" stuff.

But let's not start again a flame war...

jakob

[CBFalconer]

no*@given.out wrote:

.... snip ...
Moreover, having worked in Delphi and done a test run with c++ I'm
pretty sure OOP is not the way to do this. It's not better, it's
just easier. Underlying all those fancy visual design tools and
object methods is still a procedural core upon which the CPU itself
relies. C still underlies C++, Pascal still underlies Delphi.
That procedural languages are not progressing in the forefront of
programming is, ummm, disappointing.

Let's just take your own example - Pascal and Delphi. While the
Delphi system is much nicer than its competition for many purposes,
it is not portable. This is largely because the underlying
language is not portable. Delphi does not adhere, nor even
implement, the well published Pascal standard (which antedates
Delphi and I believe even Turbo Pascal). The result is that the
system is moribund. People want their systems to port easily to
Linux, Sun, whatever. Code developed for Delphi is useless for an
embedded system running on an ARM. It is restricted to machines
using an x86 processor and running an inferior and insecure
operating system.

This is not the fault of the language Pascal, as standardized in
ISO7185 and ISO10206 (for extended Pascal). The important
difference from C is that the C implementations have adhered to the
C standard, albeit with extensions.

There is no restriction on extensions to either Pascal or C. They
are just not standard. To allow them to be used the complete
_standard_ code to implement them has to be published. If they are
system specific then their characteristics have to be published,
and they will not advance anything on other systems without
re-implementation.

If you want to discuss modifications to the standard, comp.std.c
exists. If you want to discuss things to do with Unix or Posix or
Linux or Windoze, newsgroups with those systems in their names
exist.

If you want an improved string facility, there is no impediment to
designing and publishing one. Just make sure it is implemented in
portable standard C. In at least one such attempt known to me the
portability is highly suspect, because the author is known to make
unwarrented assumptions. However give up the idea of replacing the
existing abilities, because that would break existing code and
render such a standard unacceptable.

An example of extensions is strlcpy and strlcat. These are not my
idea, but I have published an implementation of them, together with
links back to the originators and their rationale. I would like to
see these in the next revision of the standard. Until that happens
they won't be routinely used. See my site, download section, URL
in Organization field of header.

--
"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

[CBFalconer]

no*@given.out wrote:

.... snip ...
I don't bemoan the urge for some regulation. It's necessary to
keep any newsgroup from degenerating into simple chaos... but
where does one go to discuss progress in the language?

Try comp.std.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

[CBFalconer]

no*@given.out wrote:

.... snip ...
When I retired, just before Christmas 2004, I went language
hunting, looking to make programming into a hobby to fill my time
(and maybe make a couple of bucks here and there). What I found
was unbelievable... No real progress has been made since I
learned Pascal in the early 80s. Yes there's OOP, a magical way
of turning a 200k utility into a 5meg monster. Yes, there's RAD
and Visual tools, but they're mostly about laziness. But in all
the art and science of programming is still today what it was when
I wrote my first version of "Hello World" more than 20 years ago.
What you learned in the '80s was probably not Pascal, because the
prevalent flavor was Turbo, which doesn't even implement Pascal and
has seriously damaged the language.

You should probably look into Ada. And you should definitely move
this subject, possibly to comp.programmin g. A query about
topicality is fine, but long winded grousing about the answer will
just get you PLONKED.
I looked at C, C++, D, Delphi (again) and a dozen offshoots of
each. Mostly I was flat out disappointed at the near-total lack of
documentation for any of them. I can get compilers to do almost
anything... but I have to figure out how they work all by myself.
One, in particular, was a perfect example: Smallish download, unzip
to install... one file: "mystery.exe".. . no documentation, not even
a language definition, just "here's johnny" and I'm supposed to
know what to do with it.

They have no standard. Look into Ada, it has a well defined
standard. The presence of gcc has taken the profit out of compiler
development, which is both good and bad.

--
"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