#4 byte int problem
5 messages in this thread
I don't know how the version numbers compare, but the DeskWriter (no C, or
550C) driver 3.1 I couldn't get the ANSI library to compile. Removing the
driver let it compile. I have version 3.9 of the driver now and was able to
recompile the library when I upgraded to Symantec C++ 6.0. I also used to have
project files die on me, and that went away as well. It sounds like you found
the problem, so I wouldn't worry about the driver.
I had a couple of bombs when I first used 32 bit ints with one of my projects.
It turned out that I had computed the size wrong and I guess I was overwriting
a malloc block. Actually the changed in size probably moved things so that I
was overwriting the malloc block only with 32 bit ints.
That problem is now behind me. It had nothing to do with the DeskWriter 550C
driver, or for that matter with Symantec at all. It was a bug in the MemCheck
libraries that I use — they redefine memset() and all other memory access
functions to allow me to track memory leaks, improper use of memory, etc.
Turns out it didn't handle the 4-byte ints properly and was still running in
2-byte mode, whick led me on a wild goose chase.
– Burt
Yea, I saw your message about the MemCheck library. One problem with 4 byte
ints is that everyone has to agree to do it. I am from the workstation world
ware all the compilers use 4 byte ints. On a related note, I have decided to
use the ANSI++ library and compile everything with the C++ compatible settings.
There is a button at the bottom of the compiler settings window that sets
various options. The only real difference is that it checks native floating
point, but it should ease the transition to C++.
Re: "Yea, I saw your message about the MemCheck library. One problem with 4
byte ints is that everyone has to agree to do it."
I see so many people remarking or complaining about problems with 2 byte versus
4 byte ints. (Back before Think offered a 4 byte int, many bitched about it
complaining that it was incompatible with MPW, etc.)
For my part, I religiously avoid using ints in my code. If I want a 2 byte int,
I use a short. If I want a 4 byte int, I use a long. Problem solved. Down with
ints!
Of course, if you're using a library that is already using ints, you're kind of
stuck. But I thought I'd toss in my 2 cents worth anyway. 🙂
I'm with you, Michael. Where I used to work, we even went as far as to define
types that indicated the size, and used THEM, not the underlying C-provided
types. (We were dealing with code that had to be as portable as possible to
VAX/VMS, MeSs-Windows, and the IBM Mainframe.)
Joe