473,322 Members | 1,610 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

Specific sizes of variable types

Hi all,

I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?
Should I have a platform dependent header file which checks for
CHAR_BIT and sizeof(int) etc and have a few typedefs like int16, long32
etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?
</OT>

Thanks

Jan 21 '06 #1
25 2026

"gamehack" <ga******@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
Hi all,

I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?
You can find out the sizes of types, but you can't change them.
See the 'sizeof' operator.
Should I have a platform dependent header file which checks for
CHAR_BIT
You already have such a headers as part of your implementation.
(<limits.h>). CHAR_BIT gives the number of bits in a character
(byte). 'INT_MAX' gives the largest possible value for type
'int', etc.
and sizeof(int) etc
'sizeof' will give the number of bytes a particular type
uses.

? and have a few typedefs like int16, long32 etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?


The only way before compilation is to read your documentation.
At compile-time, use the 'sizeof' operator. E.g. you can
Use a 'sizeof' expression for the 'size' argument of 'fread()'.

C99 implementations can provide exact-sized types, but you'll
still need to check documentation to see if/which one(s) are
available for a given implementation.

-Mike
Jan 21 '06 #2
"gamehack" <ga******@gmail.com> writes:
I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?
Should I have a platform dependent header file which checks for
CHAR_BIT and sizeof(int) etc and have a few typedefs like int16, long32
etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?
</OT>


C99 has a standard header called <stdint.h>, which provides typedefs
for int8_t, uint8_t, int16_t, uint16_t, int32_t, etc. Those are
exact-width types, and the signed ones are required to be
2's-complement with no padding bits; they may not exist if the
implementation doesn't provide types with the required attributes. It
also provides "least" types (the smallest type with at least the
specified number of bits) and "fast" types (the "fastest" type with at
least the specified number of bits); it's not always clear what
"fastest" really means.

If your implementation doesn't provide this header, you can roll your
own, or you can use Doug Gwyn's C90-compatible public-domain
implementation q8 at <http://www.lysator.liu.se/c/q8/>. You'll
probably need to do some tailoring for your system.

--
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.
Jan 21 '06 #3
Thanks

Mike Wahler wrote:
"gamehack" <ga******@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
Hi all,

I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?


You can find out the sizes of types, but you can't change them.
See the 'sizeof' operator.
Should I have a platform dependent header file which checks for
CHAR_BIT


You already have such a headers as part of your implementation.
(<limits.h>). CHAR_BIT gives the number of bits in a character
(byte). 'INT_MAX' gives the largest possible value for type
'int', etc.
and sizeof(int) etc


'sizeof' will give the number of bytes a particular type
uses.

? and have a few typedefs like int16, long32
etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?


The only way before compilation is to read your documentation.
At compile-time, use the 'sizeof' operator. E.g. you can
Use a 'sizeof' expression for the 'size' argument of 'fread()'.

C99 implementations can provide exact-sized types, but you'll
still need to check documentation to see if/which one(s) are
available for a given implementation.

-Mike


Jan 21 '06 #4
>I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
2 byte integers is *NOT* a definite size.
I think you mean 2-octet integers or 16-bit integers.
C bytes may have any number of bits >= 8.
a portable way in being sure that each integer will be exactly 2 bytes?
No. And there's no portable way to ensure that an integer will be
exactly 2 octets, either. And even if there were, there's the
bit-order issue, which WILL be an issue if you're reading out of
binary files.
Should I have a platform dependent header file which checks for
CHAR_BIT and sizeof(int) etc and have a few typedefs like int16, long32
etc.
There's no guarantee that there will be a type that is EXACTLY 16, 19,
23, 29, 32, 37, or whatever bits long.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?


You can compile and run a program which outputs the size in bits
of each type you care about, then build a header based on the
results.

Gordon L. Burditt
Jan 21 '06 #5
"Mike Wahler" <mk******@mkwahler.net> writes:
"gamehack" <ga******@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com... [...] ? and have a few typedefs like int16, long32
etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?
The only way before compilation is to read your documentation.


Well, that's not really true. You can write a program that looks at
the information in <limits.h> and generates valid C code as its
output. GNU autoconf uses a similar approach.
At compile-time, use the 'sizeof' operator. E.g. you can
Use a 'sizeof' expression for the 'size' argument of 'fread()'.
For maximum portability, you can't assume that sizeof gives you all
the information you need. There could be padding bits.
C99 implementations can provide exact-sized types, but you'll
still need to check documentation to see if/which one(s) are
available for a given implementation.


Assuming you have <stdint.h>, the exact-width types may or may not be
available; you can determine this during compilation by using the
*_MAX macros. For example:

#include <stdint.h>

#ifdef INT16_MAX
/* ... int16_t is available ... */
#else
/* ... int16_t is not available ... */
#endif

But this is unlikely to be useful. If the program really requires
int16_t, you might as well just use it and let the compilation fail if
it doesn't exist. If you'll settle for a larger type if int16_t
doesn't exist, you can just use int_least16_t.

If you don't have <stdint.h>, as I mentioned elsethread, you can use
Doug Gwyn's q8.

If you wanted to do this yourself from scratch, you could do something
like this:

#if SCHAR_MAX >= 32767
typedef signed char int16;
#elif SHRT_MAX >= 32767
typedef short int16;
#else /* INT_MAX is guaranteed to be at least 32767 */
typedef int int16;
#endif

#if SCHAR_MAX >= 2147483647
typedef signed char int32;
#elif SHRT_MAX >= 2147483647
typedef short int32;
#elif INT_MAX >= 2147483647
typedef int int32;
#else /* LONG_MAX is guaranteed to be at least 2147483647 */
typedef long int32;
#endif

But since the work has already been done for you, there's no need to
bother.

--
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.
Jan 21 '06 #6
gamehack wrote:
Hi all,

I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?
Should I have a platform dependent header file which checks for
CHAR_BIT and sizeof(int) etc and have a few typedefs like int16, long32
etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?
</OT>


If you want true portability with a binary file you also have to think
about endianness, so reading the file bytewise is best. If you are using
C99 stdint.h will help, if not it is easy to fake up and people have
posted links to such things here before.

Remember also that the standard does not require an implementation to
actually have a 16 bit integer type, even if CHAR_BIT is 8.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Jan 21 '06 #7
Hey Keith,

Thanks a lot! I was just exploring my /usr/include and stumbled upon
stdint.h and saw all these typedefs. Exactly what I needed. One more
question. What happens if you user signed char or unsigned char for
input/output? Does it matter which one I'm using?

Regards
Keith Thompson wrote:
"gamehack" <ga******@gmail.com> writes:
I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?
Should I have a platform dependent header file which checks for
CHAR_BIT and sizeof(int) etc and have a few typedefs like int16, long32
etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?
</OT>


C99 has a standard header called <stdint.h>, which provides typedefs
for int8_t, uint8_t, int16_t, uint16_t, int32_t, etc. Those are
exact-width types, and the signed ones are required to be
2's-complement with no padding bits; they may not exist if the
implementation doesn't provide types with the required attributes. It
also provides "least" types (the smallest type with at least the
specified number of bits) and "fast" types (the "fastest" type with at
least the specified number of bits); it's not always clear what
"fastest" really means.

If your implementation doesn't provide this header, you can roll your
own, or you can use Doug Gwyn's C90-compatible public-domain
implementation q8 at <http://www.lysator.liu.se/c/q8/>. You'll
probably need to do some tailoring for your system.

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


Jan 21 '06 #8
Hello,

I'm quite aware of the endianness problem and the need to swap octets
if necessary.BTW, when I say byte I'm referring to an octet even though
I know that a byte doesn't mean an octet. As I said, stdint.h is doing
the job for me now.

Thanks
Flash Gordon wrote:
gamehack wrote:
Hi all,

I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?
Should I have a platform dependent header file which checks for
CHAR_BIT and sizeof(int) etc and have a few typedefs like int16, long32
etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?
</OT>


If you want true portability with a binary file you also have to think
about endianness, so reading the file bytewise is best. If you are using
C99 stdint.h will help, if not it is easy to fake up and people have
posted links to such things here before.

Remember also that the standard does not require an implementation to
actually have a 16 bit integer type, even if CHAR_BIT is 8.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.


Jan 21 '06 #9

"gamehack" <ga******@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
Hi all,

I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?
No. Most C compilers are still C89, and are slowly working toward C99 which
standardized exact sizes. If you are reading in data in sizes larger than a
byte (long, short, etc), you'll also need to be concerned about endianess of
the data.
Should I have a platform dependent header file which checks for
CHAR_BIT and sizeof(int) etc and have a few typedefs like int16, long32


I'm not sure if you mean 'OS' or 'compiler' by 'platform'. You'll need a
compiler dependent header file. Each compiler implements it's own sizes.
You'll probably want to avoid automatic sizes such as 'int' or 'auto'.
You'll also want to avoid 'unions' of different size data because of the
endianess issue. If you download a classic portable C game, like perhaps
UMORIA, you'll should be able to 'cut and paste' much of the needed code...
Or, you could look at other portable code such as Info-ZIP's Unzip, etc...

There are a number of programs which will give you the necessary info when
compiled on a specific compiler. One is Steven Pemberton's (no relation)
enquire.c.
Rod Pemberton
Jan 21 '06 #10
"gamehack" <ga******@gmail.com> writes:
Hey Keith,

Thanks a lot! I was just exploring my /usr/include and stumbled upon
stdint.h and saw all these typedefs. Exactly what I needed. One more
question. What happens if you user signed char or unsigned char for
input/output? Does it matter which one I'm using?

Regards


(Please don't top-post. Your response goes below, or interspersed
with, any quoted text, and you should trim anything that's not
relevant to your followup.)

You should use whatever type the function you're using expects. Read
the documentation.

--
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.
Jan 22 '06 #11
Rod Pemberton wrote:
"gamehack" <ga******@gmail.com> wrote in message

I'm writing an application which will be opening binary files
with definite sizes for integers(2 byte integers and 4 byte
longs). Is there a portable way in being sure that each integer
will be exactly 2 bytes?


No. Most C compilers are still C89, and are slowly working
toward C99 which standardized exact sizes. If you are reading
in data in sizes larger than a byte (long, short, etc), you'll
also need to be concerned about endianess of the data.


C99 only standardizes some names for systems that have components
of those exact sizes. Using stdint.h is not really portable. It
may be convenient.

The only truly portable way to handle binary quantities is as files
of bytes. You have to pack and unpack things yourself into units
of no more than 8 bits, and control all endianness in the file.
You can write functions to do all these chores in a completely
portable manner.

Once you have all that working you can create and read your binary
file. Now you can consider system dependant optimizations, by
replacing the un/packing functions under conditionals such as:

#if defined MYWACKYSYSTEM
....
#elif defined YOURWACKYSYSTEM
....
#else
.... the portable code already developed ....
#endif

and the routines created for WACKYSYSTEM will take advantage of the
(presumably) known endianness, byte sizes, and sizeof values for
it.

Note that the portable code, by dealing with values, need never
concern itself with the actual system endianness.

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

Jan 22 '06 #12
gamehack wrote:
I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?


Do you mean ensuring that the size of int for a particular compiler is 2
bytes? Properly written, the application shouldn't need that. An int
in C is at least 16 bits. If that is what you mean by 2 bytes, that
should be sufficient. Extra bits of precision shouldn't be a problem.

--
Thad

Jan 22 '06 #13
On 2006-01-22, CBFalconer <cb********@yahoo.com> wrote:
Rod Pemberton wrote:
"gamehack" <ga******@gmail.com> wrote in message

I'm writing an application which will be opening binary files
with definite sizes for integers(2 byte integers and 4 byte
longs). Is there a portable way in being sure that each integer
will be exactly 2 bytes?


No. Most C compilers are still C89, and are slowly working
toward C99 which standardized exact sizes. If you are reading
in data in sizes larger than a byte (long, short, etc), you'll
also need to be concerned about endianess of the data.


C99 only standardizes some names for systems that have components
of those exact sizes. Using stdint.h is not really portable. It
may be convenient.

The only truly portable way to handle binary quantities is as files
of bytes. You have to pack and unpack things yourself into units
of no more than 8 bits, and control all endianness in the file.
You can write functions to do all these chores in a completely
portable manner.


If you're going to bother doing that, why not go all the way and make it
base64, then it can be moved between different systems via text
conversion tools that presumably already exist for interchange between
such systems.
Jan 22 '06 #14

"gamehack" <ga******@gmail.com> wrote
I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?
Should I have a platform dependent header file which checks for
CHAR_BIT and sizeof(int) etc and have a few typedefs like int16, long32
etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?
This is actually on-topic. Discussion of platform-specific libraries is OT,
but discussing features of compilers which can differ from platform to
platform is perfectly OK. </OT>

If you have a binary file, what you wnat to do is read integers portably.
Therefore

fread(&x, 1, sizeof(int), fp);

is not OK, because you don't know the endianness, and the size might not be
right.

int fget16(FILE *fp)
{
int answer;

answer = fgetc(fp);
answer <<= 8;
answer |= fgetc(fp);

return answer;
}

is the way to go.

There are a few issues. Firstly, you need to sign extend the return if you
want to support negative numbers. Secondly, you might want to detect EOF.

Lastly, the code is portable enough, but not 100% strictly portable. The
file might not be read in chunks of 8 bytes, and the coding system might not
be twos complement. These possibilities are sufficiently remote that,
usually, you can just forget about them.

Once you've got the data into the computer, you are unlikely to care about
whether an integer is 16, 32, or 64 bits, as long as you know that the
maximum value can be represented. If the integers are, say, 4 digit
Gregorian calendar years, it won't do any harm to have extra zeros in the
significant bits. It may waste a little space, but you can deal with that
problem when you come to it.
Jan 22 '06 #15
In article <11*********************@g49g2000cwa.googlegroups. com>,
"gamehack" <ga******@gmail.com> wrote:
Hi all,

I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?
Should I have a platform dependent header file which checks for
CHAR_BIT and sizeof(int) etc and have a few typedefs like int16, long32
etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?
</OT>

Thanks


#if UINT_MAX != 65535
#error This code is non-portable and doesn't work.
#endif

You have to be a bit careful if you check for 32 bit integers, to write
the check in a way that will work on a 16 bit machine. For example if
you write

#if UINT_MAX != 0xffffffff
#error This code is non-portable and doesn't work.
#endif

you can't be sure what a sixteen bit compiler would do. It might not be
able to handle 0xffffffff and interpret it as 0xffff, and the #error
statement would not be compiled. This will work:

#if ((UINT_MAX >> 15) >> 15) != 3
#error This code is non-portable and doesn't work
#endif
Jan 22 '06 #16
gamehack wrote:

Hi all,

I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?
Should I have a platform dependent header file which checks for
CHAR_BIT and sizeof(int) etc and have a few typedefs like int16, long32
etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?
</OT>


Binary files aren't closely associated with portability.
Text files are.

--
pete
Jan 22 '06 #17
Malcolm wrote:
"gamehack" <ga******@gmail.com> wrote
I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is
there a portable way in being sure that each integer will be
exactly 2 bytes? Should I have a platform dependent header file
which checks for CHAR_BIT and sizeof(int) etc and have a few
typedefs like int16, long32 etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?
This is actually on-topic. Discussion of platform-specific
libraries is OT, but discussing features of compilers which can
differ from platform to platform is perfectly OK.
</OT>

If you have a binary file, what you wnat to do is read integers
portably. Therefore

fread(&x, 1, sizeof(int), fp);

is not OK, because you don't know the endianness, and the size
might not be right.

int fget16(FILE *fp)
{
int answer;

answer = fgetc(fp);
answer <<= 8;
answer |= fgetc(fp);
return answer;
}

is the way to go.


Not good enough. You haven't allowed for the possible variation of
CHAR_BIT. Also you must not create an integer overflow. Thus:

unsigned int fget16(FILE *fp) {
unsigned int ans;

ans = (fgetc(fp) & 0xff) << 8;
ans |= (fgetc(fp) & 0xff);
return ans;
}
There are a few issues. Firstly, you need to sign extend the
return if you want to support negative numbers. Secondly, you
might want to detect EOF.
Exactly. Except sign-extend is not the right term.

Lastly, the code is portable enough, but not 100% strictly
portable. The file might not be read in chunks of 8 bytes,
and the coding system might not be twos complement. These
possibilities are sufficiently remote that, usually, you can just
forget about them.
Those are so easily handled (see above) that there is no excuse for
failure.

Once you've got the data into the computer, you are unlikely to
care about whether an integer is 16, 32, or 64 bits, as long as
you know that the maximum value can be represented. If the
integers are, say, 4 digit Gregorian calendar years, it won't do
any harm to have extra zeros in the significant bits. It may waste a
little space, but you can deal with that problem when you come to it.

--
"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/>
Jan 22 '06 #18
pete wrote:
gamehack wrote:
Hi all,

I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?
Should I have a platform dependent header file which checks for
CHAR_BIT and sizeof(int) etc and have a few typedefs like int16, long32
etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?
</OT>

Binary files aren't closely associated with portability.
Text files are.


Go pete! That's why source code is in text files!

Not to talk down to anyone but ASCII is American Standard Code for
Information Interchange. It is text. It is Open Standard.

It is the right way, usually, to communicate among disparate systems and
architectures.

If you will communicate with 'binary' files, you must know exquisitely
the format of the file you are reading. You cannot 'detect' the format
by reading the file.

Trying to write programs to handle format differences among binary files
from disparate systems will make you very tired, frustrated and old.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jan 22 '06 #19
Christian Bau <ch***********@cbau.freeserve.co.uk> writes:
[...]
#if UINT_MAX != 65535
#error This code is non-portable and doesn't work.
#endif

You have to be a bit careful if you check for 32 bit integers, to write
the check in a way that will work on a 16 bit machine. For example if
you write

#if UINT_MAX != 0xffffffff
#error This code is non-portable and doesn't work.
#endif

you can't be sure what a sixteen bit compiler would do. It might not be
able to handle 0xffffffff and interpret it as 0xffff, and the #error
statement would not be compiled.


Actually, that shouldn't be a a problem. In C99, the preprocessor
evaluates integers as if they were of type intmax_t or uintmax_t,
which is guaranteed to be at least 64 bits. I don't have my copy of
the C90 standard handy, but I'm fairly sure the rule is similar,
except that only 32 bits are guaranteed.

If you want to go beyond 32 bits, and you can't assume a C99
implementation, you might have to resort to some ugly tricks.

--
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.
Jan 22 '06 #20
Joe Wright <jo********@comcast.net> writes:
pete wrote:

[...]
Binary files aren't closely associated with portability.
Text files are.


Go pete! That's why source code is in text files!

Not to talk down to anyone but ASCII is American Standard Code for
Information Interchange. It is text. It is Open Standard.

It is the right way, usually, to communicate among disparate systems
and architectures.


ASCII isn't really portable either. Plain text is portable, assuming
it can be translated as it's transferred from one machine to another,
and assuming you restrict it to a portable subset of the available
characters. (Try reading ASCII on a system that uses EBCDIC, or vice
versa.)

--
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.
Jan 22 '06 #21

"Joe Wright" <jo********@comcast.net> wrote

Trying to write programs to handle format differences among binary files
from disparate systems will make you very tired, frustrated and old.

And it is hard to parse text files.
Bascially a binary file is either coherent or non-coherent. A text file can
have any sort of nonsense such as
Nemployees 10000000000000000000000

trying to handle that robustly is a real headache.
Jan 22 '06 #22
Keith Thompson wrote:
Joe Wright <jo********@comcast.net> writes:
pete wrote:


[...]
Binary files aren't closely associated with portability.
Text files are.


Go pete! That's why source code is in text files!

Not to talk down to anyone but ASCII is American Standard Code for
Information Interchange. It is text. It is Open Standard.

It is the right way, usually, to communicate among disparate systems
and architectures.

ASCII isn't really portable either. Plain text is portable, assuming
it can be translated as it's transferred from one machine to another,
and assuming you restrict it to a portable subset of the available
characters. (Try reading ASCII on a system that uses EBCDIC, or vice
versa.)

Are you picking on me?

I have never encountered a 'text' file in EBCDIC. Have you? Well maybe..

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jan 22 '06 #23
Joe Wright <jo********@comcast.net> writes:
Keith Thompson wrote: [...]
ASCII isn't really portable either. Plain text is portable, assuming
it can be translated as it's transferred from one machine to another,
and assuming you restrict it to a portable subset of the available
characters. (Try reading ASCII on a system that uses EBCDIC, or vice
versa.)

Are you picking on me?


Not at all.
I have never encountered a 'text' file in EBCDIC. Have you? Well maybe..


Yes, I've worked on IBM mainframe systems (but not lately).

The C standard places some specific requirements on the character set,
but it doesn't mention ASCII. The characters '0'..'9' are required to
be in order and contiguous; 'A'..'Z' and 'a'..'z' are not (because
they aren't contiguous in EBCDIC). EBCDIC is probably slowly dying
out, but it's not dead yet; there are still plenty of running systems
that use it.

Expanded character sets that are strict supersets of 7-bit ASCII seem
to be the wave of the future, but nothing is certain -- and there's
rarely any need to write code that will work on an ASCII system but
fail on an EBCDIC system.

--
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.
Jan 22 '06 #24
gamehack wrote:
Hi all,

I'm writing an application which will be opening binary files with
definite sizes for integers(2 byte integers and 4 byte longs). Is there
a portable way in being sure that each integer will be exactly 2 bytes?
Should I have a platform dependent header file which checks for
CHAR_BIT and sizeof(int) etc and have a few typedefs like int16, long32
etc.
<OT>
If I have to go non-portable, then what's the way to determine the
sizes before compilation and typedef accordingly?
</OT>

Thanks


The family of functions (non-standard, but very common) "htons", ...
could also help to code the I/O functions.

Kind regards.

Note: I work all days with an EBCDIC main frame. Thus, char coding is
something mandatory even for a simple "ftp".

DISCLAIMER:
If someone follows this suggestion, their program could not work, and
his boss can fire him. Or the program could work, becaume unnecessary
and make also redundant. It is also posible that the best option is do
not made nothing: you could be made redundant, but with less effort
spent.

Jan 22 '06 #25
On Sun, 22 Jan 2006 08:09:32 -0500, CBFalconer <cb********@yahoo.com>
wrote:
Malcolm wrote: <snip>
int fget16(FILE *fp)
{
int answer;

answer = fgetc(fp);
answer <<= 8;
answer |= fgetc(fp);
return answer;
}

is the way to go.


Not good enough. You haven't allowed for the possible variation of
CHAR_BIT. Also you must not create an integer overflow. Thus:

You haven't either. His code malfunctions if the bytes in (or to be
precise read from) the file aren't 8-bit values (perhaps padded);
yours returns wrong results, which isn't correct either.
unsigned int fget16(FILE *fp) {
unsigned int ans;

ans = (fgetc(fp) & 0xff) << 8;
And this doesn't prevent overflow on an implementation with 16-bit int
and not 'safe' (e.g. 2sC-bitwise) shifts. You need the left operand
unsigned int (at least) _before_ shifting, either explicitly:
ans = (unsigned)fgetc(fp) << 8;
or if you insist on the masking you can 'hide' it there:
ans = (fgetc(fp) & 0xffU) << 8;
although unless you comment this some reader(s) and particularly a
maintenance programmer may not realize the reason and "fix" it.
ans |= (fgetc(fp) & 0xff);
return ans;
}


- David.Thompson1 at worldnet.att.net
Feb 6 '06 #26

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Simon G Best | last post by:
Hello! The C++ standard library provides facilities for finding out the sizes (and other such stuff) of numeric types (::std::numeric_limits<>, for example). What I would like to do is to...
14
by: David Fisher | last post by:
The most common sizes of integer types seem to be: 8 bits - signed char 16 bits - short 16 or 32 bits - int 32 or 64 bits - long Question #1: Does anyone know how common sizes other than...
26
by: Kip | last post by:
Greetings everyone, Is there anyone here who could point me to a page or pdf that has a list of the sizes of all of the C primitive data types on various implementations such as SPARC, x86,...
4
by: Dabbler | last post by:
Is there a table of sizes to use for SqlDbTypes with SqlParameter constructor such as: SqlParameter("@VanId", SqlDbType.Int, 4")); Not sure which types require a size and which ones can be left...
14
by: Michael Brennan | last post by:
Hi, I wonder if there is any good reason to let different systems have different sizes of short, int and long? I think that makes it harder to plan which type to use for your program. For...
159
by: Bob Timpkinson | last post by:
Hi, I have a 32-bit machine... Is there anyway I can get gcc to use the following integer sizes? char: 8 bits short: 16 bits int: 32 bits long: 64 bits long long: 128 bits
2
by: =?Utf-8?B?R3JlZw==?= | last post by:
I'm using VB.Net 2005 and am defining parameters for a stored procedure using the following code snippet. MyBase.sqlAddParameter("@strExtension", _ SqlDbType.NVarChar, 4, _...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.