Byte swapping help please

[Andrew Poelstra]

Source code that does not consist of characters in your
implementation's source character set, is obviously not C code at all,
from the perspective of your implementation.

I hope that you realize that your statement makes no sense. C code is
platform independent, and therefore if you go by your "implementation's
perspective", you end up with a text file. Hmm.

However, mainstream methods for downloading, such as HTTP,
specifically provide information about whether a file is text or not,
and usually (always, in the case of HTTP) what encoding it is in.

So, you take back what you said before?

Any reasonable definition for correctly and completely "downloading" a
plaintext file from one host to another would necessarily include
proper transcoding. Otherwise, what you have at the end is not the
plaintext file that was offered to you by the server.

Wait. If you *don't covert* it, you end up with a different file? The
other way around is suggested by common sense, laws of thermodynamics, etc.

Given this, there is certainly plenty of 100% portable C code. Though
I'm sure it's well in the minority.

Well, if your definition of portable C code now includes the definition
of "portable text file requiring no conversion", I'm afraid there is no
portable C code. Nor does anything portable exist. Since you might as
well make your own operating system as none of the others are
compatible, my advice would be to use ASCII.

 

[Micah Cowan]

I hope that you realize that your statement makes no sense. C code is
platform independent, and therefore if you go by your
"implementation's perspective", you end up with a text file. Hmm.

This statement makes no sense to me. I'm not sure what you're trying
to say. Of course you have a text file. C source files are text files.
So by definition, if you don't have a text file, it certainly can't be
C source.

The definition of a text file, unfortunately, /is/ very platform dependant.

So, you take back what you said before?

I fail to see how this paragraph contradicts anything else I've
said. And you've failed to illustrate how it does, so I will continue
to believe that it does not.

Wait. If you *don't covert* it, you end up with a different file? The
other way around is suggested by common sense, laws of thermodynamics,
etc.

No, you end up with a file that is not, from your system's point of
view, a valid plaintext file, and therefore not C code at all.

The file you end up with, though, is not the file your machine was
intended to have. Conversion is typically automatic to the process of
downloading from a server: if the conversion did not take place, there
was a configuration error somewhere, and I don't believe that anyone
could consider the download to have been "successful" in that case.

Well, if your definition of portable C code now includes the
definition of "portable text file requiring no conversion", I'm afraid
there is no portable C code. Nor does anything portable exist. Since
you might as well make your own operating system as none of the others
are compatible, my advice would be to use ASCII.

Such is certainly not my definition, as you'd realize had you actually
been reading what I'd written.

My point is simply that trying to use text-encoding issues to make a
claim that C source can never be portable is a fallacy.

 

[Kenneth Brody]

Andrew Poelstra <[email protected]> writes:

[..."C source isn't portable because of ASCII/EBCDIC differences"...]

Such is certainly not my definition, as you'd realize had you actually
been reading what I'd written.

My point is simply that trying to use text-encoding issues to make a
claim that C source can never be portable is a fallacy.

Take, for example, "#include". A C source file does _not_ include
other files by starting a "line" with 0x23,0x69,0x6e,0x63,0x6c,0x75,
0x64,0x65, but rather by starting a "line" with '#','i','n','c','l',
'u','d','e'. If your platform uses ASCII, these are one and the
same. However, if your platform is EBCDIC, as the OP stated, then
the file must contain 0x7b,0x89,0x95,0x83,0x93,0xa4,0x84,0x85. To
pass 0x23,0x69,... to a C compiler expected EBCDIC is, of course,
not going to work well, any more than passing 0x7b,0x89,... to a C
compiler expecting ASCII.

Both sequences represent "#include" to the computer on which they
reside.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Micah Cowan]

Andrew Poelstra <[email protected]> writes:

[..."C source isn't portable because of ASCII/EBCDIC differences"...]

Such is certainly not my definition, as you'd realize had you actually
been reading what I'd written.

My point is simply that trying to use text-encoding issues to make a
claim that C source can never be portable is a fallacy.

Take, for example, "#include". A C source file does _not_ include
other files by starting a "line" with 0x23,0x69,0x6e,0x63,0x6c,0x75,
0x64,0x65, but rather by starting a "line" with '#','i','n','c','l',
'u','d','e'. If your platform uses ASCII, these are one and the
same. However, if your platform is EBCDIC, as the OP stated, then
the file must contain 0x7b,0x89,0x95,0x83,0x93,0xa4,0x84,0x85. To
pass 0x23,0x69,... to a C compiler expected EBCDIC is, of course,
not going to work well, any more than passing 0x7b,0x89,... to a C
compiler expecting ASCII.

Both sequences represent "#include" to the computer on which they
reside.

Exactly. So it's not the C source that's not portable (necessarily);
it's the /representation/ of that C source.

 

[Alex Colvin]

[..."C source isn't portable because of ASCII/EBCDIC differences"...]

my C code is written for 3.3V. WIll it compile at 1.5volts?

 

[Kenneth Brody]

[..."C source isn't portable because of ASCII/EBCDIC differences"...]

my C code is written for 3.3V. WIll it compile at 1.5volts?

It depends... Do you have any voltage-dependent code?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[CBFalconer]

[..."C source isn't portable because of ASCII/EBCDIC differences"...]

my C code is written for 3.3V. WIll it compile at 1.5volts?

It depends... Do you have any voltage-dependent code?

Not a chance. One Vcesat + one diode drop and you can't possibly
have any noise margin left, in fact it will be negative. All the
world is analog, and a line.

--
"If you want to post a followup via groups.google.com, 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
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[me]

I am opening a file which looks like 0xABCDEF01 on another machine but
0x01EFCDAB on my machine.

Is this a byte swapping?
Yes.

Could anyone give a good way to check if bytes are being swapped?

// C++
inline boolean islittleendian()
{
int32_t i = 0xABCDEF01;
return *(char*)(&i) == i & 0xff;
}

(code should work smoothly across different machine.)

The code would have to be written to handle all byte orders; fortunately,
most platforms have one of the two predominant byte orders - the byte
orders of PowerPC and AMD64.

 

[me]

[..."C source isn't portable because of ASCII/EBCDIC differences"...]

my C code is written for 3.3V. WIll it compile at 1.5volts?

It depends... Do you have any voltage-dependent code?

No; it depends on whether his silicon compiler runs on 1.5 volts

 

[me]

Looks like it.


In principle, there is no reliable way to tell. If you read a 32-bit
unsigned integer from a file and get a value of 0xABCDEF01, how can
you know whether it should be 0xABCDEF01 or 0x01EFCDAB? Without more
information, you can't. Even with more information, you may not be
able to tell.

If you're storing binary data in a file, byte ordering is only one of
the problems you can run into. Sizes of types can vary across
different implementations; so cah floating-point representations.

.... and alignments.

 

[John F]

[..."C source isn't portable because of ASCII/EBCDIC
differences"...]

my C code is written for 3.3V. WIll it compile at 1.5volts?

It depends... Do you have any voltage-dependent code?

The question was: Will it compile? So it depends on the voltage
dependency of the compiler. If it produces voltage dependent code then
is up to the implementation.

Personally:
I stop coding at ~60V. So, yes, if "no code" is different than "code",
I do have voltage dependent _code_ (Or don't I have it then?
*scratching my head*).

Quite a two level logic. Maybe my code gets dirty at 40V+ so there
might be some fuzzy area. I survived 230V AC, ~3000V on a HV-Capacitor
and a lot of service stuff like 330V DC in a SMPS ... deadly voltage
ratings are always so discriminating for the survivors :->

In general:
It is possible to have voltage dependent code. Not in standard C.
There can be platform specific effects. I remember a µP to set a flag
according to the supply voltage (5V or 3.3V). Quite interesting stuff.
You could tune your power management code accordingly.

regards
John

 

[glen herrmannsfeldt]

(someone wrote)

[..."C source isn't portable because of ASCII/EBCDIC
differences"...]

I once saw some IBM S/360 assembly code with comments indicating
that if the source character set was translated it would work in
the new character set.

Certainly there is a lot of C code that is ASCII dependent.
If you code hex or decimal constants in place of character
constants, for example, assuming ASCII then your code won't
be portable. Or 0x0a for newline, which isn't even portable
among ASCII systems.

-- glen

 

[glen herrmannsfeldt]

(snip)

[..."C source isn't portable because of ASCII/EBCDIC differences"...]

(snip)

Take, for example, "#include". A C source file does _not_ include
other files by starting a "line" with 0x23,0x69,0x6e,0x63,0x6c,0x75,
0x64,0x65, but rather by starting a "line" with '#','i','n','c','l',
'u','d','e'. If your platform uses ASCII, these are one and the
same. However, if your platform is EBCDIC, as the OP stated, then
the file must contain 0x7b,0x89,0x95,0x83,0x93,0xa4,0x84,0x85. To
pass 0x23,0x69,... to a C compiler expected EBCDIC is, of course,
not going to work well, any more than passing 0x7b,0x89,... to a C
compiler expecting ASCII.

Note, though, that EBCDIC doesn't have a tilde or carat character,
and does have a not character and cent character that are often
inconsistently translated between tilde and carat. There are some
other possible mistranslations, including that EBCDIC has CR, LF, and
NL characters! Which one translate as '\r', which as '\n', and what
about the third one?

-- glen

 

[Al Balmer]

(someone wrote)

[..."C source isn't portable because of ASCII/EBCDIC
differences"...]

I once saw some IBM S/360 assembly code with comments indicating
that if the source character set was translated it would work in
the new character set.

Certainly there is a lot of C code that is ASCII dependent.
If you code hex or decimal constants in place of character
constants, for example, assuming ASCII then your code won't
be portable. Or 0x0a for newline, which isn't even portable
among ASCII systems.

?
There are lots of ways to make sure your code isn't portable.

 

[Dave Thompson]

On Sat, 15 Apr 2006 08:14:08 +1000, Andrew Reilly

Personally, I favor the "write the bytes in the order you want them"
school. Even htonl and friends have the problem that you have to cast the
result to an unsigned char array, which can annoy the DSP processors that
you spoke of, earlier. They'll usually be quite happy with the arithmetic
of the explicit byte extraction approach, <snip>

The conventional and POSIX-standard {h,n}to{n,h}{s,l} work on values
and don't involve any objects array or otherwise, not to mention that
you can't cast to any array type in C anyway. Although some other
socket routines do involve storing IPaddrs, ports, and other 'network'
things in objects which could be endian-specific, although in all the
cases that come to mind the sockets standard is network (BE).

- David.Thompson1 at worldnet.att.net