Mail Archives: djgpp/1999/08/26/02:00:42
In article <37C2FA62 DOT EB9237E6 AT netvision DOT net DOT il> you wrote:
> heya somebody
> i wrote this procedure, but when i put a call for it in main(),
> compile and run, the program doesn't even finish the self-setting-up
> phase.
First rule of debugging: don't worry about what does *not* happen
(setup phase finishing, in your case), but instead observe closely
what *does* happen, looking for unexpected behaviour. You won't learn
anything, generally, from things that don't happen. There's simply no
data to analyze. Only things that do happen can be observed,
cross-checked and thus validated as either correct or incorrect.
Here, you should run this in a debugger, and see what exactly it does,
how far it gets, and where it stops functionning as expected. That'll
give you a place in your source code to inspect for possible errors.
That being said, I think I know where your problem is:
[...]
> {
> int read;
> fread(&read,2,1,f);
This looks like you assume that an int is 2 bytes long. That's *wrong*
in DJGPP, and most other modern compilers for PCs.
> while (read!=0xffff)
> {
In combination with the above, this may easily end up being an endless
loop, as the 2 high bytes of 'read' are never given any specific
value. Thus, they will contain random garbage. If that garbages
happens to be anything else than 0x0000, read will never be ==0xffff,
and your loop won't terminate.
Welcome to the world of real compilers, where ints aren't 16bit,
pointers can point as 'far' (or 'near') as you want, without you
having to call them so, and a malloc(1e6) won't be a problem, at all
:-)
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -