"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]

<11************ **********@g14g 2000cwa.googleg roups.com>
sc*****@hotpop. com wrote:

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.borl and.com and you'll
get a solution rather than flames.

--
Christopher Benson-Manica
ataru(at)cybers pace.org

[Grumble]

sc*****@hotpop. com wrote:

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]

In article <d0**********@n ews-rocq.inria.fr>,
Grumble <de*****@kma.eu .org> wrote:

sc*****@hotpop .com wrote:

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++ ?

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]

ga*****@yin.int eraccess.com (Kenny McCormack) writes:

In article <d0**********@n ews-rocq.inria.fr>,
Grumble <de*****@kma.eu .org> wrote:

sc*****@hotpo p.com wrote:

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++ ?

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.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Kenny McCormack]

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.or g> wrote:

ga*****@yin.in teraccess.com (Kenny McCormack) writes:

In article <d0**********@n ews-rocq.inria.fr>,
Grumble <de*****@kma.eu .org> wrote:

sc*****@hotp op.com wrote:

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++ ?

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.

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]

ga*****@yin.int eraccess.com (Kenny McCormack) writes:

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.or g> wrote:

ga*****@yin.i nteraccess.com (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.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Peter Nilsson]

Keith Thompson wrote:

... 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) };

--
Peter

[jacob navia]

Peter Nilsson wrote:

Keith Thompson wrote:

... 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]

In article <11************ *********@l41g2 000cwc.googlegr oups.com>,
Peter Nilsson <ai***@acay.com .au> wrote:

Keith Thompson wrote:

... 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) };

--
Peter

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