G
Gerry Quinn
And:
"The meaning of the new value of u.b is implementation dependent, and in
fact the C Standard states that it is invalid to read u.b if u.a was
last written."
- Gerry Quinn
And:
"The meaning of the new value of u.b is implementation dependent, and in
fact the C Standard states that it is invalid to read u.b if u.a was
last written."
- Gerry Quinn
G
Galga
CBFalconer said:
Because the core topic can be relevant to any of those groups; who are
you to speak for everyone in those groups? As a matter of fact, people
from all those groups (that I've seen posting regularly in those
respective groups) have been jumping into this thread.
It's the whole long established *POINT* of cross posting, to make a
thread available where it may serve common interests, which this thread
has done.
~Galga
G
Gerry Quinn
It's not illegal, any more than casting a float to an int (which it
effectively is) is illegal.
What Paul seems not to understand is that, while it is legal, the
results are unspecified, and tend to be implementation-dependent.
- Gerry Quinn
G
Galga
Paul said:
But you *DID* participate and *YOU* are just as much to blame for the
"thread drift" you speak of, yet it's everyone else's fault. How
convenient.
Actually, the part of the thread you are referring to discusses the
validity of the OP's product, which has to do with the original topic.
Since when is posting about weather the program can do what it's claimed
to be able to do off-topical from the root topic? Granted it's
stretched, but not so far as to warrant another thread, IMHO.
G
Gerry Quinn
Which is exactly what I'm saying. C has unions. Bytecode and object
code don't. Paul's objections are meaningless.
- Gerry Quinn
G
Gerry Quinn
Sorry, I meant casting a float* to an int* and de-referencing. Casting
a float to an int does give specified results, of course.
- Gerry Quinn
K
Keith Thompson
chris said:
What everybody seems to be missing here is that MPC *does* behave the
same way as a more traditional compiler. Upthread, Mohd Hanafiah
Abdullah (apparently the author of the system) provided an example
showing a union of an int and a float. The example stores a value in
the float member and reads the int, and vice versa. It mapped the int
value 1078531719 to 3.142, and vice versa. This is of course
undefined behavior, but it's consistent with the behavior of gcc on an
x86 system. Apparently MPC doesn't just implement unions in a manner
that's barely conforming; it implements true unions that behave as you
would expect them to.
There may be some interesting issues in how this is implemented in
Java bytecode (as distinct from the Java language), but that's
off-topic in comp.lang.c.
MPC is non-conforming in that it doesn't implement type double (all
the basic types are 32-bits). I don't believe the author has claimed
otherwise.
G
Galga
Gerry said:
Quite right. I think most of this thread could have been avoided if Paul
had admitted his blunder, or had not made it in the first place. But,
sigh, you can't expect much of PL anymore, as he is *never* wrong....
G
Galga
Gerry said:
Good catch, I was about to reply about that, saved me the trouble
~Galga
R
Richard Herring
Richard, is it going to warp the the fecking space time continuum to get[QUOTE="Galga said:
off your high horse about a topic that is just maybe mere ounces off
topic?[/QUOTE]
Why is it so important to you to continue crossposting this thread?
What's your agenda? I
In case _you_ haven't noticed, C and C++ are even more closely related
languages, yet comp.lang.c and comp.lang.c++ are separate groups and
there are good reasons for that.
Where did I claim to do that?
"Might be"? Have you actually read this group before today?
Yeah, right. Name five. Then show that they aren't reading it in one of
the other groups where it might be on topic.
Logic failure. Even *I* take an interest in some off-topic threads. That
doesn't bring them back on topic.
So why don't we just add misc.misc to the Newsgroup: line?
And what exactly is the "similar interest" in this case? Feel free to
point out which features of the standard C++ language
In your opinion, perhaps.
G
Galga
Richard said:
Because you wanted to speak on behalf of that group, it made no sense
*NOT* to reply to that group. Unless you have something to hide.
True, but that alomne doesn't mean you cannot have cross topic
disccusion. Again, please do not act like you are some sort of owner of
the news groups. Your opinion is only that, it's not an administrative
or royal decry.
By trying to decide for everyone what groups this belogns to (ie,
setting follow up.) Not that this part of the thread matters all that
much, your attempt goes meaningless.
Yes, plenty, what is your point? People from all these groups may read
one of these groups a lot more then the others. Even if not, why do
*YOU* care? If you don't want to see this thread in that group, then
kill file it.
Who the hell is holding a gun to your head making you read this thread?
Nice try, but that was never the point. The point was, as you actually
said, that the c and c++ groups are rather seperated, but people in
either might be *interested* in this topic, as it bares some relation.
The original post was not a direct C post, nor was it a direct Java
post, but a post about a utility, that if it works, could be a useful
program.
In that sense, there really seems to be no real reason to shout "off
topic" for only in the name of 100% conformity and ultimately complete
utter inflexibility. Only if you really feel the need to make noise by
making a unnecessary fuss.
And again, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
~Galga
J
John Gordon
In said:
This sounds like the classic spam defense. "If you don't want to read
it, just delete it!" And we all know how well that works...
F
Flash Gordon
On Wed, 27 Oct 2004 16:17:29 +0200
<snip using union to pan array of unsigned char to structs containing
unsigned chars>
Reading using a different type to the type used for writing. IIRC some
of the elements of your struct we actually declared as uint16
From the sounds of it you will be using implementation specific trickery
and/or work arounds for implementation deficiencies, so I would not
worry about using implementation specific knowledge about unions.
I thought I saw a uint16 or something like that? Maybe a typo or faulty
memory on my part.
Using the union to map the different types all on to one piece of memory
*does* achieve what you want, i.e. it does *not* move the data around to
copy with the accesses by different types. So in *your* case I would
say hang the portability issues (but comment them) and go for it.
You would be probably be best discussing this on groups/mailing lists
dedicated to your platforms of interest since on comp.lang.c we won't
know the limitations of your C-like implementation and the would be off
topic in any case.
It is probably off topic for most of the other groups as well, so I've
set follow ups to comp.programming as the most likely group of the ones
this is cross-posted to.
<snip using union to pan array of unsigned char to structs containing
unsigned chars>
Reading using a different type to the type used for writing. IIRC some
of the elements of your struct we actually declared as uint16
From the sounds of it you will be using implementation specific trickery
and/or work arounds for implementation deficiencies, so I would not
worry about using implementation specific knowledge about unions.
I thought I saw a uint16 or something like that? Maybe a typo or faulty
memory on my part.
Using the union to map the different types all on to one piece of memory
*does* achieve what you want, i.e. it does *not* move the data around to
copy with the accesses by different types. So in *your* case I would
say hang the portability issues (but comment them) and go for it.
You would be probably be best discussing this on groups/mailing lists
dedicated to your platforms of interest since on comp.lang.c we won't
know the limitations of your C-like implementation and the would be off
topic in any case.
It is probably off topic for most of the other groups as well, so I've
set follow ups to comp.programming as the most likely group of the ones
this is cross-posted to.
A
Alfred Z. Newmane
John said:
That maybe a classic defense, but I don't see how this thread (except
maybe in some views, the original post) could be spam.
In this case, I think the "kill the thread if you dont like it" hold
water, as no one is forcing anyone to read it.
Works rather well if you know how to delete a thread that you /really/
don't want to read. Is it /that/ hard?
F
Flash Gordon
Good catch, I was about to reply about that, saved me the trouble
I caught my reply on the outgoing spool before it left.
However, the bit pattern of an int can be a trap representation for a
float, so writing an int then reading it as a float is definitely *not*
guaranteed to leave your program running. I think the only type punning
the C standard actual guarantees won't crash your program is reading
anything as unsigned char, an exception that I believe is explicitly
mentioned.
E
E. Robert Tisdale
John said:
Please don't feed the trolls.
O
Old Wolf
Paul Lutus said:
And what makes you think those pages are accurate?
None of these contain references to the C standard.
They are comments made by people who are used to programming on
implementations that do the what those quotes say. However it is
possible to have a conforming C implementation without
these quotes applying.
As an analogy, I could find screensful of quotes saying that
bytes have 8 bits. But as we all know, there are C implementations
in which a byte has 9, or 32, or some other amount of bits.
In C it is possible to have a syntactically correct
program that is not portable (by which I mean, it may
work reliably on one platform, but give different results,
or crash entirely, on different platforms). For example:
int i = 3;
i = i++;
printf("%d\n", i);
Here is another example of non-portability that doesn't
include undefined behaviour:
int x = 12;
assert( *(unsigned char *)&x == 0 );
F
Flash Gordon
On Wed, 27 Oct 2004 08:57:27 -0700
You can use pragmas, but there is nothing to say
#pragma align 1
on the next compiler you use doesn't mean align on 1GB boundaries.
There is also nothing to say that any given compiler supports a pragma
for specifying alignment.
I've seen plenty of non-portable code that does *not* document what
non-portable extensions it is using.
You can use pragmas, but there is nothing to say
#pragma align 1
on the next compiler you use doesn't mean align on 1GB boundaries.
There is also nothing to say that any given compiler supports a pragma
for specifying alignment.
I've seen plenty of non-portable code that does *not* document what
non-portable extensions it is using.
O
Old Wolf
Thomas G. Marshall said:
Nice description..
According to the C standard, it is "undefined behaviour" to
read any member of a union except for the one that was most
recently set. This means that an implementation can do whatever
it likes (including printing 3.142, or crashing, or causing
demons to fly out of your nose, as they say).
Imagine that a compiler detects this situation and inserts
code to display 3.142 whenever a float is read from a union
that just had an int put in it (that would be very perverse,
and that vendor wouldn't sell many compilers, but it is allowed).
E
E. Robert Tisdale
napi said:
I used Google
http://www.google.com/
to search for
+"C to Java byte code"
and I found lots of stuff.
There have been lots of such projects for a long time.
Why do you say that this is something that has been "missing"?
How is your product better than all of the other offerings?