424,054 Members | 1,055 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,054 IT Pros & Developers. It's quick & easy.

Array size limits

P: n/a
How do I determine the maximum array size?

For example, int a[10000] works, but a[10000000] does not (run time
error).

Thank you.

Nov 14 '05 #1
Share this Question
Share on Google+
37 Replies


P: n/a
On Tue, 31 Aug 2004 02:08:08 GMT, Carol Depore <no****@nowhere.com>
wrote in comp.lang.c:
How do I determine the maximum array size?
You can't
For example, int a[10000] works, but a[10000000] does not (run time
error).

Thank you.


The original C standard (ANSI 1989/ISO 1990) required that a compiler
successfully translate at least one program containing at least one
example of a set of environmental limits. One of those limits was
being able to create an object of at least 32,767 bytes.

This minimum limit was raised in the 1999 update to the C standard to
be at least 65,535 bytes.

No C implementation is required to provide for objects greater than
that size, which means that they don't need to allow for an array of
ints greater than (int)(65535 / sizeof(int)).

In very practical terms, on modern computers, it is not possible to
say in advance how large an array can be created. It can depend on
things like the amount of physical memory installed in the computer,
the amount of virtual memory provided by the OS, the number of other
tasks, drivers, and programs already running and how much memory that
are using. So your program may be able to use more or less memory
running today than it could use yesterday or it will be able to use
tomorrow.

Many platforms place their strictest limits on automatic objects, that
is those defined inside of a function without the use of the 'static'
keyword. On some platforms you can create larger arrays if they are
static or by dynamic allocation.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #2

P: n/a
Carol Depore <no****@nowhere.com> writes:
How do I determine the maximum array size?


There is no portable way. You are better off using dynamic
allocation, because then you can try different sizes at runtime.
--
"Am I missing something?"
--Dan Pop
Nov 14 '05 #3

P: n/a
On Mon, 30 Aug 2004 21:48:07 -0500, Jack Klein <ja*******@spamcop.net>
wrote:
On Tue, 31 Aug 2004 02:08:08 GMT, Carol Depore <no****@nowhere.com>
wrote in comp.lang.c:
How do I determine the maximum array size?
You can't
For example, int a[10000] works, but a[10000000] does not (run time
error).

Thank you.


The original C standard (ANSI 1989/ISO 1990) required that a compiler
successfully translate at least one program containing at least one
example of a set of environmental limits. One of those limits was
being able to create an object of at least 32,767 bytes.

This minimum limit was raised in the 1999 update to the C standard to
be at least 65,535 bytes.

No C implementation is required to provide for objects greater than
that size, which means that they don't need to allow for an array of
ints greater than (int)(65535 / sizeof(int)).


So...are you saying that I am guaranteed at least int a[65535], but no
guarantees beyond that?



In very practical terms, on modern computers, it is not possible to
say in advance how large an array can be created. It can depend on
things like the amount of physical memory installed in the computer,
the amount of virtual memory provided by the OS, the number of other
tasks, drivers, and programs already running and how much memory that
are using. So your program may be able to use more or less memory
running today than it could use yesterday or it will be able to use
tomorrow.

Many platforms place their strictest limits on automatic objects, that
is those defined inside of a function without the use of the 'static'
keyword. On some platforms you can create larger arrays if they are
static or by dynamic allocation.


Nov 14 '05 #4

P: n/a
Carol Depore <no****@nowhere.com> writes:
On Mon, 30 Aug 2004 21:48:07 -0500, Jack Klein <ja*******@spamcop.net>
wrote:
No C implementation is required to provide for objects greater than
that size, which means that they don't need to allow for an array of
ints greater than (int)(65535 / sizeof(int)).


So...are you saying that I am guaranteed at least int a[65535], but no
guarantees beyond that?


No. To start with, sizeof(int) may be, and usually is, greater
than 1.
--
"...what folly I commit, I dedicate to you."
--William Shakespeare, _Troilus and Cressida_
Nov 14 '05 #5

P: n/a
On Mon, 30 Aug 2004 20:48:45 -0700, Ben Pfaff <bl*@cs.stanford.edu>
wrote:
Carol Depore <no****@nowhere.com> writes:
On Mon, 30 Aug 2004 21:48:07 -0500, Jack Klein <ja*******@spamcop.net>
wrote:
No C implementation is required to provide for objects greater than
that size, which means that they don't need to allow for an array of
ints greater than (int)(65535 / sizeof(int)).


So...are you saying that I am guaranteed at least int a[65535], but no
guarantees beyond that?


No. To start with, sizeof(int) may be, and usually is, greater
than 1.

Oh, I see...so, if sizeof(int) is 2 bytes, then I am guaranteed at
least int a[32767], but no larger sized arrays are guaranteed.

Thanks for the help!

Nov 14 '05 #6

P: n/a

"Carol Depore" <no****@nowhere.com> wrote in message
news:iu********************************@4ax.com...
On Mon, 30 Aug 2004 20:48:45 -0700, Ben Pfaff <bl*@cs.stanford.edu>
wrote:
Carol Depore <no****@nowhere.com> writes:
On Mon, 30 Aug 2004 21:48:07 -0500, Jack Klein <ja*******@spamcop.net>
wrote:
No C implementation is required to provide for objects greater than
that size, which means that they don't need to allow for an array of
ints greater than (int)(65535 / sizeof(int)).

So...are you saying that I am guaranteed at least int a[65535], but no
guarantees beyond that?
No. To start with, sizeof(int) may be, and usually is, greater
than 1.

Oh, I see...so, if sizeof(int) is 2 bytes, then I am guaranteed at
least int a[32767], but no larger sized arrays are guaranteed.

No, You have to check INT_MAX in your limits.h file to know the exact
maximum
value that an integer can hold on your implementation.

Thanks for the help!

Nov 14 '05 #7

P: n/a
"Ravi Uday" <ra******@gmail.com> writes:
"Carol Depore" <no****@nowhere.com> wrote in message
news:iu********************************@4ax.com...

[...]
Oh, I see...so, if sizeof(int) is 2 bytes, then I am guaranteed at
least int a[32767], but no larger sized arrays are guaranteed.

No, You have to check INT_MAX in your limits.h file to know the exact
maximum
value that an integer can hold on your implementation.


INT_MAX isn't relevant. The limit in question is the maximum size of
an object, which is at least 65535 bytes (in a hosted environment
only). If sizeof(int) is 2, you're guaranteed at least int a[32767];
if sizeof(int) is 4; you're only guaranteed at least int a[16383].

But actually the guarantee is even weaker than that. The standard
only requires that the implementation must be able to translate and
execute at least one program containing an object of 65535 bytes
(along with a number of other limits, such as 127 arguments in one
function call). It's not required to handle *your* program containing
an object of 65535 bytes.

Practically speaking, though, the easiest way to satisfy the
translation limits is generally to impose no explicit limits, but to
support whatever will fit in memory, either at compile time or at run
time. A (non-binding) footnote in C99 5.2.4.1 says, "Implementations
should avoid imposing fixed translation limits whenever possible."

--
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.
Nov 14 '05 #8

P: n/a
Keith Thompson wrote:

"Ravi Uday" <ra******@gmail.com> writes:
"Carol Depore" <no****@nowhere.com> wrote in message
news:iu********************************@4ax.com...

[...]
Oh, I see...so, if sizeof(int) is 2 bytes, then I am guaranteed at
least int a[32767], but no larger sized arrays are guaranteed.

No, You have to check INT_MAX in your limits.h file to know the exact
maximum
value that an integer can hold on your implementation.


INT_MAX isn't relevant. The limit in question is the maximum size of
an object, which is at least 65535 bytes (in a hosted environment
only). If sizeof(int) is 2, you're guaranteed at least int a[32767];
if sizeof(int) is 4; you're only guaranteed at least int a[16383].

But actually the guarantee is even weaker than that. The standard
only requires that the implementation must be able to translate and
execute at least one program containing an object of 65535 bytes
(along with a number of other limits, such as 127 arguments in one
function call). It's not required to handle *your* program containing
an object of 65535 bytes.


I think what they meant by the "at least one" part,
is closer to saying
"A C implementation is something which can translate and execute
a C program, and anything that can't translate and execute
a C program, isn't a C implementation"

I don't think that they meant to suggest that an implementation
which doesn't self destruct after program translation and execution,
"exceeds ANSI standards".

--
pete
Nov 14 '05 #9

P: n/a

Everyone, thank you for your help. I feel a little like I'm asking
Einstein to explain relativity to me. I'm way out of my league.
So, thanks for your patience.

Anyway, I'm still confused about how large a simple int array can be.
I understand what Jack and Ben said about the Standard guaranteeing
at least int a[32767], but I don't understand why I can't have an
array of int a[600000], especially since I have 311MB of unused memory
on my machine, and I thought the machine would allow programs up to
4GB.

Here's my little test program, which works for 500000, but fails for
600000.

All help to relieve my confusion is appreciated. I think I'm not
understanding something very fundamental.
#include <stdio.h>

//#define NNN 600000
#define NNN 500000

int main() {
long i;
int a[NNN];
for (i=0;i<NNN;i++) {
printf("%i\n",i);
a[i] = 1;
}
}

Nov 14 '05 #10

P: n/a
pete <pf*****@mindspring.com> writes:
Keith Thompson wrote:

[...]
But actually the guarantee is even weaker than that. The standard
only requires that the implementation must be able to translate and
execute at least one program containing an object of 65535 bytes
(along with a number of other limits, such as 127 arguments in one
function call). It's not required to handle *your* program containing
an object of 65535 bytes.


I think what they meant by the "at least one" part,
is closer to saying
"A C implementation is something which can translate and execute
a C program, and anything that can't translate and execute
a C program, isn't a C implementation"

I don't think that they meant to suggest that an implementation
which doesn't self destruct after program translation and execution,
"exceeds ANSI standards".


Actually, I think that is what they meant. For example, if an
implementation can handle a single carefully written program that
meets each of the translation limits, including a single object of
exactly 65535 bytes, but falls over and dies if you add a 1-byte
object declaration to that same program, that implementation is
conforming (assuming it doesn't have any other problems).

That doesn't imply that such an implementation is *useful*; that's a
QoI (Quality of Implementation) issue.

In real life, nobody bothers to implement a conforming C compiler
that's totally useless (or if anybody does, it rapidly vanishes).

--
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.
Nov 14 '05 #11

P: n/a
Carol Depore wrote:
Everyone, thank you for your help. I feel a little like I'm asking
Einstein to explain relativity to me. I'm way out of my league.
So, thanks for your patience.

Anyway, I'm still confused about how large a simple int array can be.
I understand what Jack and Ben said about the Standard guaranteeing
at least int a[32767], but I don't understand why I can't have an
array of int a[600000], especially since I have 311MB of unused memory
on my machine, and I thought the machine would allow programs up to
4GB.
Your machine (like many) apparently exceeds the minimum
requirements imposed by the C language Standard. It's sort
of like the Federal definition of the minimum wage: Employers
are required to pay at least thus-and-such much per hour of
labor, but many laborers nonetheless demand and receive more.
Be happy; you're rich!
Here's my little test program, which works for 500000, but fails for
600000.
Your C implementation is giving you more than the minimum,
but does in fact have a limit on how big the array can be.
You're rich, but you're not Bill Gates.
All help to relieve my confusion is appreciated. I think I'm not
understanding something very fundamental.
#include <stdio.h>

//#define NNN 600000
#define NNN 500000

int main() {
long i;
int a[NNN];


Here's another issue. C data objects can have various
"storage classes:" automatic, static, and dynamic. The amount
of memory available for an object can be different for the
different storage classes. Your a[] array occupies automatic
storage, which is typically (although not necessarily) subject
to the tightest space restrictions. You may see dramatically
different results if you change the above to

int main() {
static int a[NNN};
...

or

int main() {
int *a = malloc(NNN * sizeof *a);
if (a != NULL) {
...

The first of these uses static storage for a[], and the
second replaces the array with a pointer to dynamic storage.
There will be limits on how much static or dynamic memory
you can devote to your data, but they're likely to be looser
than the limits on automatic storage.

You're rich, but if you want to augment your wealth it's
better to rob big banks than little ones.

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

Nov 14 '05 #12

P: n/a
Carol Depore <no****@nowhere.com> writes:
[...]
Anyway, I'm still confused about how large a simple int array can be.
I understand what Jack and Ben said about the Standard guaranteeing
at least int a[32767], but I don't understand why I can't have an
array of int a[600000], especially since I have 311MB of unused memory
on my machine, and I thought the machine would allow programs up to
4GB.

Here's my little test program, which works for 500000, but fails for
600000.

All help to relieve my confusion is appreciated. I think I'm not
understanding something very fundamental.

#include <stdio.h>

//#define NNN 600000
#define NNN 500000

int main() {
long i;
int a[NNN];
for (i=0;i<NNN;i++) {
printf("%i\n",i);
a[i] = 1;
}
}


The standard doesn't guarantee at least int a[32767] unless
sizeof(int) happens to be 1 or 2. The specific guarantee is an object
of at least 65535 bytes. But almost all implementations exceed that
guarantee.

You say the program fails for 600000, but you don't say *how* it
fails. It probably doesn't matter much in this case, but in general
knowing *how* something fails can be critical to figuring out what the
problem is.

The maximum size allowed for int a[NNN] in your program, and what's
going to happen if you exceed it, is going to depend on any of a
number of things, most of which we can't help you with here. The
total amount of memory available on the system is only one possible
factor. Some systems impose specific limits on stack size (the array
is probably going to be allocated on "the stack", though the C
standard doesn't define such a thing), but you probably don't know
what else is allocate there. Some systems might allow you to adjust
the limits (on Unix-like systems, see the "limit" or "ulimit" command;
on other systems, I have no clue). Some systems may support larger
chunks of memory in different contexts; for example, declaring a as a
global variable might put it in the data section rather than on the
stack, or you might try allocating it via malloc().

If you want to ask about the details, you should try a newsgroup
that's specific to your system.

--
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.
Nov 14 '05 #13

P: n/a
Carol Depore wrote:
.... snip ...
Anyway, I'm still confused about how large a simple int array
can be. I understand what Jack and Ben said about the Standard
guaranteeing at least int a[32767], but I don't understand why
I can't have an array of int a[600000], especially since I have
311MB of unused memory on my machine, and I thought the machine
would allow programs up to 4GB.

Here's my little test program, which works for 500000, but
fails for 600000.

#include <stdio.h>

//#define NNN 600000
#define NNN 500000

int main() {
long i;
int a[NNN];
for (i=0;i<NNN;i++) {
printf("%i\n",i);
a[i] = 1;
}
}


This tells me that your system assigns a default stack size
(assuming it has a stack) of between 500,000 * sizeof int and
600,000 * sizeof int. The most likely values are 1 meg and 2 meg.

--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"We have always known that heedless self-interest was bad
morals. We now know that it is bad economics" - FDR

Nov 14 '05 #14

P: n/a
I don't know how ANSI C says. But the stacksize of a program in runtime is
limited by Opterating System. So that C compiler always doesn't give out an
compile time error.

If you are on Linux, you can use "limit" command to show the limits and use
"limit stacksize 1000000" to change them. I think your program will work OK
after change the limit.

Thanks!
Wei
"Carol Depore" <no****@nowhere.com> wrote in message
news:lm********************************@4ax.com...
How do I determine the maximum array size?

For example, int a[10000] works, but a[10000000] does not (run time
error).

Thank you.

Nov 14 '05 #15

P: n/a
"Wei Li" <li*************@yahoo.com> writes:
I don't know how ANSI C says. But the stacksize of a program in runtime is
limited by Opterating System. So that C compiler always doesn't give out an
compile time error.

If you are on Linux, you can use "limit" command to show the limits and use
"limit stacksize 1000000" to change them. I think your program will work OK

"Carol Depore" <no****@nowhere.com> wrote in message
news:lm********************************@4ax.com...
How do I determine the maximum array size?

For example, int a[10000] works, but a[10000000] does not (run time
error).

Thank you.


Wei Li: Please don't top-post.

Top-posting means writing your new material first, followed by the
quoted article to which you're responding. It makes it difficult to
follow the discussion, especially when (almost) everyone else
bottom-posts, as I'm doing there. (You should also trim anything
that's not relevant to your response, though in this case the previous
article was short enough that quoting the whole thing is probably ok.)

Thanks.

--
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.
Nov 14 '05 #16

P: n/a

"Wei Li" <li*************@yahoo.com> wrote in message
news:10*************@corp.supernews.com...
I don't know how ANSI C says. But the stacksize of a program in runtime is limited by Opterating System. So that C compiler always doesn't give out an compile time error.

If you are on Linux, you can use "limit" command to show the limits and use "limit stacksize 1000000" to change them. I think your program will work OK after change the limit.

"Carol Depore" <no****@nowhere.com> wrote in message
news:lm********************************@4ax.com...
How do I determine the maximum array size?

For example, int a[10000] works, but a[10000000] does not (run time
error).


It's the same with recursion. I attempted a simple factorial program (below)
and it crapped out at 39! and even then I think the result was wrong (it was
a while ago, so I don't remember whether it worked right or not) but I
needed something much bigger, so I moved on. I recall believing the fault
was in the recursion, not the size of the value, but it was many years ago.

-------------------------------------------
#include <stdio.h>
#include <stdlib.h>

double fact (int n);

void main(int argc, char **argv)
{
int n;
double factorial=1;

n = atoi (argv[1]);
fact (n);
}

double fact (int n)
{
static double value=1;

if (n > 1)
value = n * fact (n-1);

printf ("%3.d! = %.0f \n", n, value);

return (value);
}
-------------------------------------------

--
Mabden


Nov 14 '05 #17

P: n/a

Wow, I think a little tiny light bulb has been lit in my head! Thanks
to all of you!

In summary,
- There are TWO areas for array allocation, a stack area and a global
area.
- When my little test program uses the stack (by default), the array
is limited to about int a[500000]. (the stack limit probably can be
increased, but I'll learn that later).
- However, if I use the global area, by "static int", then my array
can be much larger. My test program below, with a[20000000], worked
fine!!

#include <stdio.h>

//#define NNN 600000
#define NNN 20000000

int main() {
long i;
static int a[NNN];
printf("Start\n");
for (i=0;i<NNN;i++) {
printf("%i\n",i);
a[i] = 1;
}
}
Thanks again, to all of you!
Nov 14 '05 #18

P: n/a
Carol Depore <no****@nowhere.com> wrote:

Anyway, I'm still confused about how large a simple int array can be.
Short answer: it depends, and you can't tell in advance.
I understand what Jack and Ben said about the Standard guaranteeing
at least int a[32767], but I don't understand why I can't have an
array of int a[600000], especially since I have 311MB of unused memory
on my machine, and I thought the machine would allow programs up to
4GB.
Your machine probably has restrictions on how big "automatic"
objects can be (ie. when you go int a[NNN] inside a function).
if you want to use up all of your actual memory then you should
try dynamic allocation, which has the advantage that you can
handle errors nicely instead of just getting a runtime error:
#include <stdio.h>

//#define NNN 600000
#define NNN 500000

int main() {
long i;
int a[NNN];
for (i=0;i<NNN;i++) {
printf("%i\n",i);
a[i] = 1;
}
}


#include <stdio.h>
#include <stdlib.h>

#define NNN 600000

int main(void) {
long i;
int *a = malloc(NNN * sizeof *a);
if (a == NULL) {
printf("not enough memory.\n");
return EXIT_FAILURE;
}
for (i = 0; i < NNN; i++) {
printf("%i\n", i);
a[i] = 1;
}
free(a); /* releases the memory for other applications */
}
Nov 14 '05 #19

P: n/a
Thanks! I will be careful next time :P

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Wei Li" <li*************@yahoo.com> writes:
I don't know how ANSI C says. But the stacksize of a program in runtime is limited by Opterating System. So that C compiler always doesn't give out an compile time error.

If you are on Linux, you can use "limit" command to show the limits and use "limit stacksize 1000000" to change them. I think your program will work OK
"Carol Depore" <no****@nowhere.com> wrote in message
news:lm********************************@4ax.com...
How do I determine the maximum array size?

For example, int a[10000] works, but a[10000000] does not (run time
error).

Thank you.

Wei Li: Please don't top-post.

Top-posting means writing your new material first, followed by the
quoted article to which you're responding. It makes it difficult to
follow the discussion, especially when (almost) everyone else
bottom-posts, as I'm doing there. (You should also trim anything
that's not relevant to your response, though in this case the previous
article was short enough that quoting the whole thing is probably ok.)

Thanks.

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

Nov 14 '05 #20

P: n/a
In <10*************@corp.supernews.com> "Wei Li" <li*************@yahoo.com> writes:
I don't know how ANSI C says. But the stacksize of a program in runtime is
limited by Opterating System. So that C compiler always doesn't give out an
compile time error.

If you are on Linux, you can use "limit" command to show the limits and use
"limit stacksize 1000000" to change them. I think your program will work OK
after change the limit.
How do you know the OP's array was automatically allocated?

Dan
"Carol Depore" <no****@nowhere.com> wrote in message
news:lm********************************@4ax.com.. .
How do I determine the maximum array size?

For example, int a[10000] works, but a[10000000] does not (run time
error).


--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #21

P: n/a
Please use google groups to read news. It syntax highlights
everything so threads aren't difficult to follow either way. Btw, I
prefer "topposting" since you don't have to scroll past what's already
been said in the thread.

I'm really surprised though that noone has pointed out so far that
most compilers will have some kind of flag or directive to allow a
larger stack size which is the most likely wall you're running in to
(all this talk of standards and no real solutions).

Keith Thompson <ks***@mib.org> wrote in message news:<ln************@nuthaus.mib.org>...
"Wei Li" <li*************@yahoo.com> writes:
I don't know how ANSI C says. But the stacksize of a program in runtime is
limited by Opterating System. So that C compiler always doesn't give out an
compile time error.

If you are on Linux, you can use "limit" command to show the limits and use
"limit stacksize 1000000" to change them. I think your program will work OK

"Carol Depore" <no****@nowhere.com> wrote in message
news:lm********************************@4ax.com...
How do I determine the maximum array size?

For example, int a[10000] works, but a[10000000] does not (run time
error).

Thank you.


Wei Li: Please don't top-post.

Top-posting means writing your new material first, followed by the
quoted article to which you're responding. It makes it difficult to
follow the discussion, especially when (almost) everyone else
bottom-posts, as I'm doing there. (You should also trim anything
that's not relevant to your response, though in this case the previous
article was short enough that quoting the whole thing is probably ok.)

Thanks.

Nov 14 '05 #22

P: n/a
In article <10*************@corp.supernews.com>, li*************@yahoo.com
says...
Thanks! I will be careful next time :P

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...


[snip discussion about top-posting]

You just did it again. Better be more careful. :-)

--
Randy Howard
To reply, remove FOOBAR.
Nov 14 '05 #23

P: n/a
On 1 Sep 2004 07:59:26 -0700
gr****@hotmail.com (grv575) wrote:
Please use google groups to read news.
Google is an on-line service that performs badly as a news reader. Many
people read groups off-line for a number of good reasons, including
dial-up connections where you pay per minute for being connected.
It syntax highlights
everything so threads aren't difficult to follow either way.
Yes they are. My news reader colour-codes quoted text, but to understand
you post I had to scroll to the bottom to see what you were replying to
then scroll back up to see your response. Posting after the quoted
material means that anyone with a decent news reader (and a lot of
people with horrible things which just about allow one to read news) can
run through a group by just hitting the space bar, only having to do
something else when replying.
Btw, I
prefer "topposting" since you don't have to scroll past what's already
been said in the thread.
That is why one snips material that is not relevant to the reply,
summarising if appropriate.
I'm really surprised though that noone has pointed out so far that
most compilers will have some kind of flag or directive to allow a
larger stack size which is the most likely wall you're running in to
(all this talk of standards and no real solutions).
The most likely solution is using malloc and this has been suggested.
Keith Thompson <ks***@mib.org> wrote in message
news:<ln************@nuthaus.mib.org>...


<snip>
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.
Nov 14 '05 #24

P: n/a
grv575 wrote:
Please use google groups to read news.
The absolute worst newsreader/news provider? Why?
Btw, I
prefer "topposting" since you don't have to scroll past what's already
been said in the thread.


If you want to participate in this newsgroup, you'll be advised to
follow the posting conventions. Many, like me, will killfile you if you
don't stop top-posting.

Search the web for the many, many arguments against top-posting.

Brian Rodenborn
Nov 14 '05 #25

P: n/a
gr****@hotmail.com (grv575) writes:
Please use google groups to read news. It syntax highlights
everything so threads aren't difficult to follow either way. Btw, I
prefer "topposting" since you don't have to scroll past what's already
been said in the thread.


The nearly universal convention of this newsgroup is to avoid
top-posting. There are good reasons for this, which you can see in
other responses to your article. The best reason, though, is that
it's the convention; if you top-post while everyone else bottom-posts,
your articles are going to be harder to read that everyone else's.

Even if you assume that bottom-posting is better than top-posting, a
mixture of the two is going to be worse than either one used
consistently.

And, of course, the concern about scrolling past what's already been
said is addressed by trimming anything that's not relevant to your
response. If you expect your readers to scroll past it, why post it
in the first place?

--
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.
Nov 14 '05 #26

P: n/a
*** Evil top-posting fixed ***

grv575 wrote:
Keith Thompson <ks***@mib.org> wrote
"Wei Li" <li*************@yahoo.com> writes:
... snip ...
I don't know how ANSI C says. But the stacksize of a program
in runtime is limited by Opterating System. So that C compiler
always doesn't give out an compile time error.

If you are on Linux, you can use "limit" command to show the
limits and use "limit stacksize 1000000" to change them. I think
your program will work OK
Wei Li: Please don't top-post.

Top-posting means writing your new material first, followed by the
quoted article to which you're responding. It makes it difficult
to follow the discussion, especially when (almost) everyone else
bottom-posts, as I'm doing there. (You should also trim anything
that's not relevant to your response, though in this case the
previous article was short enough that quoting the whole thing is
probably ok.)


Please use google groups to read news. It syntax highlights
everything so threads aren't difficult to follow either way. Btw,
I prefer "topposting" since you don't have to scroll past what's
already been said in the thread.


In comp.lang.c you are requested to bottom post (or interleave)
with proper snipping of irrelevant material. If you don't you may
well be plonked, which means that many people will never see any
of your posts. This tends to be non-productive.

Google groups is one of the slowest and awkwardest ways to read
news. Among other things many items never appear there, due to
foolish use of X-noarchive, and things that do appear have a delay
of several hours. On the other hand its archive is invaluable,
and it provides access for people without a newsreader (or behind
firewalls that prevent newserver access). This generally includes
library access, for example.
I'm really surprised though that noone has pointed out so far that
most compilers will have some kind of flag or directive to allow a
larger stack size which is the most likely wall you're running in to
(all this talk of standards and no real solutions).


Such compiler or system specific things are not portable, and are
thus off-topic here. Thus the proper reference is to a group
dealing with the specific system. There is not necessarily any
such thing as a stack.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Nov 14 '05 #27

P: n/a
grv575 top-posted:
Please use google groups to read news.

[etc.]

Didn't you see the requests to Wei Li that he not top-post? Why do you
think you merit an exemption?
Nov 14 '05 #28

P: n/a
Flash Gordon <sp**@flash-gordon.me.uk> wrote in message news:<j4************@brenda.flash-gordon.me.uk>...
On 1 Sep 2004 07:59:26 -0700
gr****@hotmail.com (grv575) wrote:
Please use google groups to read news.


Google is an on-line service that performs badly as a news reader. Many
people read groups off-line for a number of good reasons, including
dial-up connections where you pay per minute for being connected.


I've also used xnews quite a bit which also makes it irrelevant
whether the replies are top or bottom-posted. Top-posted text will be
visible first and it automatically skips quoted text (as an option).

The google comment could be change to 'use a decent threaded
newsreader' and it still wouldn't matter how someone chooses to reply
(assuming you thread the articles and read them as a group if you want
to get proper context).
Nov 14 '05 #29

P: n/a
Martin Ambuhl <ma*****@earthlink.net> wrote in message news:<2p************@uni-berlin.de>...
grv575 top-posted:
Please use google groups to read news.

[etc.]

Didn't you see the requests to Wei Li that he not top-post? Why do you
think you merit an exemption?


Thanks for the dictatorial reply. If it's in the comp.lang.c faq then
that's fine, but what gives you or the previous poster any moderator
privledges?
Nov 14 '05 #30

P: n/a
CBFalconer <cb********@yahoo.com> wrote in message news:<41***************@yahoo.com>...
Google groups is one of the slowest and awkwardest ways to read
news. Among other things many items never appear there, due to
foolish use of X-noarchive, and things that do appear have a delay
of several hours. On the other hand its archive is invaluable,
and it provides access for people without a newsreader (or behind
firewalls that prevent newserver access). This generally includes
library access, for example.


I don't see why everyone hates google groups so much (aside from the
X-noarchive header buisness) as a newsreader. It's accessible
anywhere, and instead of using the spacebar to read all the messages,
using the scroll button on the mouse works just as nicely.
Nov 14 '05 #31

P: n/a
Flash Gordon <sp**@flash-gordon.me.uk> wrote in message news:<j4************@brenda.flash-gordon.me.uk>...
The most likely solution is using malloc and this has been suggested.


Or increasing the stacksize.
Or using non-local storage (a global variable for example).
Nov 14 '05 #32

P: n/a
On 3 Sep 2004 06:04:57 -0700
gr****@hotmail.com (grv575) wrote:
Martin Ambuhl <ma*****@earthlink.net> wrote in message
news:<2p************@uni-berlin.de>...
grv575 top-posted:
Please use google groups to read news.

[etc.]

Didn't you see the requests to Wei Li that he not top-post? Why do
you think you merit an exemption?


Thanks for the dictatorial reply. If it's in the comp.lang.c faq then
that's fine, but what gives you or the previous poster any moderator
privledges?


Since you are a fan of Google Groups, here is a quote from their posting
FAQ (http://groups.google.com/googlegroup...ing_style.html) :

| Summarize what you are following up.
|
| When you follow up an existing article, Google Groups includes the
| full article in quotes, with the cursor at the top of the article.
| Tempting though it is to just start typing your message, please STOP
| and do two things first. Look at the quoted text and delete parts that
| are irrelevant. Then, go to the BOTTOM of the article and start typing
| there. Doing this makes it much easier for your readers to get through
| your post. They'll have a reminder of the relevant text before your
| comment, but won't have to re-read the entire article. And if your
| reply appears on a site before the original article does, they'll get
| the gist of what you're talking about.

The emphasis (putting STOP and BOTTOM in upper case) is Googles, not
mine.

This is just Googles interpretations of the normal Usenet conventions.
There is also an RFC that covers it, but the RFC is not as easy to read
as the above.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.
Nov 14 '05 #33

P: n/a
On 3 Sep 2004 06:00:41 -0700
gr****@hotmail.com (grv575) wrote:
Flash Gordon <sp**@flash-gordon.me.uk> wrote in message
news:<j4************@brenda.flash-gordon.me.uk>...
On 1 Sep 2004 07:59:26 -0700
gr****@hotmail.com (grv575) wrote:
Please use google groups to read news.
Google is an on-line service that performs badly as a news reader.
Many people read groups off-line for a number of good reasons,
including dial-up connections where you pay per minute for being
connected.


I've also used xnews quite a bit which also makes it irrelevant
whether the replies are top or bottom-posted. Top-posted text will be
visible first and it automatically skips quoted text (as an option).


One that would be a real pain for me if it was enabled, since on
returning to a thread I always have to scan the text that is being
replied to in order to get context before reading the first reply.
The google comment could be change to 'use a decent threaded
newsreader' and it still wouldn't matter how someone chooses to reply
(assuming you thread the articles and read them as a group if you want
to get proper context).


You get absolutely no context from a post that has not yet reached your
server, therefor you have to post on the assumption that some of the
audience will not see the article you are responding to prior to seeing
your reply. In this case the comment I made else where about having to
scroll up and down being a pain still applies. If someone does what you
suggest then it is even worse if they have not just read the previous
message since they have to unhide the quoted text, scroll down whilst
reading then scroll back up to start again. However, many excellent
threaded news readers do not hide quoted text for the very good reason
that if posts are done properly there is no need to hide quoted text.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.
Nov 14 '05 #34

P: n/a
On 3 Sep 2004 06:24:15 -0700
gr****@hotmail.com (grv575) wrote:
Flash Gordon <sp**@flash-gordon.me.uk> wrote in message
news:<j4************@brenda.flash-gordon.me.uk>...
The most likely solution is using malloc and this has been
suggested.


Or increasing the stacksize.
Or using non-local storage (a global variable for example).


I said the most likely solution, not the only possible solution.

I know of real systems still in use today where you have a fixed
global+static data limit of 64K but you can get as much memory as is
available on the machine using malloc without changing any options. I
did not have a C implementation on the system in question, but since it
was a limit in the OS it is unlikely that any C compiler would have side
stepped it.

Using malloc also means you can trap the error if you don't have enough
memory and either handle the situation (possibly by using temporary
files) or give the user a nice friendly report on the problem.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.
Nov 14 '05 #35

P: n/a
gr****@hotmail.com (grv575) writes:
CBFalconer <cb********@yahoo.com> wrote in message
news:<41***************@yahoo.com>...
Google groups is one of the slowest and awkwardest ways to read
news. Among other things many items never appear there, due to
foolish use of X-noarchive, and things that do appear have a delay
of several hours. On the other hand its archive is invaluable,
and it provides access for people without a newsreader (or behind
firewalls that prevent newserver access). This generally includes
library access, for example.


I don't see why everyone hates google groups so much (aside from the
X-noarchive header buisness) as a newsreader. It's accessible
anywhere, and instead of using the spacebar to read all the messages,
using the scroll button on the mouse works just as nicely.


If it works for you, that's great; we have no objection to your using
it. But whichever newsreader you use, you need to remember that not
everyone is going to use the same one. The conventions we use here
have evolved over many years as the best way to make sure everyone's
articles are as legible as possible.

--
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.
Nov 14 '05 #36

P: n/a
grv575 wrote:
CBFalconer <cb********@yahoo.com> wrote:
Google groups is one of the slowest and awkwardest ways to read
news. Among other things many items never appear there, due to
foolish use of X-noarchive, and things that do appear have a delay
of several hours. On the other hand its archive is invaluable,
and it provides access for people without a newsreader (or behind
firewalls that prevent newserver access). This generally includes
library access, for example.


I don't see why everyone hates google groups so much (aside from
the X-noarchive header buisness) as a newsreader. It's accessible
anywhere, and instead of using the spacebar to read all the
messages, using the scroll button on the mouse works just as nicely.


It is not a matter of hate, it is a matter of slowness and
functions. Google fouls threading. To use it you have to have
various things enabled in the browser, which increases the
possibility of intrusion. You can't use it in an off-line mode.
The same thing applies to any web-based newsreader. I use my ISPs
web based access purely to examine the list and weed out the spam
on my email (unless I am away from home). I can format my replies
as I wish, conveniently grab and paste anything, etc. when using a
proper newsreader.

--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Nov 14 '05 #37

P: n/a
grv575 wrote:
I don't see why everyone hates google groups so much (aside from the
X-noarchive header buisness) as a newsreader. It's accessible
anywhere, and instead of using the spacebar to read all the messages,
using the scroll button on the mouse works just as nicely.


<meta-topical?>

These comments are about the primary service, I haven't tried Beta.

1. There's no way to mark messages as read.

2. It takes hours to have posts show up even on their system, let alone
the rest of the world.

3. It conflates dissimilar threads that happen to have the same subject.

4. Changing the subject starts a new thread.

5. No killfile or filtering ability.
The bottom line is, groups.google is a pretty good archive and handy to
have. As a newsreading system, it sucks. There's no good reason to use
it except in the most dire circumstances. The free news server at
http://news.individual.net is a far better product. Decent free
newsreaders are available by the dozen.

</meta-topical?>

Brian Rodenborn
Nov 14 '05 #38

This discussion thread is closed

Replies have been disabled for this discussion.