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 <g4************ *************** *****@4ax.com> no*@given.out writes:

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.

In the periodically posted "Welcome to comp.lang.c!" article.
This article reflects the quasi-consensus of this newsgroup's regulars.

There are extremely few non-portable C programming issues that aren't
(much) better discussed elsewhere.

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

[jacob navia]

I find what you say very good. Your viewpoint is almost exactly mine.

jacob

[jacob navia]

Standard or not, Delphi was a highly successful programming
language.

If you use windows, Delphi was very portable :-)

[Chris Croughton]

On 19 Mar 2005 05:31:15 GMT, Walter Roberson
<ro******@ibd.n rc-cnrc.gc.ca> wrote:

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.
.... for that program. The existence of the extension may well be
essential for some other program, or for implementing the C libraries
and headers, or for compiler optimisations (like the common use of
builtin intrinsics which the compiler can optimise into fast processor
dependent code).
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.

Indeed, and most good programmers automatically encapsulate
system-dependent features into a small area which can easily be
reimplemented if necessary when porting to another system. I generally
program with -ansi -pedantic -W -Wall (or their equivalent) on for as
much of my code as I can, leaving off the pedantic part for a few
modules which have to do system-dependent things (directory searches,
file locking, low level peripheral and display access, etc.).

Chris C

[Chris Croughton]

On Sat, 19 Mar 2005 11:05:26 -0500, no*@given.out
<no*@given.ou t> wrote:

As I neared retirement, I wanted out of the heavy lifting and pulling cables
through musty ceiling tiles so I naturally gravitated towards software. I
first grabbed Delphi and started trying to learn it. I hit the wall with
that in about 6 months, I can't even begin to explain how totally
unimpressed I was. I dug out the underlying Pascal and started working in
it. 4 years and a couple of pretty big projects later, a primal flaw in the
implementation exposes itself and I'm in real trouble. I fix the problems
(of course) but now I am thoroughly disgusted with the language...
Well, Pascal is a very good example of "why not to write extensions".
Pascal as originally designed was a teaching language, and among other
things it specified that all input files were read before the program
was started and all output files were written after it ended. Not
exactly easy to write interactive programs! To start with all the code
was in one source module, as well. So what happened was that each of
the implementors added their own extensions to make it usable, all (of
course) incompatible. So we had Turbo Pascal, MS Pascal, Intel Pascal,
etc., all incompatible unless you wanted to write "Hello World". And
out of that came Delphi, which is only a de facto standard because
virtually all of the other variants died.
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.
Oh, only 20 years ago. OK, perhaps it hasn't changed so much since
then. Except for what has disappeared (apart from a few diehards):
Algol, Modula (remember when that was going to be the "new Pascal?"),
Coral, COBOL; Fortran is hanging on but is virtually unrecognisable to
someone who learned FORTRAN IV; Ada is used only in obscure bits of the
defence industry. Oh, we've added Java, C++ (although that started
earlier) and C#, which are all very much dialects (from a linguistic
point of view) of C and C With Objects.

But what does that signify? Possibly that language design has gone as
far as it needs to? The emphasis now is on design, data manipulation,
interfaces and communication, rather than on the "nuts and bolts" of
whatever language you use. Look at UML, for instance, that is language
independent, the actual code could be in assembler for all anyone cares
because it's the design which matters.
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.
As far as C and C++ are concerned, that's rubbish. There's masses of
documentation. Granted, it doesn't come with the compilers, but that's
because the languages are standardised, you can buy any book on C and it
will describe the same language (OK, avoid Schildt's one and anything
"for dummies"). The same for C++. The standards for both C and C++
cost $18 for the PDF versions.
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.
What language is "mystery.ex e" supposed to compile? If you will
download some random stuff off the net, I'm not surprised you can't find
any documentation (I am surprised that it didn't do something nasty like
install a pack of viruses). Try any of the real compilers -- gcc, for
instance, or Borland's (even Microsoft's), they'll tell you how to run
the compiler. Borland and MS even come with help files in their
development environments where you han just hover over (or hit F1 on) a
keyword or function name and get help on it.
Ok, says I, Usenet has every topic imaginable... lets try that. So I
settles on Pelles C, which is far better documented than most, but I still
need some help getting started... Pelle runs a nice set of forums and he is,
himself, very helpful, but I'm still looking to see discussion and example
that I can't possibly ask him to provide.
I've never heard of Pelles C, but apparently it is some other language
"based on C" (like Mr. Navia's one). As people have said, almost all
implementations do contain extensions, but if you want to know about
those you need to look at a specific forum or documentation for that
compiler (if you do info gcc, for instance, one of the sections is about
extension to the language).
Can you imagine my disappointment when I am rebuffed for discussing some of
the better features of Pelle's work? Told, in no uncertain terms, that
"these are not standard features of C and we aren't going to talk to you
about them."... by the very people who seem most in the know...
Because we don't know anything about this Pelle guy or his extensions,
and they aren't relevant to standard C. If we said "oh, that's
wonderful, pity none of us can use it", would that help? We still
couldn't talk about it meaningfully without getting his compiler and
documentation and evaluating it, and few of us have time to do that.

If you want to discuss specific features of his compiler, you know where
his forums are apparently. If you think that they are a worthwhile
thing to add to the language, go to comp.lang.c and try to convince the
people there, that's where future language directions are discussed.
I recognize your name Jacob, you've written compilers... you're the kind of
person I'd love to discuss C tips and techniques with... but apparently not
here. And since there doesn't seem to be anywhere else, well... it's back
to trying to find a new language.

comp.lang.misc
comp.compilers
comp.compilers. lcc (I assume that includes Mr. Navia's one)
comp.std.c (future language directions)

Looking for Pelles C using Google, I see that it's another one based on
LCC as is Mr. Navia's compiler, so that should be on topic on
comp.compilers. lcc as well.

If you want to discuss standard C, however, as it is and not as some
language you might like to use which isn't C, you're welcome to do so
here...

Chris C

[Walter Roberson]

In article <du************ *************** *****@4ax.com>,
<no*@given.ou t> wrote:
:This is progress, the language is dynamic, always changing and progressing.
:Without this, we end up programming by decade old rules on machines far more
:capable than the ones the rules were written for; in effect holding back
:progress in the very industry we support.

That is more or less BS. The last I read, researchers still aren't able
to hold more than 3 quantum transistors stable simultaneously -- so
unless you want to count DNA programming (which does actually work,
if you are willing to get into wetware), then you are still firmly in
the realm of Turing Completeness, which can be summarized as
"Anything that can be computed in one sufficiently powerful logic
system can be computed in any other sufficiently powerful logic system."
"Machines" are NOT "far more capable" than 20 years ago: they are only
far -faster- (and have some interesting extensions to their I/O interfaces.)

:Hardware reaches new generations
:in a matter of months,

*Snort*. Continents reach new positions "in a matter of years".

Read the durned press releases about inventions like new transistors
and computing on amorphous silicon: the usual timeline to take them
out of the lab into *any* product is a minimum of 5 years, and the
usual timeline given before they expected to find their way to
any kind of consumer product is a decade.

It's the old story about the singer that toils in obscurity for
25 years before becoming "an overnight success". What you see is the
Pop Culture of electronics, not the Practice! Practice! Practice!
that proceeds it.
:many programming languages are still essentially
:where they were in the early 80s. Where software once drove hardware,
:demanding progress, we are now approaching a point where the situation is
:reversing... hardware is now driving software. It would be a mistake to not
:keep up.

This is known as "The Software Deficeit". Hardware -is- getting faster
(but with much much higher time latencies than you are observing),
and it is true that software is not keeping pace. This is a signficant
concern to some very bright people and is being actively investigated.

It is, though, not entirely clear to me that the situation is capable
of a meaningful solution. People thought they had the answer with
"4GL", Fourth Generation Programming Languages, which were supposed to be
simple enough thta "even managers" could write code, with all the
details being taken care of by the compiler. The result was, of course,
a lot of very bad code, and and the recognition that large programs
*are* complex and that the best that was really being done was to remove
a constant factor from the complexity analysis, rather than reducing
the inherent complexity.

I have to ask whether you are perhaps expecting too much. In Newton's
time, people were able to create a machine that broke one treelimb
in two pieces over the course of hours -- long enough that one could
be there to catch half of it. After Watt's invention of the steam
engine, and after Ford's essential implimentation of standardized
parts (based upon earlier proposals), we are now at the point that
we have machines that can grind an entire large tree into shavings
within a matter of minutes. Tree-destroying hardware has progressed.
Do you feel significant concern that Evolution hasn't seen fit to
speed up human reactions to the point where we can still catch
half of those output in our bare hands over a matter of minutes?
: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.

Well, I can tell you that adding a true String type to C would not have
made any signficant difference towards that end.

Modern procedural languages do not have significantly more expressive
power? That's like saying that Predicate Calculas should be retired
because it hasn't advanced significantly since Goedel's Completeness
Theorem of about 1933. The essential logical elements required for
programming were invented a long time ago, and haven't advanced
signficantly because they were shown to be logically sufficient. It's
like the transition from DFA (Deterministic Finite Automata) to NDFA
(Non-Deterministic Finite Automata) -- it might look wonderful on the
surface, but it turns out only be able to express the same things after
all. For software to "advance" markedly would require that something be
discovered that could not be computed with what we have now -- the
equivilent of finding that we have to go to LALR(1) grammars. Except
that Goedel and Turing and Church-Rosser have shown that there *isn't*
anything like that waiting out there for us, not until we get into
either infinities (traditional computing is not very good at producing
infinite answers in a finite time), or into non-deterministic
computations.
Do you know what the most common solution is for "fixing"
"The Software Deficeit" ? It is producing standardized library
toolkits to act as "building blocks" for programs, so that
people can fit together standardized, debugged, well-understood
tools instead of having to write from scratch so much.
And the odd thing about the mass toolkit/building-block
approach is that it relies *heavily* upon standardization ,
upon nailing down every last behaviour and saying "Things will
mean this one thing and this one thing only". Which is the
opposite of what you are advocating -- you want evolution
through the gradual adoption of non-standard components,
whose meaning and API gets defined by historical accident and
historical pressure rather than being rigerously defined by
a group dedicated to producing precise and logically coherent
foundations.

The "evolution and common adoption by the masses" approach has
already been tried: that's a capsule summary of the Microsoft
Windows family of operating systems ("You can't make us publish
API's, that would reduce our capacity to innovate!"). The fobiles
of MS Windows are legendary (but unfortunately, not mythical.)
If the future of computing is more of the same, more of MS Window's
way of operating, then IMHO computing would be in -serious- trouble.

--
Walter Roberson is my name,
And Usenet is my nation.
Cyber space is my dwelling pace,
And flames my destination.

[Chris Croughton]

On Sat, 19 Mar 2005 10:31:59 -0500, no*@given.out
<no*@given.ou t> wrote:

Then where's the progress? If we continue to write for the lowest common
denominator the language remains stagnant in perpetuity.
Well, for a couple of decades. How long has English been effectively
the same? Or French? Or Icelandic? The latter is virtually unchanged
from the Norse spoken by Eric the Red a millenium ago (it's had a few
words added, and a few minor changes, but Eric would still be able to
converse easily with modern inhabitants).
For example: I've already mentioned I would like to see an implementation
of C with real string variables. If this were done and it proved truly
useful then it should (reasonably) proliferate to other implementations
eventually reaching the point of becoming standard.
And the fact that it hasn't caught on should tell you something about
its usefulness as a language structure. Fine, you like strings, use C++
or Java (I do, when I want to do heavy string processing). But C is
used in thousands of applications where string processing is not needed,
or not in that form.
This is progress, the language is dynamic, always changing and progressing.
Always becoming incompatible, so that programs are treated as "write
only".
Without this, we end up programming by decade old rules on machines far more
capable than the ones the rules were written for; in effect holding back
progress in the very industry we support.
What is it holding back? What machine features can not be accessed
using C as it stands?
Hardware reaches new generations in a matter of months,
Only if define a 'generation' as an increment of speed or size. Most of
the really innovative designs (the Transputer, for example) have died
because they were solutions in search of a problem, there was no actual
ned for them.
many programming languages are still essentially
where they were in the early 80s. Where software once drove hardware,
demanding progress, we are now approaching a point where the situation is
reversing... hardware is now driving software. It would be a mistake to not
keep up.
What hardware features are "driving software"? I can't see any which
would need a radical rethink in software design. Indeed, the main
features affecting software are the ones which support the 'sloppy'
programming you dislike -- cheap fast big memory and processors, which
let the software concentrate on design without having to program for the
last byte and microsecond.
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.
Which means, in many cases, that it allows the design to be built
without having to worry about the nitty-gritty of the implementation, by
using standard easily testable building blocks. Like strings. Hold on,
aren't strings one of the things you like?
Underlying all those fancy visual design tools and object methods is still a
procedural core upon which the CPU itself relies.
And while it does, that's what we're stuck with. There hasn't been a
paradigm shift in hardware -- what I'd call a 'generation' -- since the
1960s, the basic principles and operations would be familiar to Turing
(or even Babbage). OK, the speed and size of the hardware would boggle
them (it boggles me on occasion, I grew up when a large mainframe had
64K words of core store and there were only a few of them in the whole
country!), but that's only a matter of scale.

The expected breakthrough hasn't appeared, te hardware is still growing
only quantitavely. That being so, why should software be any different?
C still underlies C++,
Pascal still underlies Delphi. That procedural languages are not
progressing in the forefront of programming is, ummm, disappointing.

I'm disappointed that the promised "neural network" systems seem to have
not gone anywhere. I'm disappointed that cars are still essentially the
same as the Model T (minor user interface changes) and we're still using
fossil fuels for them. I'm disappointed that the politicians are still
behaving like power-crazed brats. I'm disappointed that the space
program hasn't progressed (indeed, has regressed in many ways). I'm
disappointed that we still don't have fusion power.

Life is full of disappointments , I'm afraid...

Chris C

[CBFalconer]

no*@given.out wrote:

CBFalconer <cb********@yah oo.com> wrote:

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.

Ummm... lets see if I'm getting this...

In comp.lang.c one is only allowed to discuss standardized C.
However, in comp.std.c one is only allowed to discuse non-standard C

Isn't that backwards?

No, they discuss future possible changes to the standard. Here we
use the existing standard. You have no excuse for not knowing what
is and is not on-topic here anymore, so kindly abide by it.

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

[Chris Croughton]

On Sat, 19 Mar 2005 15:58:52 -0500, no*@given.out
<no*@given.ou t> wrote:

On Sat, 19 Mar 2005 20:05:58 +0000, Chris Croughton <ch***@keristor .net>
wrote:

What language is "mystery.ex e" supposed to compile?
The name was fictionalized as I'm sure the writer reads these newsgroups.

I'm thinking he'll recognize himself in the description and perhaps consider
typing up a few pages of documentation.. . I'm not trying to embarrass the
guy.

Ah. I've never seen such a compiler.

go to comp.lang.c and try to convince the
people there, that's where future language directions are discussed.

This IS comp.lang.c ...

Grr, I meant comp.std.c.

Looking for Pelles C using Google, I see that it's another one based on
LCC as is Mr. Navia's compiler, so that should be on topic on
comp.compiler s.lcc as well.

Apparently not.

Ah, well, perhaps you need to start another newsgroup.

If you want to discuss standard C, however, as it is and not as some
language you might like to use which isn't C, you're welcome to do so
here...

Apparently not.

Why not? No one is complaining about people willing to discuss standard
portable C that I've seen.
Anyway... thanks for the responses on this.
I guess I'll just take up knitting.

It's not standardised. But it is, usually, portable <g>...

Chris C

[sigvald]

Chris Croughton wrote:

On Sat, 19 Mar 2005 10:31:59 -0500, no*@given.out
<no*@given.ou t> wrote:

Then where's the progress? If we continue to write for the lowest common denominator the language remains stagnant in perpetuity.
Well, for a couple of decades. How long has English been effectively
the same? Or French? Or Icelandic? The latter is virtually

unchanged from the Norse spoken by Eric the Red a millenium ago (it's had a few
words added, and a few minor changes, but Eric would still be able to
converse easily with modern inhabitants).

No, Eric the red would not understand a word of modern Icelandic upon
hearning it, the written language has changed less but it has gained a
lot of words, both loan-words and new creations.
I doubt if half of the modern Icelandic vocabulary existed in the
Viking age.