"Out of Memory" error during Borland C++ 5.02 compile

[schears]

Why?
Running on windows 2000 with all updates, 2G Memory, 117G Hard Drive
space available.

This was not an issue until I added some code to two of my c files.
Any suggestions?
Thanks

 

[Christopher Benson-Manica]

<[email protected]>

This was not an issue until I added some code to two of my c files.

If you get this error during compilation, it's a Borland problem, not
a C problem. Take it to the groups at newsgroups.borland.com and you'll
get a solution rather than flames.

 

[Grumble]

Why?
Running on windows 2000 with all updates, 2G Memory, 117G Hard Drive
space available.

This was not an issue until I added some code to two of my c files.
Any suggestions?

Did you try to ask in a newsgroup devoted to Borland C++ ?

 

[Kenny McCormack]

Did you try to ask in a newsgroup devoted to Borland C++ ?

Well, the obvious answer is: delete that code that caused the problem.

The somewhat less obvious answer is: post the code that caused the problem
here, so we can tell you what's wrong with it.

 

[Keith Thompson]

Well, the obvious answer is: delete that code that caused the problem.

The somewhat less obvious answer is: post the code that caused the problem
here, so we can tell you what's wrong with it.

That's unlikely to be useful. There is no C construct that would be
expected to cause a compiler to run out of memory (unless it's just an
incredibly huge program, but I don't think that's the case here given
the resources available on the system). This is a Borland-specific
problem; we lack the expertise to help you with it here.

 

[Kenny McCormack]

That's unlikely to be useful. There is no C construct that would be
expected to cause a compiler to run out of memory (unless it's just an
incredibly huge program, but I don't think that's the case here given
the resources available on the system). This is a Borland-specific
problem; we lack the expertise to help you with it here.

Help *me* with it? Surely, you mean "help the OP".

Anyway, get serious. One of the basic tenets of this NG is that if you
"invoke UB", anything can happen - and "anything" surely includes a compiler
blowing memory. Remember, the OP did say that it was working until he
added "a couple of lines of code". What if those "couple of lines of code"
were declaring a very (very!) large automatic variable (array)?

Yes, I am aware there is a grey area here (between compile-time behavior
and run-time behavior), but these days, those lines are blurred. My bet is
there's something wrong with those lines of code (or his story isn't
accurate).

 

[Keith Thompson]

(e-mail address removed) (Kenny McCormack) writes: [...]

The somewhat less obvious answer is: post the code that caused the problem
here, so we can tell you what's wrong with it.

That's unlikely to be useful. There is no C construct that would be
expected to cause a compiler to run out of memory (unless it's just an
incredibly huge program, but I don't think that's the case here given
the resources available on the system). This is a Borland-specific
problem; we lack the expertise to help you with it here.

Help *me* with it? Surely, you mean "help the OP".

Of course.

Anyway, get serious. One of the basic tenets of this NG is that if you
"invoke UB", anything can happen - and "anything" surely includes a compiler
blowing memory. Remember, the OP did say that it was working until he
added "a couple of lines of code". What if those "couple of lines of code"
were declaring a very (very!) large automatic variable (array)?

Declaring a large array uses memory at run time, not at compilation time.

If the "couple of lines of code" invoke undefined behavior, all we'd
be able to tell the OP is that they invoke undefined behavior.
There's no way we could guess that they could cause the compiler to
run out of memory.

Yes, I am aware there is a grey area here (between compile-time behavior
and run-time behavior), but these days, those lines are blurred. My bet is
there's something wrong with those lines of code (or his story isn't
accurate).

My bet is that there's something wrong with the compiler.

 

[Peter Nilsson]

... There is no C construct that would be expected to cause a
compiler to run out of memory (unless it's just an incredibly
huge program, ...

It doesn't have to be 'incredibly huge'. The following 21 lines
crashes my port of gcc...

#define BC1(p) p,1+p
#define BC2(p) BC1(p),BC1(1+p)
#define BC3(p) BC2(p),BC2(1+p)
#define BC4(p) BC3(p),BC3(1+p)
#define BC5(p) BC4(p),BC4(1+p)
#define BC6(p) BC5(p),BC5(1+p)
#define BC7(p) BC6(p),BC6(1+p)
#define BC8(p) BC7(p),BC7(1+p)
#define BC9(p) BC8(p),BC8(1+p)
#define BC10(p) BC9(p),BC9(1+p)
#define BC11(p) BC10(p),BC10(1+p)
#define BC12(p) BC11(p),BC11(1+p)
#define BC13(p) BC12(p),BC12(1+p)
#define BC14(p) BC13(p),BC13(1+p)
#define BC15(p) BC14(p),BC14(1+p)
#define BC16(p) BC15(p),BC15(1+p)
#define BC17(p) BC16(p),BC16(1+p)
#define BC18(p) BC17(p),BC17(1+p)
#define BC19(p) BC18(p),BC18(1+p)
#define BC20(p) BC19(p),BC19(1+p)
unsigned char bc[] = { BC20(0) };

 

[jacob navia]

... There is no C construct that would be expected to cause a
compiler to run out of memory (unless it's just an incredibly
huge program, ...

It doesn't have to be 'incredibly huge'. The following 21 lines
crashes my port of gcc...

#define BC1(p) p,1+p
#define BC2(p) BC1(p),BC1(1+p)
#define BC3(p) BC2(p),BC2(1+p)
#define BC4(p) BC3(p),BC3(1+p)
#define BC5(p) BC4(p),BC4(1+p)
#define BC6(p) BC5(p),BC5(1+p)
#define BC7(p) BC6(p),BC6(1+p)
#define BC8(p) BC7(p),BC7(1+p)
#define BC9(p) BC8(p),BC8(1+p)
#define BC10(p) BC9(p),BC9(1+p)
#define BC11(p) BC10(p),BC10(1+p)
#define BC12(p) BC11(p),BC11(1+p)
#define BC13(p) BC12(p),BC12(1+p)
#define BC14(p) BC13(p),BC13(1+p)
#define BC15(p) BC14(p),BC14(1+p)
#define BC16(p) BC15(p),BC15(1+p)
#define BC17(p) BC16(p),BC16(1+p)
#define BC18(p) BC17(p),BC17(1+p)
#define BC19(p) BC18(p),BC18(1+p)
#define BC20(p) BC19(p),BC19(1+p)
unsigned char bc[] = { BC20(0) };

"It doesn't to be incredible huge???????"

The expansion of that makes lcc-win32 use more than 1GB
RAM.

BC1 multiplies the original expression character count by two,
then it adds 3 chars.

The other expressions multiply the character count by two
and then add 5 chars!!!

Assuming the original character count is N we have
BC1 = (2*N+3) ---------->5

BC2 = 2*(2*N+3) + 5 ----->15

BC3 = 2*(2*(2*N+3) + 5 ) + 5 )-->60

etc, this grows geometrically.

Please turn on your brain before complaining...

jacob

 

[Kenny McCormack]

... There is no C construct that would be expected to cause a
compiler to run out of memory (unless it's just an incredibly
huge program, ...

It doesn't have to be 'incredibly huge'. The following 21 lines
crashes my port of gcc...

#define BC1(p) p,1+p
#define BC2(p) BC1(p),BC1(1+p)
#define BC3(p) BC2(p),BC2(1+p)
#define BC4(p) BC3(p),BC3(1+p)
#define BC5(p) BC4(p),BC4(1+p)
#define BC6(p) BC5(p),BC5(1+p)
#define BC7(p) BC6(p),BC6(1+p)
#define BC8(p) BC7(p),BC7(1+p)
#define BC9(p) BC8(p),BC8(1+p)
#define BC10(p) BC9(p),BC9(1+p)
#define BC11(p) BC10(p),BC10(1+p)
#define BC12(p) BC11(p),BC11(1+p)
#define BC13(p) BC12(p),BC12(1+p)
#define BC14(p) BC13(p),BC13(1+p)
#define BC15(p) BC14(p),BC14(1+p)
#define BC16(p) BC15(p),BC15(1+p)
#define BC17(p) BC16(p),BC16(1+p)
#define BC18(p) BC17(p),BC17(1+p)
#define BC19(p) BC18(p),BC18(1+p)
#define BC20(p) BC19(p),BC19(1+p)
unsigned char bc[] = { BC20(0) };

Right! That's what I was thinking of - a good example of compile-time UB.

 

[Keith Thompson]

... There is no C construct that would be expected to cause a
compiler to run out of memory (unless it's just an incredibly
huge program, ...

It doesn't have to be 'incredibly huge'. The following 21 lines
crashes my port of gcc...
#define BC1(p) p,1+p
#define BC2(p) BC1(p),BC1(1+p)
#define BC3(p) BC2(p),BC2(1+p)
#define BC4(p) BC3(p),BC3(1+p)
#define BC5(p) BC4(p),BC4(1+p)
#define BC6(p) BC5(p),BC5(1+p)
#define BC7(p) BC6(p),BC6(1+p)
#define BC8(p) BC7(p),BC7(1+p)
#define BC9(p) BC8(p),BC8(1+p)
#define BC10(p) BC9(p),BC9(1+p)
#define BC11(p) BC10(p),BC10(1+p)
#define BC12(p) BC11(p),BC11(1+p)
#define BC13(p) BC12(p),BC12(1+p)
#define BC14(p) BC13(p),BC13(1+p)
#define BC15(p) BC14(p),BC14(1+p)
#define BC16(p) BC15(p),BC15(1+p)
#define BC17(p) BC16(p),BC16(1+p)
#define BC18(p) BC17(p),BC17(1+p)
#define BC19(p) BC18(p),BC18(1+p)
#define BC20(p) BC19(p),BC19(1+p)
unsigned char bc[] = { BC20(0) };

"It doesn't to be incredible huge???????"

The expansion of that makes lcc-win32 use more than 1GB
RAM.

[...]

No, it doesn't have to be incredibly huge. That 1GB of RAM was
consumed while compiling just 21 lines of C source. It doesn't become
"incredibly huge" until it reaches the compiler's internals
(presumably the preprocessor).

The C construct in question is the above 21 lines, not whatever the
preprocessor generates internally.

(And yes, that means there's a case I missed in my previous remarks,
but I doubt that this is related to the OP's problem.)

Please turn on your brain before complaining...

Who was complaining, and whose brain needs to be turned on?