Re: [Freedos-user] data type length problem
On 12/11/2011 11:55 PM, David Griffith wrote: On Sun, 11 Dec 2011, Ralf A. Quint wrote: At 09:36 PM 12/11/2011, Ralf A. Quint wrote: How can I get this code to do the Right Thing? Actually just realized that it's pretty easy, you just need to typecast properly all parts of the makeid macro: Ugh! how'd I miss something like that? This revelation may come in handy when dealing with some uint32 types. Just another general rule for good C code - mark your constants if they are large. For example: #define CONNECT_TMEOUT_MS (5ul) That does not work in your case, but it looks nicer than repeated casting. The compiler wants to 'think' 16 bits, because that is what it is good at. It can do 32 bits, but it has to be forced to do so. Whenever you are doing mixed 16 and 32 bit computations start casting upward like crazy. Mike -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] data type length problem
As I stated earlier, I'm trying to re-port Frotz to DOS. I've run into a
bit of a problem with the size of some unsigned longs in quetzal.c.
Below is a test case of some problem code. I first noticed something
wrong when the compiler complained that I had two identical case
statements in a switch. There is quite a bit of packing four chars into a
long and so I'm quite sure something bad would happen even if there wasn't
a collision in the switch. Would someone take a look at this test code
and give me some advice? An unsigned long is four bytes under both Linux
and 16-bit DOS. Why then do my unsigned longs get chopped off when
running under DOS? Changing to an unsigned long long doesn't do any good.
How can I get this code to do the Right Thing?
Linux with GCC results:
sizeof(unsigned long) == 4
sizeof(long long) == 8
ID_FORM == 1179603533
ID_IFZS == 1229347411
ID_IFhd == 1229351012
ID_UMem == 1431135597
ID_CMem == 1129145709
ID_Stks == 1400138611
ID_ANNO == 1095650895
MSDOS 16-bit with Turbo C results:
sizeof(unsigned long) == 4
sizeof(long long) == 4
ID_FORM == 21069
ID_IFZS == 23123
ID_IFhd == 26724
ID_UMem == 25965 -- identical
ID_CMem == 27965 -- identical
ID_Stks == 27507
ID_ANNO == 20047
#include stdio.h
#include string.h
typedef unsigned long zlong;
#define makeid(a,b,c,d) ((zlong) (((a)24) | ((b)16) | ((c)8) | (d)))
#define ID_FORM makeid ('F','O','R','M')
#define ID_IFZS makeid ('I','F','Z','S')
#define ID_IFhd makeid ('I','F','h','d')
#define ID_UMem makeid ('U','M','e','m')
#define ID_CMem makeid ('C','M','e','m')
#define ID_Stks makeid ('S','t','k','s')
#define ID_ANNO makeid ('A','N','N','O')
int main(int argc, char *argv[])
{
printf(sizeof(unsigned long) == %i\n, sizeof(unsigned long));
printf(sizeof(long long) == %i\n, sizeof(long long));
printf(ID_FORM == %lu\n, ID_FORM);
printf(ID_IFZS == %lu\n, ID_IFZS);
printf(ID_IFhd == %lu\n, ID_IFhd);
printf(ID_UMem == %lu\n, ID_UMem);
printf(ID_CMem == %lu\n, ID_CMem);
printf(ID_Stks == %lu\n, ID_Stks);
printf(ID_ANNO == %lu\n, ID_ANNO);
return 0;
}
--
David Griffith
dgri...@cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] data type length problem
At 08:41 PM 12/11/2011, David Griffith wrote: Would someone take a look at this test code and give me some advice? An unsigned long is four bytes under both Linux and 16-bit DOS. Why then do my unsigned longs get chopped off when running under DOS? It seems that at least the Borland compiler uses only the (last) 16 bit of the defines, and UMem and CMem have both em as the last two bytes, while all others are different in those two. Hence the same 16 bit integer output. Changing to an unsigned long long doesn't do any good. That's not surprising, as the long long data type exists only since C99, which came out years after the latest true DOS compiler How can I get this code to do the Right Thing? I have been out all day and just came back home, don't feel like spending hours on the computer tonight anymore. If work is slow, I will have some time to look into this. Btw, I could quickly reproduce your problem with the latest version of Borland C++ 3.11, not sure which version you're using... Ralf -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] data type length problem
On Sun, 11 Dec 2011, Ralf A. Quint wrote: At 08:41 PM 12/11/2011, David Griffith wrote: Would someone take a look at this test code and give me some advice? An unsigned long is four bytes under both Linux and 16-bit DOS. Why then do my unsigned longs get chopped off when running under DOS? It seems that at least the Borland compiler uses only the (last) 16 bit of the defines, and UMem and CMem have both em as the last two bytes, while all others are different in those two. Hence the same 16 bit integer output. I figured that was the reason for the collision. How can I get this code to do the Right Thing? I have been out all day and just came back home, don't feel like spending hours on the computer tonight anymore. If work is slow, I will have some time to look into this. Btw, I could quickly reproduce your problem with the latest version of Borland C++ 3.11, not sure which version you're using... I'm using Turbo C++ 3.0. -- David Griffith dgri...@cs.csubak.edu A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] data type length problem
At 09:36 PM 12/11/2011, Ralf A. Quint wrote:
How can I get this code to do the Right Thing?
Actually just realized that it's pretty easy, you just need to
typecast properly all parts of the makeid macro:
#include stdio.h
#include string.h
typedef unsigned long zlong;
// all parts of the macro need to be typecast to unsigned long, or
operation on those parts will only be performed in 16 bits, // //
despite the overall result type of the macro being defined as an unsigned long
#define makeid(a,b,c,d) ((zlong) (((zlong)(a)24) + ((zlong)(b)16)
+ ((zlong)(c)8) + (zlong)(d)))
#define ID_FORM makeid ('F','O','R','M')
#define ID_IFZS makeid ('I','F','Z','S')
#define ID_IFhd makeid ('I','F','h','d')
#define ID_UMem makeid ('U','M','e','m')
#define ID_CMem makeid ('C','M','e','m')
#define ID_Stks makeid ('S','t','k','s')
#define ID_ANNO makeid ('A','N','N','O')
int main(void)
{
printf(sizeof(unsigned long) == %i\n, sizeof(unsigned long));
printf(sizeof(long long) == %i\n, sizeof(long long));
printf(ID_FORM == %lu\n, ID_FORM);
printf(ID_IFZS == %lu\n, ID_IFZS);
printf(ID_IFhd == %lu\n, ID_IFhd);
printf(ID_UMem == %lu\n, ID_UMem);
printf(ID_CMem == %lu\n, ID_CMem);
printf(ID_Stks == %lu\n, ID_Stks);
printf(ID_ANNO == %lu\n, ID_ANNO);
return 0;
}
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] data type length problem
On Sun, 11 Dec 2011, Ralf A. Quint wrote: At 09:36 PM 12/11/2011, Ralf A. Quint wrote: How can I get this code to do the Right Thing? Actually just realized that it's pretty easy, you just need to typecast properly all parts of the makeid macro: Ugh! how'd I miss something like that? This revelation may come in handy when dealing with some uint32 types. -- David Griffith dgri...@cs.csubak.edu A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] data type length problem
At 09:55 PM 12/11/2011, David Griffith wrote: On Sun, 11 Dec 2011, Ralf A. Quint wrote: At 09:36 PM 12/11/2011, Ralf A. Quint wrote: How can I get this code to do the Right Thing? Actually just realized that it's pretty easy, you just need to typecast properly all parts of the makeid macro: Ugh! how'd I miss something like that? This revelation may come in handy when dealing with some uint32 types. Well, you're probably used to program in an environment that has a different (32 bit) default int size! ;-) In 16bit DOS the default int is 16bit, that also means that all macro or other from the compiler performed computation is done with 16 bit values, unless explictly specified otherwise. For me the penny dropped as soon as I had send my first reply, noticing that in DOS, it printed all 16 bit values even though the format string defined clearly a %ul. Took a quick look at the assembler output from BC++3.11 and notices that it actually pushes a 0 upper 16 bit register and then the computed 16bit value. That's when I realized that shifts of a and b are just for the bit bucket unless properly typecasted... Ralf -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
