dev-cpp-users — Dev-C++ users discussion list

[Dev-C++] String encoding between Server-Client connection

[Jonathan M. G. <jgu...@nt...>]

Hello Gurus,

For days, I have been trying to find a solution about
a bug on my prototype. As all of you can see, the Client
is a VC++ implementation that sends a japanese message
string to a Linux C++ Server. The connection seems correct but
during the time I try to display the string message, it
is corrupted. Please take note that both OS supports
Japanese encoding as its default locale. When sending back
the string message to the VC++ Client, the Japanese string
message is displayed correctly. My guess is that Linux can't
handle Window's Japanese encoding (SJIS). Does any of you
encountered the same problem before? It would be a great
help for me for any information from you. :)

Thank you very much.

--
Jonathan.

Re: [Dev-C++] strcpy x pointer array

[Ioannis V. <no...@ho...>]

-------Original Message-------=0D
 =0D
From: Andr=E9 Mac=E1rio Barros=0D
Date: =D0=E1=F1=E1=F3=EA=E5=F5=DE, 7 =CC=DC=F1=F4=E9=EF=F2 2003 1:30:46 =F0=
=EC=0D
To: Dev-Cpp-Users=0D
Subject: [Dev-C++] strcpy x pointer array=0D
 =0D
1. Please consider the following piece of code=0D
=0D
#include <stdio.h>=0D
#include <string.h>=0D
=2E..=0D
int main()=0D
{=0D
char *vect[100];=0D
=0D
=2E..=0D
/* line x */ vect[3]=3D"text";=0D
=2E..=0D
/* line y */ strcpy(vect[3], "text");=0D
=2E..=0D
}=0D
=2E..=0D
=0D
2. Both commands in lines x and y don=B4t gererate any compilation errors=
;=0D
=0D
3. The command in line x works fine;=0D
=0D
4. Why the command in line y generates an execution error interrupting th=
e=0D
execution of=0D
the program?=0D
=0D
=0D
=3D=3D> What you did is similar to:=0D
=0D
const char *p=3D"text";=0D
=0D
strcpy(p, "text");=0D
=0D
=0D
=3D=3D> After some thinking you will understand why & what it means.=0D
=0D
=0D
=0D
Ioannis Vranos=0D
=0D
* Programming pages: http://www.noicys.freeurl.com=0D
* Alternative URL: http://run.to/noicys=20

Re: [Dev-C++] Some extra bytes written to file?

[Ioannis V. <no...@ho...>]

-------Original Message-------=0D
 =0D
From: Per Westermark=0D
Date: =D0=E1=F1=E1=F3=EA=E5=F5=DE, 7 =CC=DC=F1=F4=E9=EF=F2 2003 1:18:58 =F0=
=EC=0D
To: "J=F6rgen"=0D
Cc: Ioannis Vranos; dev...@li...=0D
Subject: Re: [Dev-C++] Some extra bytes written to file?=0D
 =0D
No problem about the extra 0x0d before a 0x0a.=0D
=0D
Every heard about CR+LF, i.e. carriage return + line feed.=0D
=0D
Whenever you open the file in text mode on a MSDos or Windows machine, yo=
u=0D
will get the automatic addition, i.e. printf("hello\n"); will actually=0D
emit "hello\r\n", and when you load the file in text mode, the extra CR=0D
will be removed.=0D
=0D
People normally only programming on Unix machines tries to forget this=0D
little Microsoft extra, resulting in big problems reading and or writing=0D
binary files.=0D
=0D
=0D
=3D=3D> Yes, this is also the case to change line in .NET multiline Text =
boxes.
I can't understand why...=0D
=0D
=0D
=0D
Ioannis Vranos=0D
=0D
* Programming pages: http://www.noicys.freeurl.com=0D
* Alternative URL: http://run.to/noicys=20

Re: [Dev-C++] Some extra bytes written to file?

[Ioannis V. <no...@ho...>]

-------Original Message-------=0D
 =0D
From: "J=F6rgen"=0D
Date: =D0=E1=F1=E1=F3=EA=E5=F5=DE, 7 =CC=DC=F1=F4=E9=EF=F2 2003 12:59:43 =
=F0=EC=0D
To: Ioannis Vranos; dev...@li...=0D
Subject: Re: [Dev-C++] Some extra bytes written to file?=0D
 =0D
See comments...=0D
 =0D
 =0D
[comment] =0D
What I'm trying to do is to reduce the size of the written file. Casting =
to
unsigned long gives=0D
me no reduction in size.=0D
E.g. =0D
  4 * char  =3D 4 * 8 =3D 32 bits =3D 4 bytes. =0D
  4 * unsigned long =3D 4 * 32 =3D 128 bits =3D 32 bytes=0D
 =0D
 =0D
 =0D
=3D=3D> At first as i said you apply casting wrong. =0D
=0D
=3D=3D> For example you wrote:=0D
=0D
foo << ((unsigned char) (value[i][0] & 0x000000FF)); =0D
=0D
=0D
=3D=3D> But it should be:=0D
=0D
foo << (unsigned char) (value[i][0]) & 0x000000FF; =0D
=0D
or better:=0D
=0D
foo << static_cast<unsigned char> (value[i][0]) & 0x000000FF; =0D
=0D
=0D
=3D=3D> or better you should have used bitset<unsigned whatever> from the
beginning.=0D
=0D
=0D
=3D=3D> After that, you are do these bitwise things to reduce the size? =0D
 =0D
=3D=3D> Keep in mind that for size reduction, binary file mode is better =
(but
with the cost of non=0D
file portability).=0D
 =0D
 =0D
[comment]=0D
 =0D
First. There are no negative integers (int) in the data so the problem
shouldn't be happening.=0D
Second. Lets say that the value of the int to be casted is 130. In bits i=
t
is written=0D
00000000 00000000 00000000 10000010=0D
Then it is masket with =0D
00000000 00000000 00000000 11111111=0D
and the result is=0D
00000000 00000000 00000000 10000010=0D
Now it is casted to unsigned char and we got the following bits=0D
10000010=0D
The value is still 130. If it were a signed char the bitrepresentation wo=
uld
still be=0D
10000010=0D
but the value would be -126=0D
 =0D
 =0D
=3D=3D> You can assume nothing about the implementation. You can assume a=
fter
the casting=0D
which you did wrong. Also for values larger than numeric_limits<unsigned
char>::max() you=0D
get data truncation.=0D
=0D
=0D
=0D
 =0D
 =0D
Ioannis Vranos=0D
 =0D
* Programming pages: http://www.noicys.freeurl.com=0D
* Alternative URL: http://run.to/noicys=20

Re: [Dev-C++] strcpy x pointer array

[Per W. <pw...@ia...>]

How about vect[3] =3D new char[strlen("text")+1];

/Per W

On Fri, 7 Mar 2003, Zodiaq wrote:

> Hello Andr=E9 and all Dev-C++ users,
>
> Friday, March 7, 2003, 12:27:42 AM, Andr=E9 wrote as follows:
>
> AMB> 1. Please consider the following piece of code
>
> AMB>    #include <stdio.h>
> AMB>    #include <string.h>
> AMB>    ...
> AMB>    int main()
> AMB>    {
> AMB>       char *vect[100];
>
> AMB>       ...
> AMB>       /* line x */ vect[3]=3D"text";
> AMB>       ...
> AMB>       /* line y */ strcpy(vect[3], "text");
> AMB>       ...
> AMB>    }
> AMB>    ...
>
> AMB> 2. Both commands in lines x and y don=B4t gererate any compilation e=
rrors;
>
> AMB> 3. The command in line x works fine;
>
> You are asigning a new value for pointer at vect[3] which is ok...
>
> AMB> 4. Why the command in line y generates an execution error interrupti=
ng the
> AMB> execution of
> AMB>    the program?
>
> You are copying string "text" to const value "text" - pointer from
> line x points at this...
>
> Before line y, first get some space to hold new data:
> vect[3]=3D new char[ strlen( "text" )];
> now strcpy should work fine
>
>
> --
> regards, Zodiaq
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugg=
er
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNI=
X
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Re: [Dev-C++] strcpy x pointer array

[Zodiaq <zo...@ac...>]

Hello André and all Dev-C++ users,

Friday, March 7, 2003, 12:27:42 AM, André wrote as follows:

AMB> 1. Please consider the following piece of code

AMB>    #include <stdio.h>
AMB>    #include <string.h>
AMB>    ...
AMB>    int main()
AMB>    {
AMB>       char *vect[100];

AMB>       ...
AMB>       /* line x */ vect[3]="text";
AMB>       ...
AMB>       /* line y */ strcpy(vect[3], "text");
AMB>       ...
AMB>    }
AMB>    ...

AMB> 2. Both commands in lines x and y don´t gererate any compilation errors;

AMB> 3. The command in line x works fine;

You are asigning a new value for pointer at vect[3] which is ok...

AMB> 4. Why the command in line y generates an execution error interrupting the
AMB> execution of
AMB>    the program?

You are copying string "text" to const value "text" - pointer from
line x points at this...

Before line y, first get some space to hold new data:
vect[3]= new char[ strlen( "text" )];
now strcpy should work fine


-- 
regards, Zodiaq

Re: [Dev-C++] strcpy x pointer array

[Per W. <pw...@ia...>]

char *vect[100] means that you have an array of 100 character pointers.

the first assignment assigns the address of a string, i.e. a character
pointer to the 4th element of your array. That's ok.

Your line 'y' on the other hand tries to copy data to the pointer already
stored in vect[3].

If you run without line x, vect[3] will point to random address and the
copy will most probably fail misserably.

If you run with line x, vect[3] will point to a constant, i.e.
write-protected (for most environments at least), text string that your
compiler has created. The strcpy() call will then fail misserably when it
tries to overwrite the write-protected memory where the first "text"
string is stored.

You might do:
  vect[3] =3D strdup("text");
  ...
  free(vect[3]);

strdup() will first allocate a block of memory large enough for the
string. Then it will copy "text" to the new memory block. Then it will set
the character pointer vect[3] to point at the newly allocated memory.

However, to avoid memory leaks, you must then release the memory that
strdup() allocated, i..e calling free() on it.

/Per W


On Thu, 6 Mar 2003, Andr=E9 Mac=E1rio Barros wrote:

> 1. Please consider the following piece of code
>
>    #include <stdio.h>
>    #include <string.h>
>    ...
>    int main()
>    {
>       char *vect[100];
>
>       ...
>       /* line x */ vect[3]=3D"text";
>       ...
>       /* line y */ strcpy(vect[3], "text");
>       ...
>    }
>    ...
>
> 2. Both commands in lines x and y don=B4t gererate any compilation errors=
;
>
> 3. The command in line x works fine;
>
> 4. Why the command in line y generates an execution error interrupting th=
e
> execution of
>    the program?
>
> Regards
> Andre
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugg=
er
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNI=
X
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Re: [Dev-C++] Some extra bytes written to file?

[<qa...@ho...>]

Ahhh, I see. Thought there was a simple explanation to the problem.

/J=F6rgen


*********** REPLY SEPARATOR  ***********

On 2003-03-07 at 00:18 Per Westermark wrote:

>No problem about the extra 0x0d before a 0x0a.
>
>Every heard about CR+LF, i.e. carriage return + line feed.
>
>Whenever you open the file in text mode on a MSDos or Windows machine, you
>will get the automatic addition, i.e. printf("hello\n"); will actually
>emit "hello\r\n", and when you load the file in text mode, the extra CR
>will be removed.
>
>People normally only programming on Unix machines tries to forget this
>little Microsoft extra, resulting in big problems reading and or writing
>binary files.
>
>/Per W
>
>On Thu, 6 Mar 2003, "J=F6rgen" wrote:
>
>> See comments...
>>
>> *********** REPLY SEPARATOR ***********
>>
>> On 2003-03-06 at 23:42 Ioannis Vranos wrote:
>> Important correction:
>>
>>
>>  -------Original Message-------
>>
>> From: Ioannis Vranos
>> Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 11:37:40 =EC=EC
>> To: Dev-C++ Mailing List
>> Subject: Re: [Dev-C++] Some extra bytes written to file?
>>
>> -------Original Message-------
>>
>> From: "J=F6rgen"
>> Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 5:00:15 =EC=EC
>> To: dev...@li...
>> Subject: [Dev-C++] Some extra bytes written to file?
>>
>> Hi.
>>
>> This problem puzzles me. I have the following data.
>> -4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4
>6 0
>> 4 7 0 4 8 0 4 9
>> 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1
>>
>> I'm not to familiar with reg.exp, but I guess that the reg.exp. for the
>data
>> would be
>> result [value1 value2 value3]*
>>
>> where
>> result is an integer but is always in the range -64 to 64
>> value1 is an integer but is always in the range 0 to 11
>> value2 is an integer but is always in the range 0 to 65536
>> value3 is an integer but is always in the range 0 to 4
>>
>> let's say that we call [value1 value2 value3] for 'value' and
>'nbrOfValues'
>> the number of sets
>> of 'value'. In this case nbrOfvalues =3D 20
>>
>> When I write the data to file, using ofstream foo("foofile") I do it in
>the
>> following way
>>
>>
>> =3D=3D> Since it is C++, why don't you use bitset<> elegantly and
>efficiently?
>> [commment]
>> Where should I use it? I can't see the purpose for it.
>>
>>
>> if(result < 0)
>> foo << '-';
>> else
>> foo << '+';
>> foo << ((unsigned char) (abs(result) & 0x000000FF));
>>
>> for(int i=3D0; i<numberOfValues; i++){
>> foo << ((unsigned char) (value[i][0] & 0x000000FF));
>> foo << ((unsigned char) ((value[i][1] & 0x0000FF00) >> 8));
>> foo << ((unsigned char) (value[i][1] & 0x000000FF));
>> foo << ((unsigned char) (value[i][2] & 0x000000FF));
>>
>>
>> =3D=3D> CORRECTION: Since value2 is [0,65536] use unsigned long. E.g.
>>
>> for(int i=3D0; i<numberOfValues; i++){
>> foo << static_cast<unsigned long> (value[i][0]) & 0x000000FF;
>> foo << static_cast<unsigned long>(value[i][1]) & 0x0000FF00 >> 8;
>> foo << static_cast<unsigned long> (value[i][1]) & 0x000000FF;
>> foo << static_cast<unsigned long> (value[i][2]) & 0x000000FF;
>>
>>
>> =3D=3D>CORRECTION: The casting should be applied "before" the bitwise
>operation.
>> [comment]
>> What I'm trying to do is to reduce the size of the written file. Casting
>to unsigned long gives me no reduction in size.
>> E.g.
>>   4 * char  =3D 4 * 8 =3D 32 bits =3D 4 bytes.
>>   4 * unsigned long =3D 4 * 32 =3D 128 bits =3D 32 bytes
>>
>>
>>
>>
>> }
>>
>> The problem comes when I read the data from file. If I just reverse the
>> procedure and prints
>> the decoded data to screen I get
>> -4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4
>6 0
>> 4 7 0 4 8 0 4 9 0
>> 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 0 80 114
>>
>> It looks just the same as the original data except for the last three
>> numbers (0 80 114).
>>
>> When looking at the filesize it shows that it is 85 bytes, but the data
>> written is only 82 bytes
>>
>> For debugging purposes, instead of writing directly to file, I first
>store
>> everything in a
>> string s. That is, replacing foo << ... with s +=3D ... Finally I write=
 it
>to
>> file with foo << s;
>>
>> When I print the string s to screen in hex-mode
>>
>> cout.setf( ios_base::hex, ios_base::basefield );
>> for(int i=3D0; i<s.size(); i++)
>> cout << " " << s[i];
>>
>> it gives the following output
>> 2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f
>1 4
>> 0 0 8 5 0 0 4 6 0
>> 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 a 0 1b 2 a 0 24 1 a 0 36 1 b 0 6c 1
>b
>> 0 bd 1
>> and it is the way it should be
>>
>> But when I look at the datafile in a hexeditor I see
>> 2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f
>1 4
>> 0 0 8 5 0 0 4 6 0
>> 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 d a 0 1b 2 d a 0 24 1 d a 0 36 1 b
>0 6c
>> 1 b 0 bd 1
>>
>> An extra byte 'd' emerges before every one of the three "value1"-'a'
>bytes
>> (d a 0 1b 2 , d a 0 24 1 , d a 0 36 1).
>>
>> Where did these 'd' bytes come from?
>>
>>
>> =3D=3D> Truncation. You "bitwise" a signed value (casted to unsigned=
 type)
>and
>> its bit, marking its signess floats around. Also keep in mind that the
>> binary representation of negative values is radically different from the
>> positive ones.
>>
>> [comment]
>> First. There are no negative integers (int) in the data so the problem
>shouldn't be happening.
>> Second. Lets say that the value of the int to be casted is 130. In bits
>it is written
>> 00000000 00000000 00000000 10000010
>> Then it is masket with
>> 00000000 00000000 00000000 11111111
>> and the result is
>> 00000000 00000000 00000000 10000010
>> Now it is casted to unsigned char and we got the following bits
>> 10000010
>> The value is still 130. If it were a signed char the bitrepresentation
>would still be
>> 10000010
>> but the value would be -126
>>
>>
>>
>> Why are the only occuring in front of the 'a' byte?
>> How come that when I print the data to screen it does not mess up the
>values
>> but instead
>> appends (0 80 114) at the end?
>>
>>
>> =3D=3D> Hmmm.
>> [comment]
>> Couldn't agree more
>>
>>
>>
>> Ioannis Vranos
>>
>> * Programming pages: http://www.noicys.freeurl.com
>> * Alternative URL: http://run.to/noicys
>>
>>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Etnus, makers of TotalView, The
>debugger 
>for complex code. Debugging C/C++ programs can leave you feeling lost and 
>disoriented. TotalView can help you find your way. Available on major UNIX=
 
>and Linux platforms. Try it free. www.etnus.com
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

[Dev-C++] strcpy x pointer array

[<and...@su...>]

1. Please consider the following piece of code

   #include <stdio.h>
   #include <string.h>
   ...
   int main()
   {
      char *vect[100];

      ...
      /* line x */ vect[3]="text";
      ...
      /* line y */ strcpy(vect[3], "text");
      ...
   }
   ...

2. Both commands in lines x and y don´t gererate any compilation errors;

3. The command in line x works fine;

4. Why the command in line y generates an execution error interrupting the
execution of
   the program?

Regards
Andre

Re: [Dev-C++] Some extra bytes written to file?

[Per W. <pw...@ia...>]

No problem about the extra 0x0d before a 0x0a.

Every heard about CR+LF, i.e. carriage return + line feed.

Whenever you open the file in text mode on a MSDos or Windows machine, you
will get the automatic addition, i.e. printf("hello\n"); will actually
emit "hello\r\n", and when you load the file in text mode, the extra CR
will be removed.

People normally only programming on Unix machines tries to forget this
little Microsoft extra, resulting in big problems reading and or writing
binary files.

/Per W

On Thu, 6 Mar 2003, "J=F6rgen" wrote:

> See comments...
>
> *********** REPLY SEPARATOR ***********
>
> On 2003-03-06 at 23:42 Ioannis Vranos wrote:
> Important correction:
>
>
>  -------Original Message-------
>
> From: Ioannis Vranos
> Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 11:37:40 =EC=EC
> To: Dev-C++ Mailing List
> Subject: Re: [Dev-C++] Some extra bytes written to file?
>
> -------Original Message-------
>
> From: "J=F6rgen"
> Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 5:00:15 =EC=EC
> To: dev...@li...
> Subject: [Dev-C++] Some extra bytes written to file?
>
> Hi.
>
> This problem puzzles me. I have the following data.
> -4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6=
 0
> 4 7 0 4 8 0 4 9
> 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1
>
> I'm not to familiar with reg.exp, but I guess that the reg.exp. for the d=
ata
> would be
> result [value1 value2 value3]*
>
> where
> result is an integer but is always in the range -64 to 64
> value1 is an integer but is always in the range 0 to 11
> value2 is an integer but is always in the range 0 to 65536
> value3 is an integer but is always in the range 0 to 4
>
> let's say that we call [value1 value2 value3] for 'value' and 'nbrOfValue=
s'
> the number of sets
> of 'value'. In this case nbrOfvalues =3D 20
>
> When I write the data to file, using ofstream foo("foofile") I do it in t=
he
> following way
>
>
> =3D=3D> Since it is C++, why don't you use bitset<> elegantly and efficie=
ntly?
> [commment]
> Where should I use it? I can't see the purpose for it.
>
>
> if(result < 0)
> foo << '-';
> else
> foo << '+';
> foo << ((unsigned char) (abs(result) & 0x000000FF));
>
> for(int i=3D0; i<numberOfValues; i++){
> foo << ((unsigned char) (value[i][0] & 0x000000FF));
> foo << ((unsigned char) ((value[i][1] & 0x0000FF00) >> 8));
> foo << ((unsigned char) (value[i][1] & 0x000000FF));
> foo << ((unsigned char) (value[i][2] & 0x000000FF));
>
>
> =3D=3D> CORRECTION: Since value2 is [0,65536] use unsigned long. E.g.
>
> for(int i=3D0; i<numberOfValues; i++){
> foo << static_cast<unsigned long> (value[i][0]) & 0x000000FF;
> foo << static_cast<unsigned long>(value[i][1]) & 0x0000FF00 >> 8;
> foo << static_cast<unsigned long> (value[i][1]) & 0x000000FF;
> foo << static_cast<unsigned long> (value[i][2]) & 0x000000FF;
>
>
> =3D=3D>CORRECTION: The casting should be applied "before" the bitwise ope=
ration.
> [comment]
> What I'm trying to do is to reduce the size of the written file. Casting =
to unsigned long gives me no reduction in size.
> E.g.
>   4 * char  =3D 4 * 8 =3D 32 bits =3D 4 bytes.
>   4 * unsigned long =3D 4 * 32 =3D 128 bits =3D 32 bytes
>
>
>
>
> }
>
> The problem comes when I read the data from file. If I just reverse the
> procedure and prints
> the decoded data to screen I get
> -4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6=
 0
> 4 7 0 4 8 0 4 9 0
> 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 0 80 114
>
> It looks just the same as the original data except for the last three
> numbers (0 80 114).
>
> When looking at the filesize it shows that it is 85 bytes, but the data
> written is only 82 bytes
>
> For debugging purposes, instead of writing directly to file, I first stor=
e
> everything in a
> string s. That is, replacing foo << ... with s +=3D ... Finally I write i=
t to
> file with foo << s;
>
> When I print the string s to screen in hex-mode
>
> cout.setf( ios_base::hex, ios_base::basefield );
> for(int i=3D0; i<s.size(); i++)
> cout << " " << s[i];
>
> it gives the following output
> 2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1=
 4
> 0 0 8 5 0 0 4 6 0
> 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 a 0 1b 2 a 0 24 1 a 0 36 1 b 0 6c 1 =
b
> 0 bd 1
> and it is the way it should be
>
> But when I look at the datafile in a hexeditor I see
> 2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1=
 4
> 0 0 8 5 0 0 4 6 0
> 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 d a 0 1b 2 d a 0 24 1 d a 0 36 1 b 0=
 6c
> 1 b 0 bd 1
>
> An extra byte 'd' emerges before every one of the three "value1"-'a' byte=
s
> (d a 0 1b 2 , d a 0 24 1 , d a 0 36 1).
>
> Where did these 'd' bytes come from?
>
>
> =3D=3D> Truncation. You "bitwise" a signed value (casted to unsigned type=
) and
> its bit, marking its signess floats around. Also keep in mind that the
> binary representation of negative values is radically different from the
> positive ones.
>
> [comment]
> First. There are no negative integers (int) in the data so the problem sh=
ouldn't be happening.
> Second. Lets say that the value of the int to be casted is 130. In bits i=
t is written
> 00000000 00000000 00000000 10000010
> Then it is masket with
> 00000000 00000000 00000000 11111111
> and the result is
> 00000000 00000000 00000000 10000010
> Now it is casted to unsigned char and we got the following bits
> 10000010
> The value is still 130. If it were a signed char the bitrepresentation wo=
uld still be
> 10000010
> but the value would be -126
>
>
>
> Why are the only occuring in front of the 'a' byte?
> How come that when I print the data to screen it does not mess up the val=
ues
> but instead
> appends (0 80 114) at the end?
>
>
> =3D=3D> Hmmm.
> [comment]
> Couldn't agree more
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys
>
>

Re: [Dev-C++] Some extra bytes written to file?

[<qa...@ho...>]

See comments...

*********** REPLY SEPARATOR ***********

On 2003-03-06 at 23:42 Ioannis Vranos wrote:
Important correction:


 -------Original Message-------

From: Ioannis Vranos
Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 11:37:40 =EC=EC
To: Dev-C++ Mailing List
Subject: Re: [Dev-C++] Some extra bytes written to file?

-------Original Message------- 

From: "J=F6rgen" 
Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 5:00:15 =EC=EC 
To: dev...@li... 
Subject: [Dev-C++] Some extra bytes written to file? 

Hi. 

This problem puzzles me. I have the following data. 
-4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6 0
4 7 0 4 8 0 4 9 
0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 

I'm not to familiar with reg.exp, but I guess that the reg.exp. for the=
 data
would be 
result [value1 value2 value3]* 

where 
result is an integer but is always in the range -64 to 64 
value1 is an integer but is always in the range 0 to 11 
value2 is an integer but is always in the range 0 to 65536 
value3 is an integer but is always in the range 0 to 4 

let's say that we call [value1 value2 value3] for 'value' and 'nbrOfValues'
the number of sets 
of 'value'. In this case nbrOfvalues =3D 20 

When I write the data to file, using ofstream foo("foofile") I do it in the
following way 


=3D=3D> Since it is C++, why don't you use bitset<> elegantly and=
 efficiently? 
[commment] 
Where should I use it? I can't see the purpose for it.


if(result < 0) 
foo << '-'; 
else 
foo << '+'; 
foo << ((unsigned char) (abs(result) & 0x000000FF)); 

for(int i=3D0; i<numberOfValues; i++){ 
foo << ((unsigned char) (value[i][0] & 0x000000FF)); 
foo << ((unsigned char) ((value[i][1] & 0x0000FF00) >> 8)); 
foo << ((unsigned char) (value[i][1] & 0x000000FF)); 
foo << ((unsigned char) (value[i][2] & 0x000000FF)); 


=3D=3D> CORRECTION: Since value2 is [0,65536] use unsigned long. E.g. 

for(int i=3D0; i<numberOfValues; i++){ 
foo << static_cast<unsigned long> (value[i][0]) & 0x000000FF; 
foo << static_cast<unsigned long>(value[i][1]) & 0x0000FF00 >> 8; 
foo << static_cast<unsigned long> (value[i][1]) & 0x000000FF; 
foo << static_cast<unsigned long> (value[i][2]) & 0x000000FF; 


=3D=3D>CORRECTION: The casting should be applied "before" the bitwise=
 operation.
[comment] 
What I'm trying to do is to reduce the size of the written file. Casting to=
 unsigned long gives me no reduction in size.
E.g. 
  4 * char  =3D 4 * 8 =3D 32 bits =3D 4 bytes. 
  4 * unsigned long =3D 4 * 32 =3D 128 bits =3D 32 bytes




} 

The problem comes when I read the data from file. If I just reverse the
procedure and prints 
the decoded data to screen I get 
-4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6 0
4 7 0 4 8 0 4 9 0 
3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 0 80 114 

It looks just the same as the original data except for the last three
numbers (0 80 114). 

When looking at the filesize it shows that it is 85 bytes, but the data
written is only 82 bytes 

For debugging purposes, instead of writing directly to file, I first store
everything in a 
string s. That is, replacing foo << ... with s +=3D ... Finally I write it=
 to
file with foo << s; 

When I print the string s to screen in hex-mode 

cout.setf( ios_base::hex, ios_base::basefield ); 
for(int i=3D0; i<s.size(); i++) 
cout << " " << s[i]; 

it gives the following output 
2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1 4
0 0 8 5 0 0 4 6 0 
0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 a 0 1b 2 a 0 24 1 a 0 36 1 b 0 6c 1 b
0 bd 1 
and it is the way it should be 

But when I look at the datafile in a hexeditor I see 
2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1 4
0 0 8 5 0 0 4 6 0 
0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 d a 0 1b 2 d a 0 24 1 d a 0 36 1 b 0=
 6c
1 b 0 bd 1 

An extra byte 'd' emerges before every one of the three "value1"-'a' bytes 
(d a 0 1b 2 , d a 0 24 1 , d a 0 36 1). 

Where did these 'd' bytes come from? 


=3D=3D> Truncation. You "bitwise" a signed value (casted to unsigned type)=
 and
its bit, marking its signess floats around. Also keep in mind that the
binary representation of negative values is radically different from the
positive ones. 

[comment]
First. There are no negative integers (int) in the data so the problem=
 shouldn't be happening.
Second. Lets say that the value of the int to be casted is 130. In bits it=
 is written
00000000 00000000 00000000 10000010
Then it is masket with 
00000000 00000000 00000000 11111111
and the result is
00000000 00000000 00000000 10000010
Now it is casted to unsigned char and we got the following bits
10000010
The value is still 130. If it were a signed char the bitrepresentation=
 would still be
10000010
but the value would be -126



Why are the only occuring in front of the 'a' byte? 
How come that when I print the data to screen it does not mess up the=
 values
but instead 
appends (0 80 114) at the end? 


=3D=3D> Hmmm. 
[comment]
Couldn't agree more



Ioannis Vranos 

* Programming pages: http://www.noicys.freeurl.com 
* Alternative URL: http://run.to/noicys 

RE: [Dev-C++] New project with GTK and Dev-Cpp 4970

[Rodolfo d'E. <rod...@la...>]

Hi,

In an existing GTK project click the menu item Project Options, in the =
"General" tab, in compiler options replace:

  -fnative-struct=20

with=20


-mms-bitfields=20

Do the same in linker options. Also do the same substitution  in the =
file gtk+.template, so that you will have that change in every new GTK =
project.

Good luck

Rodolfo d'Ettorre

Re: [Dev-C++] Some extra bytes written to file?

[Ioannis V. <no...@ho...>]

Important correction:=0D
=0D
=0D
 -------Original Message-------=0D
 =0D
From: Ioannis Vranos=0D
Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 11:37:40 =EC=EC=0D
To: Dev-C++ Mailing List=0D
Subject: Re: [Dev-C++] Some extra bytes written to file?=0D
 =0D
-------Original Message------- =0D
=0D
From: "J=F6rgen" =0D
Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 5:00:15 =EC=EC =0D
To: dev...@li... =0D
Subject: [Dev-C++] Some extra bytes written to file? =0D
=0D
Hi. =0D
=0D
This problem puzzles me. I have the following data. =0D
-4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6=
 0=0D
4 7 0 4 8 0 4 9 =0D
0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 =0D
=0D
I'm not to familiar with reg.exp, but I guess that the reg.exp. for the d=
ata=0D
would be =0D
result [value1 value2 value3]* =0D
=0D
where =0D
result is an integer but is always in the range -64 to 64 =0D
value1 is an integer but is always in the range 0 to 11 =0D
value2 is an integer but is always in the range 0 to 65536 =0D
value3 is an integer but is always in the range 0 to 4 =0D
=0D
let's say that we call [value1 value2 value3] for 'value' and 'nbrOfValue=
s'=0D
the number of sets =0D
of 'value'. In this case nbrOfvalues =3D 20 =0D
=0D
When I write the data to file, using ofstream foo("foofile") I do it in t=
he=0D
following way =0D
=0D
=0D
=3D=3D> Since it is C++, why don't you use bitset<> elegantly and efficie=
ntly? =0D
=0D
=0D
=0D
if(result < 0) =0D
foo << '-'; =0D
else =0D
foo << '+'; =0D
foo << ((unsigned char) (abs(result) & 0x000000FF)); =0D
=0D
for(int i=3D0; i<numberOfValues; i++){ =0D
foo << ((unsigned char) (value[i][0] & 0x000000FF)); =0D
foo << ((unsigned char) ((value[i][1] & 0x0000FF00) >> 8)); =0D
foo << ((unsigned char) (value[i][1] & 0x000000FF)); =0D
foo << ((unsigned char) (value[i][2] & 0x000000FF)); =0D
=0D
=0D
=3D=3D> CORRECTION: Since value2 is [0,65536] use unsigned long. E.g. =0D
=0D
for(int i=3D0; i<numberOfValues; i++){ =0D
foo << static_cast<unsigned long> (value[i][0]) & 0x000000FF; =0D
foo << static_cast<unsigned long>(value[i][1]) & 0x0000FF00 >> 8; =0D
foo << static_cast<unsigned long> (value[i][1]) & 0x000000FF; =0D
foo << static_cast<unsigned long> (value[i][2]) & 0x000000FF; =0D
=0D
=0D
=3D=3D>CORRECTION: The casting should be applied "before" the bitwise ope=
ration.=0D
=0D
=0D
=0D
=0D
} =0D
=0D
The problem comes when I read the data from file. If I just reverse the=0D
procedure and prints =0D
the decoded data to screen I get =0D
-4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6=
 0=0D
4 7 0 4 8 0 4 9 0 =0D
3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 0 80 114 =0D
=0D
It looks just the same as the original data except for the last three=0D
numbers (0 80 114). =0D
=0D
When looking at the filesize it shows that it is 85 bytes, but the data=0D
written is only 82 bytes =0D
=0D
For debugging purposes, instead of writing directly to file, I first stor=
e=0D
everything in a =0D
string s. That is, replacing foo << ... with s +=3D ... Finally I write i=
t to=0D
file with foo << s; =0D
=0D
When I print the string s to screen in hex-mode =0D
=0D
cout.setf( ios_base::hex, ios_base::basefield ); =0D
for(int i=3D0; i<s.size(); i++) =0D
cout << " " << s[i]; =0D
=0D
it gives the following output =0D
2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1=
 4=0D
0 0 8 5 0 0 4 6 0 =0D
0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 a 0 1b 2 a 0 24 1 a 0 36 1 b 0 6c 1 =
b=0D
0 bd 1 =0D
and it is the way it should be =0D
=0D
But when I look at the datafile in a hexeditor I see =0D
2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1=
 4=0D
0 0 8 5 0 0 4 6 0 =0D
0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 d a 0 1b 2 d a 0 24 1 d a 0 36 1 b 0=
 6c=0D
1 b 0 bd 1 =0D
=0D
An extra byte 'd' emerges before every one of the three "value1"-'a' byte=
s =0D
(d a 0 1b 2 , d a 0 24 1 , d a 0 36 1). =0D
=0D
Where did these 'd' bytes come from? =0D
=0D
=0D
=3D=3D> Truncation. You "bitwise" a signed value (casted to unsigned type=
) and=0D
its bit, marking its signess floats around. Also keep in mind that the=0D
binary representation of negative values is radically different from the=0D
positive ones. =0D
=0D
=0D
Why are the only occuring in front of the 'a' byte? =0D
How come that when I print the data to screen it does not mess up the val=
ues=0D
but instead =0D
appends (0 80 114) at the end? =0D
=0D
=0D
=3D=3D> Hmmm. =0D
=0D
=0D
=0D
Ioannis Vranos =0D
=0D
* Programming pages: http://www.noicys.freeurl.com =0D
* Alternative URL: http://run.to/noicys=20

Re: [Dev-C++] Some extra bytes written to file?

[Ioannis V. <no...@ho...>]

-------Original Message-------=0D
 =0D
From: "J=F6rgen"=0D
Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 6:44:34 =EC=EC=0D
To: Per Westermark=0D
Cc: dev...@li...=0D
Subject: Re: [Dev-C++] Some extra bytes written to file?=0D
 =0D
Hi,=0D
=0D
The type is signed, but as you can see there are no negative values [0...=
11,
0...65536, 0...4], so that shouldn't be the problem because the most
significant bit is zero. I've tried every possible combination I can thin=
k
of but I can't not figure out where the extra bytes comes from.=0D
=0D
=0D
=3D=3D> Strictly speaking you do not know how the implementation implemen=
ts
signed types. It is only guaranteed to work with unsigned ones.=0D
=0D
=0D
=0D
Ioannis Vranos=0D
=0D
* Programming pages: http://www.noicys.freeurl.com=0D
* Alternative URL: http://run.to/noicys=20

Re: [Dev-C++] Some extra bytes written to file?

[Ioannis V. <no...@ho...>]

-------Original Message-------=0D
 =0D
From: "J=F6rgen"=0D
Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 5:00:15 =EC=EC=0D
To: dev...@li...=0D
Subject: [Dev-C++] Some extra bytes written to file?=0D
 =0D
Hi.=0D
 =0D
This problem puzzles me. I have the following data.=0D
-4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6=
 0
4 7 0 4 8 0 4 9=0D
 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1=0D
 =0D
I'm not to familiar with reg.exp, but I guess that the reg.exp. for the d=
ata
would be =0D
result [value1 value2 value3]*=0D
 =0D
where =0D
  result is an integer but is always in the range -64 to 64=0D
  value1 is an integer but is always in the range 0 to 11=0D
  value2 is an integer but is always in the range 0 to 65536=0D
  value3 is an integer but is always in the range 0 to 4=0D
 =0D
let's say that we call [value1 value2 value3] for 'value' and 'nbrOfValue=
s'
the number of sets=0D
 of 'value'. In this case nbrOfvalues =3D 20=0D
 =0D
When I write the data to file, using ofstream foo("foofile") I do it in t=
he
following way=0D
 =0D
 =0D
=3D=3D> Since it is C++, why don't you use bitset<> elegantly and efficie=
ntly?=0D
 =0D
 =0D
 =0D
if(result < 0)=0D
  foo << '-';=0D
else=0D
  foo << '+';=0D
foo << ((unsigned char) (abs(result) & 0x000000FF));=0D
 =0D
for(int i=3D0; i<numberOfValues; i++){=0D
  foo << ((unsigned char) (value[i][0] & 0x000000FF));=0D
  foo << ((unsigned char) ((value[i][1] & 0x0000FF00) >> 8));=0D
  foo << ((unsigned char) (value[i][1] & 0x000000FF));=0D
  foo << ((unsigned char) (value[i][2] & 0x000000FF));=0D
 =0D
 =0D
=3D=3D> Since value2 is [0,65536]  use unsigned long. E.g.=0D
 =0D
for(int i=3D0; i<numberOfValues; i++){=0D
  foo << static_cast<unsigned long> (value[i][0] & 0x000000FF);=0D
  foo << static_cast<unsigned long>(value[i][1] & 0x0000FF00) >> 8);=0D
  foo << static_cast<unsigned long> (value[i][1] & 0x000000FF);=0D
  foo << static_cast<unsigned long> (value[i][2] & 0x000000FF);=0D
 =0D
 =0D
 =0D
 =0D
}=0D
 =0D
The problem comes when I read the data from file. If I just reverse the
procedure and prints=0D
 the decoded data to screen I get=0D
-4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6=
 0
4 7 0 4 8 0 4 9 0=0D
 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 0 80 114=0D
 =0D
It looks just the same as the original data except for the last three
numbers (0 80 114).=0D
 =0D
When looking at the filesize it shows that it is 85 bytes, but the data
written is only 82 bytes=0D
 =0D
For debugging purposes, instead of writing directly to file, I first stor=
e
everything in a=0D
string s. That is, replacing foo << ... with s +=3D ... Finally I write i=
t to
file with foo << s;=0D
 =0D
When I print the string s to screen in hex-mode=0D
 =0D
cout.setf( ios_base::hex, ios_base::basefield );=0D
for(int i=3D0; i<s.size(); i++)=0D
  cout << " " << s[i];=0D
 =0D
it gives the following output=0D
2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1=
 4
0 0 8 5 0 0 4 6 0=0D
 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 a 0 1b 2 a 0 24 1 a 0 36 1 b 0 6c 1=
 b
0 bd 1=0D
and it is the way it should be =0D
 =0D
But when I look at the datafile in a hexeditor I see=0D
2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1=
 4
0 0 8 5 0 0 4 6 0=0D
0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 d a 0 1b 2 d a 0 24 1 d a 0 36 1 b 0=
 6c
1 b 0 bd 1=0D
 =0D
An extra byte 'd' emerges before every one of the three "value1"-'a' byte=
s =0D
(d a 0 1b 2 , d a 0 24 1 , d a 0 36 1).=0D
 =0D
Where did these 'd' bytes come from?=0D
 =0D
 =0D
=3D=3D> Truncation. You "bitwise" a signed value (casted to unsigned type=
) and
its bit, marking its signess floats around. Also keep in mind that the
binary representation of negative values is radically different from the
positive ones.=0D
 =0D
 =0D
Why are the only occuring in front of the 'a' byte?=0D
How come that when I print the data to screen it does not mess up the val=
ues
but instead=0D
appends (0 80 114) at the end?=0D
 =0D
 =0D
=3D=3D> Hmmm.=0D
 =0D
=0D
 =0D
Ioannis Vranos=0D
 =0D
* Programming pages: http://www.noicys.freeurl.com=0D
* Alternative URL: http://run.to/noicys=20

Re: [Dev-C++] flex/bison

[erwan a. <erw...@fr...>]

I use flex and bison with Dev-Cpp, and I just used a custom makefile to add
these dependencies. two targets defined in Dev-Cpp are used: all-before and
clean-custom

this is my sample custom makefile:



all-before:: build/lex.yy.cc build/yaccfile.cpp

build/lex.yy.cc: parser.lex build/yaccfile.cpp
    flex -obuild/lex.yy.cc parser.lex

build/yaccfile.cpp: parser.yacc
    bison -d -obuild/yaccfile.cpp parser.yacc

clean-custom::
    rm -f build/lex.yy.cc build/yaccfile.cpp build/yaccfile.hpp


----- Original Message -----
From: "Pierre Raoul" <pie...@wa...>
To: <dev...@li...>
Sent: Thursday, March 06, 2003 11:08 AM
Subject: [Dev-C++] flex/bison


Hello,

How to manage dependency relations with flex/bison files in Dev-Cpp? A long
time ago, I already asked this question, without any answer. Perhaps now,
somebody will have any idea about this issue...

Thanks

Pierre Raoul



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

Re: [Dev-C++] Some extra bytes written to file?

[Per W. <pw...@ia...>]

If you are using signed variables, you should be careful about

larger than 127 for char
larger than 32767 for int
larger than 2147483647 for long

or you will set the sign bit. If a small signed variable is type-converted
to a larget signed variable, it will be sign-extended, i.e. all "new" bits
of the larger integer will be set to 1.

/Per W

On Thu, 6 Mar 2003, "J=F6rgen" wrote:

> Hi,
>
> The type is signed, but as you can see there are no negative values [0...=
11, 0...65536, 0...4], so that shouldn't be the problem because the most si=
gnificant bit is zero. I've tried every possible combination I can think of=
 but I can't not figure out where the extra bytes comes from.
>
> /J=F6rgen
>
> *********** REPLY SEPARATOR  ***********
>
> On 2003-03-06 at 16:51 Per Westermark wrote:
>
> >You don't show what type value has, but if it's signed, your in for a bi=
t
> >of surprise if you try and shift and mask on it.
> >
> >Most compilers - not all as Ioannis and I have had an earlier discussion
> >about yesterday :-) - will shift in most significant bit set if you shif=
t
> >a negative value to the right.
> >
> >Note that 0xbd is the same is 189 unsigned or -67 signed.
> >
> >/Per W
> >
> >On Thu, 6 Mar 2003, "J=F6rgen" wrote:
> >
> >> Hi.
> >>
> >> This problem puzzles me. I have the following data.
> >> -4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 =
4
> >6 0 4 7 0 4 8 0 4 9 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1
> >>
> >> I'm not to familiar with reg.exp, but I guess that the reg.exp. for th=
e
> >data would be
> >> result [value1 value2 value3]*
> >>
> >> where
> >>   result is an integer but is always in the range -64 to 64
> >>   value1 is an integer but is always in the range 0 to 11
> >>   value2 is an integer but is always in the range 0 to 65536
> >>   value3 is an integer but is always in the range 0 to 4
> >>
> >> let's say that we call [value1 value2 value3] for 'value' and
> >'nbrOfValues' the number of sets of 'value'. In this case nbrOfvalues =
=3D 20
> >>
> >> When I write the data to file, using ofstream foo("foofile") I do it i=
n
> >the following way
> >>
> >> if(result < 0)
> >>   foo << '-';
> >> else
> >>   foo << '+';
> >> foo << ((unsigned char) (abs(result) & 0x000000FF));
> >>
> >> for(int i=3D0; i<numberOfValues; i++){
> >>   foo << ((unsigned char) (value[i][0] & 0x000000FF));
> >>   foo << ((unsigned char) ((value[i][1] & 0x0000FF00) >> 8));
> >>   foo << ((unsigned char) (value[i][1] & 0x000000FF));
> >>   foo << ((unsigned char) (value[i][2] & 0x000000FF));
> >> }
> >>
> >> The problem comes when I read the data from file. If I just reverse th=
e
> >procedure and prints the decoded data to screen I get
> >> -4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 =
4
> >6 0 4 7 0 4 8 0 4 9 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1=
 0
> >80 114
> >>
> >> It looks just the same as the original data except for the last three
> >numbers (0 80 114).
> >>
> >> When looking at the filesize it shows that it is 85 bytes, but the dat=
a
> >written is only 82 bytes
> >>
> >> For debugging purposes, instead of writing directly to file, I first
> >store everything in a string s. That is, replacing foo << ... with s +=
=3D
> >... Finally I write it to file with foo << s;
> >>
> >> When I print the string s to screen in hex-mode
> >>
> >> cout.setf( ios_base::hex, ios_base::basefield );
> >> for(int i=3D0; i<s.size(); i++)
> >>   cout << " " << s[i];
> >>
> >> it gives the following output
> >> 2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5=
f
> >1 4 0 0 8 5 0 0 4 6 0 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 a 0 1b 2 a 0 =
24
> >1 a 0 36 1 b 0 6c 1 b 0 bd 1
> >> and it is the way it should be
> >>
> >> But when I look at the datafile in a hexeditor I see
> >> 2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5=
f
> >1 4 0 0 8 5 0 0 4 6 0 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 d a 0 1b 2 d =
a
> >0 24 1 d a 0 36 1 b 0 6c 1 b 0 bd 1
> >>
> >> An extra byte 'd' emerges before every one of the three "value1"-'a'
> >bytes (d a 0 1b 2 , d a 0 24 1 , d a 0 36 1).
> >>
> >> Where did these 'd' bytes come from?
> >> Why are the only occuring in front of the 'a' byte?
> >> How come that when I print the data to screen it does not mess up the
> >values but instead appends (0 80 114) at the end?
> >> Finally, and most important, how do I get rid of them?
> >>
> >>
> >> Any ideas are very welcome.
> >>
> >> TIA
> >> /J=F6rgen
> >>
> >>
>
>
>
>

Re: [Dev-C++] Some extra bytes written to file?

[<qa...@ho...>]

Hi again.

Found the solution to my problem. If I write the file as a binaryfile it=
 works perfect.
I don't understand why I have to do that though.

/J=F6rgen

*********** REPLY SEPARATOR  ***********

On 2003-03-06 at 16:51 Per Westermark wrote:

>You don't show what type value has, but if it's signed, your in for a bit
>of surprise if you try and shift and mask on it.
>
>Most compilers - not all as Ioannis and I have had an earlier discussion
>about yesterday :-) - will shift in most significant bit set if you shift
>a negative value to the right.
>
>Note that 0xbd is the same is 189 unsigned or -67 signed.
>
>/Per W
>
>On Thu, 6 Mar 2003, "J=F6rgen" wrote:
>
>> Hi.
>>
>> This problem puzzles me. I have the following data.
>> -4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4
>6 0 4 7 0 4 8 0 4 9 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1
>>
>> I'm not to familiar with reg.exp, but I guess that the reg.exp. for the
>data would be
>> result [value1 value2 value3]*
>>
>> where
>>   result is an integer but is always in the range -64 to 64
>>   value1 is an integer but is always in the range 0 to 11
>>   value2 is an integer but is always in the range 0 to 65536
>>   value3 is an integer but is always in the range 0 to 4
>>
>> let's say that we call [value1 value2 value3] for 'value' and
>'nbrOfValues' the number of sets of 'value'. In this case nbrOfvalues =3D=
 20
>>
>> When I write the data to file, using ofstream foo("foofile") I do it in
>the following way
>>
>> if(result < 0)
>>   foo << '-';
>> else
>>   foo << '+';
>> foo << ((unsigned char) (abs(result) & 0x000000FF));
>>
>> for(int i=3D0; i<numberOfValues; i++){
>>   foo << ((unsigned char) (value[i][0] & 0x000000FF));
>>   foo << ((unsigned char) ((value[i][1] & 0x0000FF00) >> 8));
>>   foo << ((unsigned char) (value[i][1] & 0x000000FF));
>>   foo << ((unsigned char) (value[i][2] & 0x000000FF));
>> }
>>
>> The problem comes when I read the data from file. If I just reverse the
>procedure and prints the decoded data to screen I get
>> -4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4
>6 0 4 7 0 4 8 0 4 9 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 0
>80 114
>>
>> It looks just the same as the original data except for the last three
>numbers (0 80 114).
>>
>> When looking at the filesize it shows that it is 85 bytes, but the data
>written is only 82 bytes
>>
>> For debugging purposes, instead of writing directly to file, I first
>store everything in a string s. That is, replacing foo << ... with s +=3D
>... Finally I write it to file with foo << s;
>>
>> When I print the string s to screen in hex-mode
>>
>> cout.setf( ios_base::hex, ios_base::basefield );
>> for(int i=3D0; i<s.size(); i++)
>>   cout << " " << s[i];
>>
>> it gives the following output
>> 2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f
>1 4 0 0 8 5 0 0 4 6 0 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 a 0 1b 2 a 0 24
>1 a 0 36 1 b 0 6c 1 b 0 bd 1
>> and it is the way it should be
>>
>> But when I look at the datafile in a hexeditor I see
>> 2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f
>1 4 0 0 8 5 0 0 4 6 0 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 d a 0 1b 2 d a
>0 24 1 d a 0 36 1 b 0 6c 1 b 0 bd 1
>>
>> An extra byte 'd' emerges before every one of the three "value1"-'a'
>bytes (d a 0 1b 2 , d a 0 24 1 , d a 0 36 1).
>>
>> Where did these 'd' bytes come from?
>> Why are the only occuring in front of the 'a' byte?
>> How come that when I print the data to screen it does not mess up the
>values but instead appends (0 80 114) at the end?
>> Finally, and most important, how do I get rid of them?
>>
>>
>> Any ideas are very welcome.
>>
>> TIA
>> /J=F6rgen
>>
>>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Etnus, makers of TotalView, The
>debugger 
>for complex code. Debugging C/C++ programs can leave you feeling lost and 
>disoriented. TotalView can help you find your way. Available on major UNIX=
 
>and Linux platforms. Try it free. www.etnus.com
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

Re: [Dev-C++] Some extra bytes written to file?

[<qa...@ho...>]

Hi,

The type is signed, but as you can see there are no negative values=
 [0...11, 0...65536, 0...4], so that shouldn't be the problem because the=
 most significant bit is zero. I've tried every possible combination I can=
 think of but I can't not figure out where the extra bytes comes from.

/J=F6rgen

*********** REPLY SEPARATOR  ***********

On 2003-03-06 at 16:51 Per Westermark wrote:

>You don't show what type value has, but if it's signed, your in for a bit
>of surprise if you try and shift and mask on it.
>
>Most compilers - not all as Ioannis and I have had an earlier discussion
>about yesterday :-) - will shift in most significant bit set if you shift
>a negative value to the right.
>
>Note that 0xbd is the same is 189 unsigned or -67 signed.
>
>/Per W
>
>On Thu, 6 Mar 2003, "J=F6rgen" wrote:
>
>> Hi.
>>
>> This problem puzzles me. I have the following data.
>> -4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4
>6 0 4 7 0 4 8 0 4 9 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1
>>
>> I'm not to familiar with reg.exp, but I guess that the reg.exp. for the
>data would be
>> result [value1 value2 value3]*
>>
>> where
>>   result is an integer but is always in the range -64 to 64
>>   value1 is an integer but is always in the range 0 to 11
>>   value2 is an integer but is always in the range 0 to 65536
>>   value3 is an integer but is always in the range 0 to 4
>>
>> let's say that we call [value1 value2 value3] for 'value' and
>'nbrOfValues' the number of sets of 'value'. In this case nbrOfvalues =3D=
 20
>>
>> When I write the data to file, using ofstream foo("foofile") I do it in
>the following way
>>
>> if(result < 0)
>>   foo << '-';
>> else
>>   foo << '+';
>> foo << ((unsigned char) (abs(result) & 0x000000FF));
>>
>> for(int i=3D0; i<numberOfValues; i++){
>>   foo << ((unsigned char) (value[i][0] & 0x000000FF));
>>   foo << ((unsigned char) ((value[i][1] & 0x0000FF00) >> 8));
>>   foo << ((unsigned char) (value[i][1] & 0x000000FF));
>>   foo << ((unsigned char) (value[i][2] & 0x000000FF));
>> }
>>
>> The problem comes when I read the data from file. If I just reverse the
>procedure and prints the decoded data to screen I get
>> -4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4
>6 0 4 7 0 4 8 0 4 9 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 0
>80 114
>>
>> It looks just the same as the original data except for the last three
>numbers (0 80 114).
>>
>> When looking at the filesize it shows that it is 85 bytes, but the data
>written is only 82 bytes
>>
>> For debugging purposes, instead of writing directly to file, I first
>store everything in a string s. That is, replacing foo << ... with s +=3D
>... Finally I write it to file with foo << s;
>>
>> When I print the string s to screen in hex-mode
>>
>> cout.setf( ios_base::hex, ios_base::basefield );
>> for(int i=3D0; i<s.size(); i++)
>>   cout << " " << s[i];
>>
>> it gives the following output
>> 2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f
>1 4 0 0 8 5 0 0 4 6 0 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 a 0 1b 2 a 0 24
>1 a 0 36 1 b 0 6c 1 b 0 bd 1
>> and it is the way it should be
>>
>> But when I look at the datafile in a hexeditor I see
>> 2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f
>1 4 0 0 8 5 0 0 4 6 0 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 d a 0 1b 2 d a
>0 24 1 d a 0 36 1 b 0 6c 1 b 0 bd 1
>>
>> An extra byte 'd' emerges before every one of the three "value1"-'a'
>bytes (d a 0 1b 2 , d a 0 24 1 , d a 0 36 1).
>>
>> Where did these 'd' bytes come from?
>> Why are the only occuring in front of the 'a' byte?
>> How come that when I print the data to screen it does not mess up the
>values but instead appends (0 80 114) at the end?
>> Finally, and most important, how do I get rid of them?
>>
>>
>> Any ideas are very welcome.
>>
>> TIA
>> /J=F6rgen
>>
>>

Re: [Dev-C++] Some extra bytes written to file?

[Per W. <pw...@ia...>]

You don't show what type value has, but if it's signed, your in for a bit
of surprise if you try and shift and mask on it.

Most compilers - not all as Ioannis and I have had an earlier discussion
about yesterday :-) - will shift in most significant bit set if you shift
a negative value to the right.

Note that 0xbd is the same is 189 unsigned or -67 signed.

/Per W

On Thu, 6 Mar 2003, "J=F6rgen" wrote:

> Hi.
>
> This problem puzzles me. I have the following data.
> -4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6=
 0 4 7 0 4 8 0 4 9 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1
>
> I'm not to familiar with reg.exp, but I guess that the reg.exp. for the d=
ata would be
> result [value1 value2 value3]*
>
> where
>   result is an integer but is always in the range -64 to 64
>   value1 is an integer but is always in the range 0 to 11
>   value2 is an integer but is always in the range 0 to 65536
>   value3 is an integer but is always in the range 0 to 4
>
> let's say that we call [value1 value2 value3] for 'value' and 'nbrOfValue=
s' the number of sets of 'value'. In this case nbrOfvalues =3D 20
>
> When I write the data to file, using ofstream foo("foofile") I do it in t=
he following way
>
> if(result < 0)
>   foo << '-';
> else
>   foo << '+';
> foo << ((unsigned char) (abs(result) & 0x000000FF));
>
> for(int i=3D0; i<numberOfValues; i++){
>   foo << ((unsigned char) (value[i][0] & 0x000000FF));
>   foo << ((unsigned char) ((value[i][1] & 0x0000FF00) >> 8));
>   foo << ((unsigned char) (value[i][1] & 0x000000FF));
>   foo << ((unsigned char) (value[i][2] & 0x000000FF));
> }
>
> The problem comes when I read the data from file. If I just reverse the p=
rocedure and prints the decoded data to screen I get
> -4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6=
 0 4 7 0 4 8 0 4 9 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 0 8=
0 114
>
> It looks just the same as the original data except for the last three num=
bers (0 80 114).
>
> When looking at the filesize it shows that it is 85 bytes, but the data w=
ritten is only 82 bytes
>
> For debugging purposes, instead of writing directly to file, I first stor=
e everything in a string s. That is, replacing foo << ... with s +=3D ... F=
inally I write it to file with foo << s;
>
> When I print the string s to screen in hex-mode
>
> cout.setf( ios_base::hex, ios_base::basefield );
> for(int i=3D0; i<s.size(); i++)
>   cout << " " << s[i];
>
> it gives the following output
> 2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1=
 4 0 0 8 5 0 0 4 6 0 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 a 0 1b 2 a 0 24 1=
 a 0 36 1 b 0 6c 1 b 0 bd 1
> and it is the way it should be
>
> But when I look at the datafile in a hexeditor I see
> 2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1=
 4 0 0 8 5 0 0 4 6 0 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 d a 0 1b 2 d a 0 =
24 1 d a 0 36 1 b 0 6c 1 b 0 bd 1
>
> An extra byte 'd' emerges before every one of the three "value1"-'a' byte=
s (d a 0 1b 2 , d a 0 24 1 , d a 0 36 1).
>
> Where did these 'd' bytes come from?
> Why are the only occuring in front of the 'a' byte?
> How come that when I print the data to screen it does not mess up the val=
ues but instead appends (0 80 114) at the end?
> Finally, and most important, how do I get rid of them?
>
>
> Any ideas are very welcome.
>
> TIA
> /J=F6rgen
>
>

RES: [Dev-C++] New project with GTK and Dev-Cpp 4970

[Daniel K. O. <dan...@ya...>]

 >  > I am starting a new C++ project and I want to know
 >  > if
 >  > I will be able to use GTK and Dev-Cpp 4.9.7.0


Yes, you will.



 >  > Are the packages working well? If not, how long do I
 >  > have to wait? I do not need it right now, since I am
 >  > in the research phase. What about GCC 3.2? How is
 >  > it?


Forget about the GTK package, Tor is constantly updating the files on
http://www.gimp.org/~tml/gimp/win32/, so the GTK+ package soon become
outdated. If the updates are just on Pango, or ATK, or even on GLib, you'll
have to download the entire package again, or wait until more changes be
made, to download an entire new package.

Better learn how to install GTK+ by hand - unzip the dev files under
Dev-Cpp's dir, and search the archived messages on this list to see how to
set the compiler/linker flags.

 >  https://lists.sourceforge.net/lists/listinfo/dev-cpp-users






Daniel K. O.

It's OK to be ignorant; it's not OK to play stupid.
http://www.catb.org/~esr/faqs/smart-questions.html








_______________________________________________________________________
Busca Yahoo!
O serviço de busca mais completo da Internet. O que você pensar o Yahoo! encontra.
http://br.busca.yahoo.com/

[Dev-C++] Some extra bytes written to file?

[<qa...@ho...>]

Hi.

This problem puzzles me. I have the following data.
-4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6 0=
 4 7 0 4 8 0 4 9 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1

I'm not to familiar with reg.exp, but I guess that the reg.exp. for the=
 data would be 
result [value1 value2 value3]*

where 
  result is an integer but is always in the range -64 to 64
  value1 is an integer but is always in the range 0 to 11
  value2 is an integer but is always in the range 0 to 65536
  value3 is an integer but is always in the range 0 to 4

let's say that we call [value1 value2 value3] for 'value' and 'nbrOfValues'=
 the number of sets of 'value'. In this case nbrOfvalues =3D 20

When I write the data to file, using ofstream foo("foofile") I do it in the=
 following way

if(result < 0)
  foo << '-';
else
  foo << '+';
foo << ((unsigned char) (abs(result) & 0x000000FF));

for(int i=3D0; i<numberOfValues; i++){
  foo << ((unsigned char) (value[i][0] & 0x000000FF));
  foo << ((unsigned char) ((value[i][1] & 0x0000FF00) >> 8));
  foo << ((unsigned char) (value[i][1] & 0x000000FF));
  foo << ((unsigned char) (value[i][2] & 0x000000FF));
}

The problem comes when I read the data from file. If I just reverse the=
 procedure and prints the decoded data to screen I get
-4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6 0=
 4 7 0 4 8 0 4 9 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 0 80=
 114

It looks just the same as the original data except for the last three=
 numbers (0 80 114).

When looking at the filesize it shows that it is 85 bytes, but the data=
 written is only 82 bytes

For debugging purposes, instead of writing directly to file, I first store=
 everything in a string s. That is, replacing foo << ... with s +=3D ...=
 Finally I write it to file with foo << s;

When I print the string s to screen in hex-mode

cout.setf( ios_base::hex, ios_base::basefield );
for(int i=3D0; i<s.size(); i++)
  cout << " " << s[i];

it gives the following output
2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1 4=
 0 0 8 5 0 0 4 6 0 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 a 0 1b 2 a 0 24 1 a=
 0 36 1 b 0 6c 1 b 0 bd 1
and it is the way it should be 

But when I look at the datafile in a hexeditor I see
2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1 4=
 0 0 8 5 0 0 4 6 0 0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 d a 0 1b 2 d a 0 24=
 1 d a 0 36 1 b 0 6c 1 b 0 bd 1

An extra byte 'd' emerges before every one of the three "value1"-'a' bytes=
 (d a 0 1b 2 , d a 0 24 1 , d a 0 36 1).

Where did these 'd' bytes come from?
Why are the only occuring in front of the 'a' byte?
How come that when I print the data to screen it does not mess up the=
 values but instead appends (0 80 114) at the end?
Finally, and most important, how do I get rid of them?


Any ideas are very welcome.

TIA
/J=F6rgen

[Dev-C++] New project with GTK and Dev-Cpp 4970

[<fla...@ya...>]

Please, somebody. Answer this e-mail.

Tks

Flávio.
 --- Flávio de Souza <fla...@ya...>
escreveu: > Data: Mon, 3 Mar 2003 13:56:41 -0300 (ART)
> De: Flávio de Souza <fla...@ya...>
> Assunto: New project with GTK and Dev-Cpp 4970
> Para: Dev-Cpp <dev...@li...>
> 
> Hi every body!
> 
> I am starting a new C++ project and I want to know
> if
> I will be able to use GTK and Dev-Cpp 4.9.7.0
> 
> Are the packages working well? If not, how long do I
> have to wait? I do not need it right now, since I am
> in the research phase. What about GCC 3.2? How is
> it?
> 
> I do not want to start my project using the previous
> versions because it will become a large project and
> in
> the future I dont want to rewrite my code due to
> version incompabilitty.
> 
> I´d appreciate to hear your comments.
> 
> Thanks,
> 
> Flavio.
> 
> =====
> Flavio de Souza
> fla...@ya...
> Sertãozinho - SP - Brasil
> Yahoo! ID: flaviostz
> 
>
_______________________________________________________________________
> Busca Yahoo!
> O serviço de busca mais completo da Internet. O que
> você pensar o Yahoo! encontra.
> http://br.busca.yahoo.com/
>  

=====
Flavio de Souza
fla...@ya...
Sertãozinho - SP - Brasil
Yahoo! ID: flaviostz

_______________________________________________________________________
Busca Yahoo!
O serviço de busca mais completo da Internet. O que você pensar o Yahoo! encontra.
http://br.busca.yahoo.com/

[Dev-C++] flex/bison

[Pierre R. <pie...@wa...>]

Hello,

How to manage dependency relations with flex/bison files in Dev-Cpp? A =
long time ago, I already asked this question, without any answer. =
Perhaps now, somebody will have any idea about this issue...

Thanks

Pierre Raoul

[Dev-C++] (no subject)

[Eric <eri...@cl...>]

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25-Feb-03