By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,233 Members | 1,972 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,233 IT Pros & Developers. It's quick & easy.

about declaration of huge matrix in C

P: n/a
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~~

Jun 21 '06 #1
Share this Question
Share on Google+
15 Replies


P: n/a


lu**********@gmail.com wrote On 06/21/06 11:30,:
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/

--
Er*********@sun.com

Jun 21 '06 #2

P: n/a

lu**********@gmail.com wrote:
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

Jun 21 '06 #3

P: n/a
Le 21-06-2006, lu**********@gmail.com <lu**********@gmail.com> a écrit*:
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
Jun 21 '06 #4

P: n/a
Tom St Denis said:

lu**********@gmail.com wrote:
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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 21 '06 #5

P: n/a
"lu**********@gmail.com" <lu**********@gmail.com> writes:
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.

--
Keith Thompson (The_Other_Keith) 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.
Jun 21 '06 #6

P: n/a
lu**********@gmail.com wrote:
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.
Jun 21 '06 #7

P: n/a
Richard Heathfield wrote:
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

Jun 21 '06 #8

P: n/a
"Tom St Denis" <to********@gmail.com> writes:
Richard Heathfield wrote:
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?


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.

--
Keith Thompson (The_Other_Keith) 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.
Jun 21 '06 #9

P: n/a
Keith Thompson wrote:
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.


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

Jun 22 '06 #10

P: n/a
"Tom St Denis" <to********@gmail.com> writes:
Keith Thompson wrote:
> 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.


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.

--
Keith Thompson (The_Other_Keith) 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.
Jun 22 '06 #11

P: n/a
In article <Sv********************@bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
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
Jun 22 '06 #12

P: n/a
Tom St Denis said:
Richard Heathfield wrote:
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?


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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 22 '06 #13

P: n/a
Richard Tobin said:
In article <Sv********************@bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
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.


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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 22 '06 #14

P: n/a
Richard Heathfield wrote:
It's not guranteed to work or not allowed to succeed?


Not guaranteed to work.


Ok, so it's not a standards violation.
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".


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

Jun 22 '06 #15

P: n/a
In article <11**********************@c74g2000cwc.googlegroups .com>,
Tom St Denis <to********@gmail.com> wrote:
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".
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

Jun 22 '06 #16

This discussion thread is closed

Replies have been disabled for this discussion.