Variable Block Text File

[scad]

I have a file that has blocks of data that can vary in length. The
first 2 bytes of the block are a Hex number telling me how many bytes
long the block is (including those 2 bytes). I need to be able to
read those first 2 bytes, then read then entire block and write it out
to a new file with '\n' at the end of each block. Can someone help me
with that? I am having significant trouble determining the block
length as I have done little work in C++.

Thank you,

Scott

[Juha Nieminen]

scad wrote:

I have a file that has blocks of data that can vary in length. The
first 2 bytes of the block are a Hex number telling me how many bytes
long the block is (including those 2 bytes).

Are you sure the two bytes form a hexadecimal number (in ascii?), that
is, the maximum size of the block is 255 bytes (ie. FF in hex), rather
than the two bytes forming a 16-bit value telling the size of the block
(ie. the maximum size would then be 65535 bytes)?

The solution is obviously different depending on that. Also in the
latter case it depends on whether the two bytes form a low-endian or a
high-endian value.

[scad]

On Oct 28, 4:07*pm, Juha Nieminen <nos...@thanks. invalidwrote:

scad wrote:

I have a file that has blocks of data that can vary in length. *The
first 2 bytes of the block are a Hex number telling me how many bytes
long the block is (including those 2 bytes).

* Are you sure the two bytes form a hexadecimal number (in ascii?), that
is, the maximum size of the block is 255 bytes (ie. FF in hex), rather
than the two bytes forming a 16-bit value telling the size of the block
(ie. the maximum size would then be 65535 bytes)?

* The solution is obviously different depending on that. Also in the
latter case it depends on whether the two bytes form a low-endian or a
high-endian value.

It is a 16-bit value. 7F 88 = 32648

Thank you,

[James Kanze]

On Oct 29, 1:28 am, scad <scadr...@gmail .comwrote:

On Oct 28, 4:07 pm, Juha Nieminen <nos...@thanks. invalidwrote:

scad wrote:

I have a file that has blocks of data that can vary in
length. The first 2 bytes of the block are a Hex number
telling me how many bytes long the block is (including
those 2 bytes).

Are you sure the two bytes form a hexadecimal number (in
ascii?), that is, the maximum size of the block is 255 bytes
(ie. FF in hex), rather than the two bytes forming a 16-bit
value telling the size of the block (ie. the maximum size
would then be 65535 bytes)?

The solution is obviously different depending on that. Also
in the latter case it depends on whether the two bytes form
a low-endian or a high-endian value.

It is a 16-bit value. 7F 88 = 32648

And how is this binary value represented? Without knowing that,
we can't read it. If it's the same as an unsigned short in XDR,
something like:

unsigned short result = input.get() ;
result |= result << 8 | input.get() ;

would do the trick (except for error handling). If the format
is something else, you'd need something different.

And of course, this only works if you open the file in binary.
Similarly, reading the data, then outputing it with a trailing
'\n', will likely only work if the data is text, encoded in the
same character set as you normally use.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Juha Nieminen]

scad wrote:

It is a 16-bit value. 7F 88 = 32648

Thus it had nothing to do with hexadecimal. You should be more
accurate when posting questions, or else you will only send people into
wild goose chases.

[sean_in_raleigh]

On Oct 29, 11:35 am, Juha Nieminen <nos...@thanks. invalidwrote:

scad wrote:

It is a 16-bit value. 7F 88 = 32648

Thus it had nothing to do with hexadecimal. You should be more
accurate when posting questions, or else you will only send people into
wild goose chases.

It's common for beginners to associate binary values
with hex. No need to bite the newbies.

Sean

[Richard Herring]

In message
<9d************ *************** *******@y71g200 0hsa.googlegrou ps.com>,
se************* @yahoo.com writes

>On Oct 29, 11:35 am, Juha Nieminen <nos...@thanks. invalidwrote:

>scad wrote:

It is a 16-bit value. 7F 88 = 32648

Thus it had nothing to do with hexadecimal. You should be more
accurate when posting questions, or else you will only send people into
wild goose chases.

It's common for beginners to associate binary values
with hex. No need to bite the newbies.

It's common for beginners and others to confuse values with
representations , and this should be discouraged.

A value is just a value, it isn't "binary" any more than it is
"hexadecima l".

--
Richard Herring

[Juha Nieminen]

Richard Herring wrote:

A value is just a value, it isn't "binary" any more than it is
"hexadecima l".

True, but it's difficult to talk about values and their storage when
the terminology is so confusing.

"Hexadecima l" refers quite unambiguously to the (usually ascii)
representation of a numerical value (in base 16). The term "binary" is
more complicated.

In theory when you say "the number is stored in binary" it might refer
to one of two things:

1) It's stored in base-2 representation. That is, the number is stored
by writing a combination of the two characters '0' and '1'.

2) It's stored in the same way as it's stored in memory, in other
words, as a series of octets. In other words, it's stored in "raw"
format, without any conversion or representation in ascii.

Thus the term "binary" is used with two different meanings: In some
contexts it talks about base-2 (ascii) representation, in other contexts
it talks about raw, unconverted byte values (eg. when saying "open the
file in binary mode). These two things have basically nothing to do with
each other, except that they share the name "binary".

Maybe this is the reason why it seems that some people get even more
confused and think "hexadecima l" refers to what usually is meant with
"binary" (in the second meaning).

[James Kanze]

On Oct 30, 8:14 pm, Juha Nieminen <nos...@thanks. invalidwrote:

Richard Herring wrote:

A value is just a value, it isn't "binary" any more than it
is "hexadecima l".

True, but it's difficult to talk about values and their
storage when the terminology is so confusing.

"Hexadecima l" refers quite unambiguously to the (usually
ascii) representation of a numerical value (in base 16). The
term "binary" is more complicated.

In theory when you say "the number is stored in binary" it
might refer to one of two things:

1) It's stored in base-2 representation. That is, the number
is stored by writing a combination of the two characters '0'
and '1'.

That is, actually, what is required by the C++ standard.

Of course, since only two characters are involved, a character
encoding using just one bit (rather than the usual 7, 8 or more)
is sufficient, and used by all of the implementations I've ever
encountered.

(Sort of a half :-). Just thought I'd add to the confusion, for
the fun of it.)

2) It's stored in the same way as it's stored in memory, in
other words, as a series of octets. In other words, it's
stored in "raw" format, without any conversion or
representation in ascii.

I like the word "raw". Or "machine" or "hardware" representation.

The C++ standard requires this to be a pure binary
representation (and I don't think the intent is to require
ASCII).

Of course, all of the standard requirements are "as if"; an
implementation can use base 10, as long as it implements &, |, ^
and ~ in a manner that they behave "as if" the representation
were base 2.

Thus the term "binary" is used with two different meanings: In
some contexts it talks about base-2 (ascii) representation, in
other contexts it talks about raw, unconverted byte values
(eg. when saying "open the file in binary mode). These two
things have basically nothing to do with each other, except
that they share the name "binary".

And that they are both demonstrably base 2. (Consider the
behavior of |, &, ^ and ~.)

Maybe this is the reason why it seems that some people get
even more confused and think "hexadecima l" refers to what
usually is meant with "binary" (in the second meaning).

Since most modern machines are byte oriented, maybe we should
call machine format base 256.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]