set and reset the least significant bit of a address

[Walter Roberson]

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

 

[Walter Roberson]

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

 

[Richard Tobin]

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]

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

 

[not]

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

 

[Flash Gordon]

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.

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.

 

[Chris Croughton]

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]

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

 

[not]

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

 

[CBFalconer]

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

 

[not]

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.

 

[jacob navia]

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]

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]

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

 

[Keith Thompson]

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]

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

 

[Chris Croughton]

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]

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

 

[not]

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.portable?

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?

 

[Walter Roberson]

|On 16 Mar 2005 11:08:42 GMT, (e-mail address removed)-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.