about declaration of huge matrix in C

[Marc Boyer]

First, I have implemented a huge matrix in a program, like 'unsigned
char matrix[1500][1500];',
when I executed this program, the error occured.

Then I modified the declaration, like 'static unsigned char
matrix[1500][1500];', it runs well.

so, could anyone tell me why the error occured at first situation?

The static or auto/local variables are, in general, not
stored in the same kind of area, and, on your test platform,
one was sufficient and the other was not.

It depend on you platform, ie compiler (and options),
OS (and parameters) and so on.

Marc Boyer

 

[luke.yolanda]

hi everyone

I have a question.

First, I have implemented a huge matrix in a program, like 'unsigned
char matrix[1500][1500];',
when I executed this program, the error occured.

Then I modified the declaration, like 'static unsigned char
matrix[1500][1500];', it runs well.

so, could anyone tell me why the error occured at first situation?

thank you very very much~~

 

[Eric Sosman]

hi everyone

I have a question.

First, I have implemented a huge matrix in a program, like 'unsigned
char matrix[1500][1500];',
when I executed this program, the error occured.

Then I modified the declaration, like 'static unsigned char
matrix[1500][1500];', it runs well.

so, could anyone tell me why the error occured at first situation?

This is Question 16.3 in the comp.lang.c Frequently
Asked Questions (FAQ) list at

http://www.c-faq.com/

 

[Tom St Denis]

hi everyone

I have a question.

First, I have implemented a huge matrix in a program, like 'unsigned
char matrix[1500][1500];',
when I executed this program, the error occured.

Then I modified the declaration, like 'static unsigned char
matrix[1500][1500];', it runs well.

so, could anyone tell me why the error occured at first situation?

What error? What platform is this on? What compiler?

Tom

 

[Richard Heathfield]

Tom St Denis said:

hi everyone

I have a question.

First, I have implemented a huge matrix in a program, like 'unsigned
char matrix[1500][1500];',
when I executed this program, the error occured.

Then I modified the declaration, like 'static unsigned char
matrix[1500][1500];', it runs well.

so, could anyone tell me why the error occured at first situation?

What error? What platform is this on? What compiler?

If the platform and compiler matter, the question is off-topic in
comp.lang.c. In this case, they don't matter. The code is asking for an
object 2250000 bytes in size, and C90 doesn't guarantee anything over 32767
bytes (C99: 65535), so there's no reason for the code to succeed, no matter
what the compiler or platform.

 

[Keith Thompson]

First, I have implemented a huge matrix in a program, like 'unsigned
char matrix[1500][1500];',
when I executed this program, the error occured.

Then I modified the declaration, like 'static unsigned char
matrix[1500][1500];', it runs well.

so, could anyone tell me why the error occured at first situation?

You've already gotten the best answers you're going to get here. But
for future reference, you should be aware that phrases like "the error
occurred" or "it doesn't work" are nearly useless in diagnosing any
problem. You need to specify *what* error occurred. If there was an
error message, show it to us. If at all possible, show us a small,
complete, self-contained, compilable program that illustrates the
error, so we can try to reproduce it ourselves.

Imagine someone walking into an auto mechanic's shop and saying, "My
car doesn't work", without saying what kind of car it is, giving any
details about *how* it doesn't work, or even bringing the car with
him. He's not likely to get much help.

<http://www.catb.org/~esr/faqs/smart-questions.html> is a good resource.

 

[Sjouke Burry]

hi everyone

I have a question.

First, I have implemented a huge matrix in a program, like 'unsigned
char matrix[1500][1500];',
when I executed this program, the error occured.

Then I modified the declaration, like 'static unsigned char
matrix[1500][1500];', it runs well.

so, could anyone tell me why the error occured at first situation?

thank you very very much~~

Some compilers have non static vars on the stack,
and static in general memory.
If the stack space is less than a few MB,you
have a problem.

 

[Tom St Denis]

If the platform and compiler matter, the question is off-topic in
comp.lang.c. In this case, they don't matter. The code is asking for an
object 2250000 bytes in size, and C90 doesn't guarantee anything over 32767
bytes (C99: 65535), so there's no reason for the code to succeed, no matter
what the compiler or platform.

I don't get your comment.

It's not guranteed to work or not allowed to succeed?

Does the standard guarantee any length program will work on any
platform?

My point/question is, does the standard specifically state that such
behaviour is non-comformant? Or are the rules just relaxed to the
point where you don't have to support it and still claim C99
conformance?

I know many platforms where a 64K structure wouldn't fit anyways

Tom

 

[Keith Thompson]

I don't get your comment.

It's not guranteed to work or not allowed to succeed?

It's not guaranteed to work. Of course it's allowed to succeed.

Does the standard guarantee any length program will work on any
platform?

Not really. The only such guarantee is in C99 5.2.4.1:

The implementation shall be able to translate and execute at least
one program that contains at least one instance of every one of
the following limits:

followed by a list of limits (127 nesting levels of blocks, etc.).

It would, of course, be possible for an implementation to recognize
one such program, and fail to compile anything useful. But it would
be a significant amount of work for the sake of producing an
implementation that's conforming but useless. In real life, the most
straightforward way to satisfy this extremely narrow requirement is to
create a useful implementation with reasonable limits.

My point/question is, does the standard specifically state that such
behaviour is non-comformant? Or are the rules just relaxed to the
point where you don't have to support it and still claim C99
conformance?

Um, what behavior? If you mean failing to execute a program that
creates a 2250000-byte object, yes, that's permitted.

I know many platforms where a 64K structure wouldn't fit anyways

The requirement to support a 65535-byte object aplies only to hosted
environments.

 

[Tom St Denis]

Um, what behavior? If you mean failing to execute a program that
creates a 2250000-byte object, yes, that's permitted.

My point though is the question isn't wholesale off-topic since it's
not forbidden.

Yes, tell them that it doesn't HAVE to work. But chances are his
problem isn't that the compiler rejects 2MB structures. Most likely
some form of pointer error or something.

He wasn't specific enough to make that determination yet.

Tom

 

[Keith Thompson]

My point though is the question isn't wholesale off-topic since it's
not forbidden.

You didn't answer my question. When you wrote "does the standard
specifically state that such behaviour is non-comformant", what
behavior were you referring to?

Yes, tell them that it doesn't HAVE to work. But chances are his
problem isn't that the compiler rejects 2MB structures. Most likely
some form of pointer error or something.

He wasn't specific enough to make that determination yet.

The program declared a large object local to a function, and the
program failed. Making it static avoided the problem. The most
likely explanation is a shortage of stack space.

Running out of stack space like this this is one instance of the C
standard's statement that objects bigger than 65535 bytes needn't be
supported.

 

[Richard Tobin]

The code is asking for an
object 2250000 bytes in size, and C90 doesn't guarantee anything over 32767
bytes (C99: 65535), so there's no reason for the code to succeed, no matter
what the compiler or platform.

Since all that is required of an implementation is that it accept one
program that meets the environmental limits, there is no program that
is required by the standard to succeed.

-- Richard

 

[Richard Heathfield]

Tom St Denis said:

I don't get your comment.

It's not guranteed to work or not allowed to succeed?

Not guaranteed to work.

Does the standard guarantee any length program will work on any
platform?

No, but it does give a few guarantees about what you can rely on as a
programmer. For example, see the Translation Limits section, where this
32767 (or 65535) figure appears under "bytes in an object".

My point/question is, does the standard specifically state that such
behaviour is non-comformant?

Any program that relies on the ability to create an object greater than
32767 (or 65535 for C99) bytes in size is not a strictly conforming
program.

1.7 COMPLIANCE

"A strictly conforming program shall use only those features of the
language and library specified in this Standard. It shall not produce
output dependent on any unspecified, undefined, or implementation-defined
behavior, and shall not exceed any minimum implementation limit."


Or are the rules just relaxed to the

point where you don't have to support it and still claim C99
conformance?

I know many platforms where a 64K structure wouldn't fit anyways

On such platforms, a C99 implementor has his work cut out - or he could
simply claim that it's a freestanding implementation, which lets him off
the 65535 hook completely.

 

[Richard Heathfield]

Richard Tobin said:

Since all that is required of an implementation is that it accept one
program that meets the environmental limits, there is no program that
is required by the standard to succeed.

Very true, but Qoi carp with tiny little backfins are circling around your
argument.

 

[Tom St Denis]

Not guaranteed to work.

Ok, so it's not a standards violation.

No, but it does give a few guarantees about what you can rely on as a
programmer. For example, see the Translation Limits section, where this
32767 (or 65535) figure appears under "bytes in an object".

Ok, but what does that have to do with the price of tea in China?

His problem LIKELY isn't due to this soft restriction. So instead of
being a pedantic lunatic with no real world experience you could infer
from his post [as another OP did] that perhaps it's a runtime failure
[like putting the thing on the stack].

That's the difference between being "right" and "helpful".

Tom

 

[Richard Tobin]

No, but it does give a few guarantees about what you can rely on as a
programmer. For example, see the Translation Limits section, where this
32767 (or 65535) figure appears under "bytes in an object".

[/QUOTE]

His problem LIKELY isn't due to this soft restriction. So instead of
being a pedantic lunatic with no real world experience you could infer
from his post [as another OP did] that perhaps it's a runtime failure
[like putting the thing on the stack].

The limits section is relevant, because its purpose is to allow such
runtime failures without making the compiler non-conformant. However
it would indeed be helpful to point out that most operating systems
provide a way for the user to control such limits, such as the
"ulimit" command in some Unix shells.

-- Richard