Major bug in my old gencols (1994) distribution

[pcallahan]

I see some references to it, so it looks like people still try to use gencols, but here is what I found after building it from the original distribution on a Mac. The bug potentially happens on any 64 bit machine.

First, it doesn't compile at all, because references to malloc.h need to be changed to stdlib.h.
Second, it still doesn't compile because the methods in output.c need to be declared void.
Third, it still doesn't compile because there needs to be a forward declaration of outputpattern as void.

At this point it compiles, but then you get to the bug. The tipoff is that when you run the Examples script, some of the output files are empty.

The problem seems to be in defs.h, which has the line:

Code: Select all

typedef unsigned long cellseg;

That was fine in 1994 but it may have been unnecessary. I just wanted a 32 bit unsigned. It should be:

Code: Select all

typedef unsigned int cellseg;

After this change, the most obvious problems go away. It is still old code that I wrote when I was a much less experienced coder. For some reason, I used K&R declarations, though ANSI C had been out for years.

If there is interest and nobody else has done it, I can briefly clean up the code so it at least compiles and runs without the bug. I could also change the declarations to ANSI C.

[calcyman]

The problem seems to be in defs.h, which has the line:

Code: Select all

typedef unsigned long cellseg;

That was fine in 1994 but it may have been unnecessary. I just wanted a 32 bit unsigned. It should be:

Code: Select all

typedef unsigned int cellseg;

This is why (and I seem to be in the minority for doing this) I always #include <stdint.h> to give myself access to the fixed-width types uint64_t, uint32_t, uint16_t, uint8_t, and their signed counterparts int64_t, int32_t, int16_t, and int8_t.

So you could instead write:

Code: Select all

#include <stdint.h>
typedef uint32_t cellseg;

and then it's future-proofed against some compiler that decides ints should be 64-bit (which is allowed by the standard).

[Scorbie]

This is why (and I seem to be in the minority for doing this) I always #include <stdint.h> to give myself access to the fixed-width types uint64_t, uint32_t, uint16_t, uint8_t, and their signed counterparts int64_t, int32_t, int16_t, and int8_t.

And simsim314 and me. You're not alone (Although I haven't made any real C Programs yet)
Perhaps we don't see them in legacy scripts as these constructs? are introduced in C99?

(Off-topic)

In my defense, I didn't start doing it professionally until several years later.

Interesting. I'm wondering if I could change do programming for a living... Did you have another job prior to programming?
Whoops, I guess "software engineering" would be a more precise term for real work...

[pcallahan]

Future-proofing my C code was almost the last thing on my mind in 1994. Given the K&R declarations, it looks like I was "past-proofing" it to work on old compilers, though I am sure I had access to ANSI C. What was I thinking?

I don't know if I should be happy or embarrassed that I am a much better software engineer at 54 than I was at 29. Neither is especially young. In my defense, I didn't start doing it professionally until several years later.