Problem with Array size

[biplab]

Hi all,
I am using TC 3.0..there if I declare a integer array with dimension
162*219...an error msg saying that too long array is shown....what
should I do to recover from this problem???

 

[biplab]

biplab said:


Use a smaller array.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

But I need to use array with this dimension..is there any way to
resolve it??

 

[s0suk3]

But I need to use array with this dimension..is there any way to
resolve it??

Post the code to see if we can figure any alternatives. But *please*
don't post the code that writes to unexistent memory in all the first
four lines of main(), unless you have fixed it.

Sebastian

 

[Thomas Austad]

Hi all,
I am using TC 3.0..there if I declare a integer array with dimension
162*219...an error msg saying that too long array is shown....what
should I do to recover from this problem???

Are you compiling this for DOS real-mode by any chance?
If so your problem might be that 162*219*sizeof(int) is 70956 bytes
which is larger than the DOS real-mode segment size(65536 bytes).

 

[vippstar]

Hi all,
I am using TC 3.0..there if I declare a integer array with dimension
162*219...an error msg saying that too long array is shown....what
should I do to recover from this problem???

char foo[162 * 219];

Is an integer array that any C99 implementation can accept.

Don't quote sig blocks. (you've done so in another reply)

 

[Keith Thompson]

Hi all,
I am using TC 3.0..there if I declare a integer array with dimension
162*219...an error msg saying that too long array is shown....what
should I do to recover from this problem???

char foo[162 * 219];

Is an integer array that any C99 implementation can accept.

[...]

Yes, it is. Is that intended to be a response to the OP's question?
Are you under the impression that the OP is using a C99
implementation, or that he either tried to or should declare an array
of char?

I strongly suspect that the OP fell into the trap of conflating "int"
and "integer". It's an easy mistake to make. It's also an easy
mistake to point out in a straightforward manner. Perhaps that's what
you intended to do, but it's likely the OP is going to miss the
subtlety of your demonstration.

The OP needs to post the actual code and the actual error message.
Telling him that is just as easy as giving a response that assumes a
literal interpretation of the OP's words that are obviously
inconsistent with what he actually meant.

Using a little common sense now and then doesn't violate the
comp.lang.c topicality guidelines.

 

[Martin Ambuhl]

Hi all,
I am using TC 3.0..there if I declare a integer array with dimension
162*219...an error msg saying that too long array is shown....what
should I do to recover from this problem???

There are (at least) 3 possible situations:

1. Auto array:
int main(void) {
int array[162][219];
return 0;
}

If this is what you are trying to do, your array may exceed the limits
for an automatic object. The TC implementation uses a stack for storage
of automatic objects, and the documentation tells you how to increase
that stack size. That is an implementation-specific detail, for which
any further questions belong in some forum (newsgroup, technical
support, mailing list, etc.) dedicated to Borland implementations, not
here. But there are other possibilities, either as the cause or
solution to your problem, such as

2. Static array
2a. With block scope
int main(void) {
static int array[162][219];
return 0;
}
2b. With file scope
/* static */ int array[162][219];
int main(void) {
return 0;
}

Making the array static _might_ solve your problem, since static arrays
are rarely allocated using the same scheme as auto arrays. In
particular, your implementation will not try to put them on the stack.
But it is possible that the size of the array exceeds that supported by
your implementation for objects, when you will need ...

3. Dynamically allocated array
#include <stdlib.h>
int main(void)
{
int **array;
const size_t rows=152, cols=219;
size_t i;
/* check the FAQ for another way to do this */
if (!(array = malloc(rows * sizeof *array)))
/* handle error */;
for (i = 0; i < rows; i++)
if (!(array = malloc(cols * sizeof *array)))
/* handle error */
/* after using it, free it analogously */
return 0;
}

If the above doesn't work, notice that TC uses various memory models.
You can change the above to use the non-standard far pointers (and
associated version of malloc), when any questions again belong in a
Borland forum, or you could use the documented compilation flags to
force the compiler to use a memory model that will allow objects of the
right size. The "huge" memory model might be right, but again that is a
question for a Borland forum, not here.

If none of the above works, either your machine has insufficient memory
or you need a different compiler. As a matter of fact, you should
consider a different compiler anyway. Borland makes the command line
version of its 32-bit compiler available free, there are various
versions of gcc available free, Jacob makes lcc available free for
single non-commercial users, and there are more. TC is not a good choice.

 

[vippstar]

char foo[162 * 219];

Is an integer array that any C99 implementation can accept.

[...]

Yes, it is. Is that intended to be a response to the OP's question?
Are you under the impression that the OP is using a C99
implementation, or that he either tried to or should declare an array
of char?

I strongly suspect that the OP fell into the trap of conflating "int"
and "integer". It's an easy mistake to make. It's also an easy
mistake to point out in a straightforward manner. Perhaps that's what
you intended to do, but it's likely the OP is going to miss the
subtlety of your demonstration.

The OP needs to post the actual code and the actual error message.
Telling him that is just as easy as giving a response that assumes a
literal interpretation of the OP's words that are obviously
inconsistent with what he actually meant.

Using a little common sense now and then doesn't violate the
comp.lang.c topicality guidelines.

I understand what you're saying.
However, I think this biplab person is a troll. (Yes, I'm a bit
paranoid, but that's what his previous messages suggest)
I wanted to see his reply to my post to figure out if he's indeed a
troll or legitimate.

As for C99, he said "I'm using TC 3.0". I have no idea what that is,
but I thought maybe he's referring to technical corrigendum 3. (though
unlikely)

Regardless, here's a more "complete" answer...

In C90, it's impossible to have such array in every implementation.
Keep in mind, 162 * 219 = 35478

Environmental limits allow any conforming C90 implementation to fail
to translate a program if its source code has an object that is larger
than 32767 bytes.

~(size_t)0 is guaranteed to be equal or greater than 32767.
(note I'm using ~(size_t)0 since there is no SIZE_MAX in C90)

So malloc(35478) might not allocate an object of 35478 bytes, if
~(size_t)0 is equal to 32767.
Instead, it will allocate 35478 - 32767 - 1 bytes. (2710)

In C99, SIZE_MAX in <limits.h> is equal to ~(size_t)0. It's equal or
greater than 65535.
If by integer you meant int, you can have

int array[35478];

*ONLY* if sizeof (int) == 1, which is quite unlikely for most
implementations.
You can do something like this in C99:

#include <limits.h>
#if SIZE_MAX < ULONG_MAX
# error not enough resources
#endif

/* ... */

Then use malloc. (just because SIZE_MAX is greater than the suggested
environmental limit by the standard does not mean the implementation
must allow objects that large)


Since you want an array so big, you might want to conform to another
standard instead of ISO C, such as POSIX of windows C. (is there such
standard anyway? windows C programming...)
Those are off-topic for comp.lang.c by the way.

 

[vippstar]

On Sep 15, 11:10 pm, (e-mail address removed) wrote:

If by integer you meant int, you can have

int array[35478];

*ONLY* if sizeof (int) == 1, which is quite unlikely for most implementations

Or if the environmental limits allow it, of course.

 

[Keith Thompson]

As for C99, he said "I'm using TC 3.0". I have no idea what that is,
but I thought maybe he's referring to technical corrigendum 3. (though
unlikely)

[...]

That interpretation hadn't occurred to me. I assumed (and I still
assume) that he's using Turbo C 3.0, a rather old implementation.

 

[CBFalconer]

I am using TC 3.0..there if I declare a integer array with
dimension 162*219...an error msg saying that too long array is
shown....what should I do to recover from this problem???

char foo[162 * 219];

Is an integer array that any C99 implementation can accept.

No they can't. From the C standard:

5.2.4.1 Translation limits

[#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:12)

.... snip ...

-- 4095 characters in a character string literal or wide
string literal (after concatenation)

-- 65535 bytes in an object (in a hosted environment only)

and C90 (which is what TC 3.0 attempts to satisfy) only requires
32767 bytes, I believe.

 

[Default User]

As for C99, he said "I'm using TC 3.0". I have no idea what that is,
but I thought maybe he's referring to technical corrigendum 3. (though
unlikely)

Normally Turbo C, an old albeit once popular compiler series from
Borland. Old TC compilers have seen a new life due to of our Asian
participants downloading them free from the Borland museum.





Brian

 

[vippstar]

(e-mail address removed) writes:

[...]> As for C99, he said "I'm using TC 3.0". I have no idea what that is,

but I thought maybe he's referring to technical corrigendum 3. (though
unlikely)

[...]

That interpretation hadn't occurred to me. I assumed (and I still
assume) that he's using Turbo C 3.0, a rather old implementation.

Yeah, that's probably it. I have heard of Turbo C, but didn't know
they call it TC (google didn't help, but I did not try many queries
anyway)

 

[vippstar]

char foo[162 * 219];

Is an integer array that any C99 implementation can accept.

No they can't. From the C standard:

5.2.4.1 Translation limits

[#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:12)

... snip ...

-- 4095 characters in a character string literal or wide
string literal (after concatenation)

-- 65535 bytes in an object (in a hosted environment only)

and C90 (which is what TC 3.0 attempts to satisfy) only requires
32767 bytes, I believe.

I said "any *C99* implementation". At the time of my post I didn't
even know what TC 3.0 stands for, but even if I knew, that would not
make my claim any less true.
(Unless what you are nitpicking here is that I said any C99
implementation and not any C99 hosted implementation)

 

[Kenny McCormack]

Using a little common sense now and then doesn't violate the
comp.lang.c topicality guidelines.

Oh, I believe that it does. Give me a bit and I'll come up with C&V
from the standard to prove it.

 

[Keith Thompson]

I am using TC 3.0..there if I declare a integer array with
dimension 162*219...an error msg saying that too long array is
shown....what should I do to recover from this problem???

char foo[162 * 219];

Is an integer array that any C99 implementation can accept.

No they can't. From the C standard:

Yes, they can.

5.2.4.1 Translation limits

[#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:12)

... snip ...

-- 4095 characters in a character string literal or wide
string literal (after concatenation)

There is no character string literal.

-- 65535 bytes in an object (in a hosted environment only)

and C90 (which is what TC 3.0 attempts to satisfy) only requires
32767 bytes, I believe.

Yes, but vippstar's statement (which was based on an erroneous
assumption) was about C99 implementations.

 

[CBFalconer]

.... snip ...

However, I think this biplab person is a troll. (Yes, I'm a bit
paranoid, but that's what his previous messages suggest) I wanted
to see his reply to my post to figure out if he's indeed a troll
or legitimate.

As for C99, he said "I'm using TC 3.0". I have no idea what that
is, but I thought maybe he's referring to technical corrigendum
3. (though unlikely)

No, that is Turbo C 3.0 for MsDOS. It is available free on the
Borland site. It was published just before the C89 standard came
out, and adhered to a slightly earlier draft, so it is quite
close. It is useful for checking that code compiles and executes
in a 16 bit environment.

I seem to overdo seeing off-topic posts. You overdo seeing
trolls. We are both wrong.

 

[CBFalconer]

I am using TC 3.0..there if I declare a integer array with
dimension 162*219...an error msg saying that too long array is
shown....what should I do to recover from this problem???

char foo[162 * 219];

Is an integer array that any C99 implementation can accept.

No they can't. From the C standard:

Yes, they can.

5.2.4.1 Translation limits

[#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:12)

... snip ...

-- 4095 characters in a character string literal or wide
string literal (after concatenation)

There is no character string literal.

-- 65535 bytes in an object (in a hosted environment only)

and C90 (which is what TC 3.0 attempts to satisfy) only requires
32767 bytes, I believe.

Yes, but vippstar's statement (which was based on an erroneous
assumption) was about C99 implementations.

No they can't. My quote, above, was from the C99 standard. The
last line pointed out that C90 didn't even guarantee that much
space. The character string literal portion was only to ease
finding the appropriate point in the actual standard for curious
readers. Non-hosted environments (e.g. embedded machines) don't
have to meet that provision.

The original post specified an int array, requiring at least 2
bytes per int in most systems.

 

[CBFalconer]

.... snip ...

If none of the above works, either your machine has insufficient
memory or you need a different compiler. As a matter of fact,
you should consider a different compiler anyway. Borland makes
the command line version of its 32-bit compiler available free,
there are various versions of gcc available free, Jacob makes
lcc available free for single non-commercial users, and there
are more. TC is not a good choice.

For checking source portability to aa 16 bit environment, TC is an
excellent choice. For other purposes I can agree with you.

 

[Default User]

(e-mail address removed) wrote:

No, that is Turbo C 3.0 for MsDOS. It is available free on the
Borland site. It was published just before the C89 standard came
out, and adhered to a slightly earlier draft, so it is quite
close.

I believe you are thinking of TC 2.0. There never was a Turbo C 3.0,
they combined C and C++ into one product after TC 2.01 I believe.




Brian