Byte swapping help please

[Ann]

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

Is this a byte swapping?

Could anyone give a good way to check if bytes are being swapped? (code
should work smoothly across different machine.)

Thanks,
Ann

[Craig Ruff]

In article <11**********************@z34g2000cwc.googlegroups .com>,
Ann <ps****@yahoo.com> wrote:

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

Is this a byte swapping?
Or possbily spouse swapping.
Could anyone give a good way to check if bytes are being swapped? (code
should work smoothly across different machine.)

Perhaps we should just send the code directly to your instructor so
we can get the credit for your homework?
--

Craig Ruff NCAR cr***@ucar.edu
303-497-1211 P.O. Box 3000
Boulder, CO 80307

[Keith Thompson]

"Ann" <ps****@yahoo.com> writes:

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

Is this a byte swapping?
Looks like it.
Could anyone give a good way to check if bytes are being swapped? (code
should work smoothly across different machine.)

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.

The safest approach is to write *only* byte data. For example, if you
want to write an integer value 0x01EFCDAB to a file, you can read and
write the individual bytes (0x01, 0xEF, 0xCD, 0xAB) in a fixed order.
Or you can write a textual representation of the number, which also
has the advantage of letting you view the file with a text editor.

Strictly speaking, you might still have problems on systems with byte
sizes bigger than 8 bits, or with non-ASCII character sets; the former
is unlikely to arise in practice, and the latter can be solved with
textual conversion tools. (There are systems, mostly DSPs, with bytes
bigger than 8 bits, but they're embedded systems, and you're not
likely to need to share files with them.)

If you must write raw binary data to a file, you might add information
to the file header indicating how the data is formatted.

--
Keith Thompson (The_Other_Keith) 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]

cr***@ucar.edu (Craig Ruff) writes:

In article <11**********************@z34g2000cwc.googlegroups .com>,
Ann <ps****@yahoo.com> wrote:

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

Is this a byte swapping?

Or possbily spouse swapping.

Could anyone give a good way to check if bytes are being swapped? (code
should work smoothly across different machine.)

Perhaps we should just send the code directly to your instructor so
we can get the credit for your homework?

I didn't see any indication that this was homework. (If it was, it's
a very poorly stated problem; as I mentioned elsethread, there is no
reliable way to detect the byte ordering of a binary file.)

--
Keith Thompson (The_Other_Keith) 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.

[Roberto Waltman]

Keith Thompson wrote:

... as I mentioned elsethread, there is no
reliable way to detect the byte ordering of a binary file.

I believe there is, if you are allowed to "cheat" by using an
auxiliary file, or a field with a known value at the beginning of the
file.
Assuming, for example, that the file will be used to store 32 bit
integers, writing 0x12345678 as the first 4 octets will provide you
will all the information you need to decode the following data
correctly.

[ray]

On Thu, 13 Apr 2006 11:47:24 -0700, Ann wrote:

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

Is this a byte swapping?

Could anyone give a good way to check if bytes are being swapped? (code
should work smoothly across different machine.)

Thanks,
Ann

One is 'big-endian' and one is 'little-endian'. That is exactly what htonl
and ntohl are for (host to network long and network to host long).

[Al Balmer]

On Thu, 13 Apr 2006 15:57:40 -0400, Roberto Waltman
<us****@rwaltman.net> wrote:

Keith Thompson wrote:

... as I mentioned elsethread, there is no
reliable way to detect the byte ordering of a binary file.

I believe there is, if you are allowed to "cheat" by using an
auxiliary file, or a field with a known value at the beginning of the
file.
Assuming, for example, that the file will be used to store 32 bit
integers, writing 0x12345678 as the first 4 octets will provide you
will all the information you need to decode the following data
correctly.

That can be a useful technique. William Waite used something like that
to distribute the Stage 2 macro processor. As I recall, the Fortran
bootstrap read a record containing the character set to be used.

--
Al Balmer
Sun City, AZ

[Roberto Waltman]

Al Balmer wrote:

<OT> ( I think..)

William Waite used something like that
to distribute the Stage 2 macro processor. As I recall, the Fortran
bootstrap read a record containing the character set to be used.

What is/was "the Stage 2 macro processor" ?
</OT>

[Al Balmer]

On Thu, 13 Apr 2006 16:49:16 -0400, Roberto Waltman
<us****@rwaltman.net> wrote:

Al Balmer wrote:

<OT> ( I think..)
OT in comp.lang.c. I plead ignorance about the other two groups <g>.

William Waite used something like that
to distribute the Stage 2 macro processor. As I recall, the Fortran
bootstrap read a record containing the character set to be used.

What is/was "the Stage 2 macro processor" ?

A rather nice macro processor designed to be ported to any system
which had a Fortran compiler. Years ago, I used it to implement a
system called "SAP" (Structured Assembler Programming) which was used
successfully to implement a number of process control products. Here's
an abstract of an early paper:
http://hopl.murdoch.edu.au/showlanguage2.prx?exp=534
########
* Waite, W. M. "The Mobile Programming System: STAGE2" view
details Abstract: STAGE2 is the second level of a bootstrap sequence
which is easily implemented on any computer. It is a flexible,
powerful macro processor designed specifically as a tool for
constructing machine-independent software. In this paper the features
provided by STAGE2 are summarized, and the implementation techniques
which have made it possible to have STAGE2 running on a new machine
with less than one man-week of effort are discussed. The approach has
been successful on over 15 machines of widely varying characteristics.
DOI
in [ACM] CACM 13(09) (Sep 1970) view details
########

The published papers were not quite sufficient to implement the
system. For that, the best resource was the book:

Waite, W. M. Implementing Software for Non-numeric Applications, P-H
1973
</OT>

--
Al Balmer
Sun City, AZ

[Roberto Waltman]

Al Balmer wrote:

What is/was "the Stage 2 macro processor" ?

A rather nice macro processor designed to be ported to any system
which had a Fortran compiler. Years ago, I used it to implement a
system called "SAP" (Structured Assembler Programming) which was used
successfully to implement a number of process control products. Here's
an abstract of an early paper:
http://hopl.murdoch.edu.au/showlanguage2.prx?exp=534

Thanks for the info, looks interesting. Of course now I must learn
what FLUB and LIMP are, and then... There goes my weekend...

[danielhe99]

Yes, the id stored at the beginning of the binary file is called
"magic number".

Here is an example:
http://aslan.smnd.sk/anino/programmi...gettext_6.html

[Keith Thompson]

da********@gmail.com writes:

Yes, the id stored at the beginning of the binary file is called
"magic number".

Here is an example:
http://aslan.smnd.sk/anino/programmi...gettext_6.html

Please read <http://cfaj.freeshell.org/google/>.

Yes, if you store the right information in the file, it's possible to
determine its endianness. My point was that there's no *general* way
to do this. If I use fwrite() to write, say, an array of integers to
a binary file, there's no way to determine the endianness of the file
unless it's indicated explicitly, or unless I know something about
the expected values.

--
Keith Thompson (The_Other_Keith) 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.

[Andy Glew]

Roberto Waltman <us****@rwaltman.net> writes:

Al Balmer wrote:

What is/was "the Stage 2 macro processor" ?

A rather nice macro processor designed to be ported to any system
which had a Fortran compiler. Years ago, I used it to implement a
system called "SAP" (Structured Assembler Programming) which was used
successfully to implement a number of process control products. Here's
an abstract of an early paper:
http://hopl.murdoch.edu.au/showlanguage2.prx?exp=534

Thanks for the info, looks interesting. Of course now I must learn
what FLUB and LIMP are, and then... There goes my weekend...

Cool.

Circa 2000 I defined (and had somebody implement) a macro language
that had a property similar to something I saw on a quick scan of
Stage2: the text after expansion was completely reprocessed by all
remaining patterns, repeatedly.

Now, sure, macro languages like CPP will expand a macro, then will
expand all macros in the macro, etc. But, to the best of my
knowledge, they have a single pattern match going on - macro
invocation such as FOO().

The fun part was
a) defining "best match" in a way that users found meaningful
b) reparsing completely - e.g. Foo##Bar() might concatenate,
and then expand FooBar()
c) defining things in a way so that phase ordering did not
produce unpleasant artifacts.

Unfortunately, that project evaporated when I left Intel.

[Charles Allen]

Ann:

Could anyone give a good way to check if bytes are being swapped? (code
should work smoothly across different machine.)

Keith Thompson: 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
...
The safest approach is to write *only* byte data. For example, if you

Depending on what level you control the I/O and how often this is
going to occur, you could also look at XDR, or something higher level
like netCDF.

--
Charles Allen

[Andrew Reilly]

On Fri, 14 Apr 2006 02:10:06 +0000, Keith Thompson wrote:

Yes, if you store the right information in the file, it's possible to
determine its endianness. My point was that there's no *general* way
to do this. If I use fwrite() to write, say, an array of integers to
a binary file, there's no way to determine the endianness of the file
unless it's indicated explicitly, or unless I know something about
the expected values.

If the numbers represent a white, random sequence, then it might not
matter which order you read them. Maybe that's good enough for the OP?

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, and if you have an octet-wide
peripheral or memory to stuff the results, you'll even get the same file...
(Luckily for the sanity of programmers, byte-addressability seems to be
becoming more popular in DSPs too, at least those that have some
expectation of being spoken to in C, some of the time.)

Cheers,

--
Andrew

[jaysome]

Keith Thompson wrote:

[snip]

Strictly speaking, you might still have problems on systems with byte
sizes bigger than 8 bits, or with non-ASCII character sets; the former
is unlikely to arise in practice, and the latter can be solved with
textual conversion tools.

In other words, strictly speaking, portable C code does not exist in the
real world. I just downloaded some code that was purported to be
portable C. But it was written using the ASCII character set, and my
development environment uses the EBCDIC character set. Needless to say,
I got compilation errors.

You can not distribute portable C code in electronic form--you must
write a book or publish a document or use some other form of
communication that conveys your source code. Those infatuated with
portable C must somehow translate such a listing to their
platform-specific character encoding if they wish to use your portable C
code. The brute force way to do this is to type in the text manually in
a text editor. Should you choose this route, you'd be much advised to
teach your spouse to do this. I'm sure if you tell him or her that such
an effort buttresses the spirit of portable C, him or her will willingly
comply. Be rest assured there are some hard-core portable C fanatics
working on a "portable" OCR solution to automate this task.

What you see is not always what you get. When you open a file in your
text editor or development environment, it assumes a certain character
encoding of the file. If the character encoding is not what your text
editor or development environment expects, then don't blame the C
standard, which says nothing about how character encoding of files is
specified: ASCII and EBCDIC, among others, are acceptable.

--
jay

[Terje Mathisen]

jaysome wrote:

Keith Thompson wrote:

[snip]

Strictly speaking, you might still have problems on systems with byte
sizes bigger than 8 bits, or with non-ASCII character sets; the former
is unlikely to arise in practice, and the latter can be solved with
textual conversion tools.

In other words, strictly speaking, portable C code does not exist in the
real world. I just downloaded some code that was purported to be
portable C. But it was written using the ASCII character set, and my
development environment uses the EBCDIC character set. Needless to say,
I got compilation errors.

Trolls that cannot use the default ascii-ebcdic conversion tools, not
even to the extent of sending the code as email, needs to go back into
their cave and hide.

Terje

--
- <Te************@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

[Roberto Waltman]

da********@gmail.com wrote:

Yes, the id stored at the beginning of the binary file is called
"magic number".

Here is an example:
http://aslan.smnd.sk/anino/programmi...gettext_6.html

Please include some context from the message you are replying to. This
is meaningless when read in isolation. Since I still remember what I
wrote earlier today, I will provide it for you this time. ;)

"Assuming, for example, that the file will be used to store 32 bit
integers, writing 0x12345678 as the first 4 octets will provide you
will all the information you need to decode the following data
correctly."

The intent here is not to have something that will identify what the
contents or layout if the file are, as in the common use of file
"magic numbers", but to detect byte-swapping.

When you write a magic number to identify a file, you expect to read
it back with the same value.

What I refer to in my post, is that you can write

0x12345678

and, after transferring the file to another system, read back any of
the following:

0x12345678 - no change.
0x78563412 - byte reversal.
0x56781234 - high/low half swap.
0x34127856 - byte swap between each half.

( I believe these are the only permutations that make sense. Somebody
tell me I'm wrong? )

If you know that the word was indeed 0x12345678, then you know how to
correct for byte-swapping in the rest of the file.
Roberto Waltman
[ please reply to the group,
return address is invalid ]

[Micah Cowan]

jaysome <ja*****@spamcop.com> writes:

Keith Thompson wrote:

[snip]

Strictly speaking, you might still have problems on systems with byte
sizes bigger than 8 bits, or with non-ASCII character sets; the former
is unlikely to arise in practice, and the latter can be solved with
textual conversion tools.

In other words, strictly speaking, portable C code does not exist in
the real world. I just downloaded some code that was purported to be
portable C. But it was written using the ASCII character set, and my
development environment uses the EBCDIC character set. Needless to
say, I got compilation errors.

You make an extremely poor case.

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.

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.

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.

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

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

[Old Wolf]

jaysome wrote:

In other words, strictly speaking, portable C code does not exist in the
real world. I just downloaded some code that was purported to be
portable C. But it was written using the ASCII character set, and my
development environment uses the EBCDIC character set.
Which environment is that, out of interest?
Needless to say, I got compilation errors.
The C standard defines a source character set -- all of which
are supported by both ASCII and EBCDIC. So either the source
was not actually portable in the first place (ie. it contained an
illegal character), or you did not properly convert the source
from ASCII to EBCDIC before loading it onto your system.
You can not distribute portable C code in electronic form--you must
write a book or publish a document or use some other form of
communication that conveys your source code. Those infatuated with
portable C must somehow translate such a listing to their
platform-specific character encoding if they wish to use your portable C
code. The brute force way to do this is to type in the text manually in
a text editor.
This is just silly. Would you also say that source files cannot
be distributed in gzip archives, because your C compiler cannot
read gzip files? No. When you receive a source file, you first
translate it to the correct form for your environment.
What you see is not always what you get. When you open a file in your
text editor or development environment, it assumes a certain character
encoding of the file. If the character encoding is not what your text
editor or development environment expects, then don't blame the C
standard

Of course not. Invoking your development environment properly
is not part of any standard, nor should it be. Read your IDE's
documentation.

[Andrew Poelstra]

Micah Cowan wrote:

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]

Andrew Poelstra <ap*******@shaw.ca> writes:

Micah Cowan wrote:

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.

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.

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?

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.

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.

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.

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.

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.

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

[Kenneth Brody]

Micah Cowan wrote:

Andrew Poelstra <ap*******@shaw.ca> writes:

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

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.

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:Th*************@gmail.com>

[Micah Cowan]

Kenneth Brody <ke******@spamcop.net> writes:

Micah Cowan wrote:

Andrew Poelstra <ap*******@shaw.ca> writes:

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

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.

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.

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

[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?

--
mac the naïf

[Kenneth Brody]

Alex Colvin wrote:

[..."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:Th*************@gmail.com>

[me]

Ann wrote:

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.
Thanks,
Ann

[me]

Kenneth Brody wrote:

Alex Colvin wrote:

>> [..."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:-)

[CBFalconer]

Kenneth Brody wrote:

Alex Colvin wrote:

>> [..."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]

Keith Thompson wrote:

"Ann" <ps****@yahoo.com> writes:

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

Is this a byte swapping?

Looks like it.

Could anyone give a good way to check if bytes are being swapped? (code
should work smoothly across different machine.)

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]

"Kenneth Brody" wrote:

Alex Colvin wrote:

>> [..."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]

Micah Cowan wrote:

Kenneth Brody <ke******@spamcop.net> writes:

(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]

On Tue, 25 Apr 2006 03:10:55 -0700, glen herrmannsfeldt
<ga*@ugcs.caltech.edu> wrote:

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

--
Al Balmer
Sun City, AZ

[Dave Thompson]

On Sat, 15 Apr 2006 08:14:08 +1000, Andrew Reilly
<an*************@areilly.bpc-users.org> wrote:
<snip>

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