how to create an array for 15000 integers?

[David]

I need to do an array with around 15000 integers in it.
I have declared it as unsigned letter[13000];
But the compiler is saying that this is too much.
How can I create an array for 15000 integers?

I am using "Miracle C compiler".

This is the error i am recieving:

"c:\documents and settings\david\desktop\asdasdasdasdasdasdasdad22.c :
line 6: too many locals declared
'unsigned letter[15000]'
aborting compile"

[wahaha]

This will depend on how many memory your desktop has. Assume you have
enough memory, you can write:

unsigned int *letter;
if ((letter = malloc(15000 *sizeof(int))) == NULL)
return -1;
"David дµÀ£º
"

I need to do an array with around 15000 integers in it.
I have declared it as unsigned letter[13000];
But the compiler is saying that this is too much.
How can I create an array for 15000 integers?

I am using "Miracle C compiler".

This is the error i am recieving:

"c:\documents and settings\david\desktop\asdasdasdasdasdasdasdad22.c :
line 6: too many locals declared
'unsigned letter[15000]'
aborting compile"

[Christopher Benson-Manica]

wahaha <zh***********@gmail.comwrote:

This will depend on how many memory your desktop has. Assume you have
enough memory, you can write:

A. Now you know.
Q. Why is top-posting bad?

unsigned int *letter;
if ((letter = malloc(15000 *sizeof(int))) == NULL)

if( (letter=malloc(15000*sizeof(*letter))) == NULL )

return -1;

Not my first choice for error handling.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Keith Thompson]

"wahaha" <zh***********@gmail.comwrites:

This will depend on how many memory your desktop has. Assume you have
enough memory, you can write:

unsigned int *letter;
if ((letter = malloc(15000 *sizeof(int))) == NULL)
return -1;

letter is a pointer to unsigned int, but you use sizeof(int). Yes,
they're guaranteed to be the same, but there's no point in depending
on that. In fact, the preferred way to write that is:

if ((letter = malloc(15000 * sizeof *letter)) == NULL)

And what is the "return -1" supposed to accomplish? That makes sense
only if the code is in a function that returns some integer (or at
least arithmetic) type. If you're assuming the code is within main(),
then (a) that's a bad assumption, and (b) returning -1 from main() is
not portable.

And please don't top-post. See the following:

http://www.caliburn.nl/topposting.html
http://www.cpax.org.uk/prg/writings/topposting.php

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

[Bill Reid]

David <da***********@gmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...

I need to do an array with around 15000 integers in it.
I have declared it as unsigned letter[13000];
But the compiler is saying that this is too much.
How can I create an array for 15000 integers?

I am using "Miracle C compiler".

This is the error i am recieving:

"c:\documents and settings\david\desktop\asdasdasdasdasdasdasdad22.c :
line 6: too many locals declared
'unsigned letter[15000]'
aborting compile"

Maybe try declaring it as a global array? Move it out of a
function body and see what happens...

---
William Ernest Reid

[David T. Ashley]

"David" <da***********@gmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...

>I need to do an array with around 15000 integers in it.
I have declared it as unsigned letter[13000];
But the compiler is saying that this is too much.
How can I create an array for 15000 integers?

I am using "Miracle C compiler".

This is the error i am recieving:

"c:\documents and settings\david\desktop\asdasdasdasdasdasdasdad22.c :
line 6: too many locals declared
'unsigned letter[15000]'
aborting compile"

Make it static or global.

Or, dynamically allocate it.

With a typical compiler, local variables are stored in what is called a
"stack frame".

http://en.wikipedia.org/wiki/Call_stack

Typically, there are at least a couple of reasons why the size of the stack
and each individual stack frame is limited. The most pressing reason is
often that to retrieve and store values to the stack frame, machine
instructions that are stack-relative are used. These instructions typically
embed a stack-pointer relative offset into the instruction, and the
instruction encoding imposes a limit on how big the offsets can be.
Somewhere around 4,000 bytes (11 or 12 bits) strikes me as typical for a
desktop machine. 15,000 integers is quite a large array.

Most programmers think twice when something of storage class automatic that
has more than a couple dozen elements.

[jacob navia]

David wrote:

I need to do an array with around 15000 integers in it.
I have declared it as unsigned letter[13000];
But the compiler is saying that this is too much.
How can I create an array for 15000 integers?

I am using "Miracle C compiler".

This is the error i am recieving:

"c:\documents and settings\david\desktop\asdasdasdasdasdasdasdad22.c :
line 6: too many locals declared
'unsigned letter[15000]'
aborting compile"

You are using Miracl C, what is a DOS C ompiler. Under DOS you just
can't do anything big like that, and specially the stack is a precious
ressource to be used with utmost care.

You have two possibilities:
1) Go on use an obsolete compiler/OS and spend a lot of time
programming around its limitations; This *could* have been
OK in 1990, it is quite senseless now

2) Use a 32 bit OS for your programming: Linux/windows, whatever.

[Richard Bos]

jacob navia <ja***@jacob.remcomp.frwrote:

David wrote:

I need to do an array with around 15000 integers in it.
I have declared it as unsigned letter[13000];
But the compiler is saying that this is too much.
How can I create an array for 15000 integers?

I am using "Miracle C compiler".

You are using Miracl C, what is a DOS C ompiler.

_Which_ is a DOS compiler.

Under DOS you just can't do anything big like that,

Bullshit. Under Miracle C you may not be able to do that, but that
doesn't mean that there aren't any C implementations that do let you use
this array. In fact, I'd be surprised if the one I used to use didn't.

1) Go on use an obsolete compiler/OS and spend a lot of time
programming around its limitations; This *could* have been
OK in 1990, it is quite senseless now

Tell that to the MS-DOS program that's still running the back-end of our
A2 full-colour scanner.

Richard

[jacob navia]

Richard Bos wrote:

jacob navia <ja***@jacob.remcomp.frwrote:

>>David wrote:

>>>I need to do an array with around 15000 integers in it.
I have declared it as unsigned letter[13000];
But the compiler is saying that this is too much.
How can I create an array for 15000 integers?

I am using "Miracle C compiler".

You are using Miracl C, what is a DOS C ompiler.

_Which_ is a DOS compiler.

Gosh I can't get that right...

Thanks

>

>>Under DOS you just can't do anything big like that,

Bullshit. Under Miracle C you may not be able to do that, but that
doesn't mean that there aren't any C implementations that do let you use
this array. In fact, I'd be surprised if the one I used to use didn't.

>>1) Go on use an obsolete compiler/OS and spend a lot of time
programming around its limitations; This *could* have been
OK in 1990, it is quite senseless now

Tell that to the MS-DOS program that's still running the back-end of our
A2 full-colour scanner.

USING MS-DOS programs, and even developing embedded software in MSDOS
is OK. But LEARNING C with MSDOS?

[Richard Heathfield]

jacob navia said:

<snip>

USING MS-DOS programs, and even developing embedded software in MSDOS
is OK. But LEARNING C with MSDOS?

Sure, why not?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[CBFalconer]

jacob navia wrote:

Richard Bos wrote:

.... snip ...

>>
Tell that to the MS-DOS program that's still running the back-end
of our A2 full-colour scanner.

USING MS-DOS programs, and even developing embedded software in
MSDOS is OK. But LEARNING C with MSDOS?

This is more likely to produce good habits, assuming an appropriate
C compiler system, than using a non-standard systems which
promulgates various non-portable extensions, and doesn't provide an
easy and obvious way to inhibit all of them. In particular the
DJGPP system will do just fine under DOS.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[jacob navia]

CBFalconer wrote:

jacob navia wrote:

>>Richard Bos wrote:

... snip ...

>>>Tell that to the MS-DOS program that's still running the back-end
of our A2 full-colour scanner.

USING MS-DOS programs, and even developing embedded software in
MSDOS is OK. But LEARNING C with MSDOS?

This is more likely to produce good habits, assuming an appropriate
C compiler system, than using a non-standard systems which
promulgates various non-portable extensions, and doesn't provide an
easy and obvious way to inhibit all of them. In particular the
DJGPP system will do just fine under DOS.

Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models", making the difference between near and far pointers,
all that aren't any extensions of course.

Yeah, of course

[Richard Heathfield]

jacob navia said:

CBFalconer wrote:

>jacob navia wrote:

>>>Richard Bos wrote:

... snip ...

>>>>Tell that to the MS-DOS program that's still running the back-end
of our A2 full-colour scanner.

USING MS-DOS programs, and even developing embedded software in
MSDOS is OK. But LEARNING C with MSDOS?

This is more likely to produce good habits, assuming an appropriate
C compiler system, than using a non-standard systems which
promulgates various non-portable extensions, and doesn't provide an
easy and obvious way to inhibit all of them. In particular the
DJGPP system will do just fine under DOS.

Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models",

Why would you need to do that just to learn C? The language knows nothing of
such things.

making the difference between near and far pointers,

Why would you need to do that just to learn C? The language knows nothing of
such things.

all that aren't any extensions of course.

Yeah, of course

Yes, of course. Any conforming C implementation, plus a reasonable source
editor, will do. Who cares what platform it's on? DOS is fine for such a
purpose.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[jacob navia]

Richard Heathfield wrote:

jacob navia said:

>>CBFalconer wrote:

>>>jacob navia wrote:
Richard Bos wrote:
... snip ...
>Tell that to the MS-DOS program that's still running the back-end
>of our A2 full-colour scanner.

USING MS-DOS programs, and even developing embedded software in
MSDOS is OK. But LEARNING C with MSDOS?
This is more likely to produce good habits, assuming an appropriate
C compiler system, than using a non-standard systems which
promulgates various non-portable extensions, and doesn't provide an
easy and obvious way to inhibit all of them. In particular the
DJGPP system will do just fine under DOS.

Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models",

Why would you need to do that just to learn C? The language knows nothing of
such things.

You can't program on DOS without knowing those things.
Apparently you have forgotten how it was, or never used it.
I do remember how it was...

>

>>making the difference between near and far pointers,

Why would you need to do that just to learn C? The language knows nothing of
such things.

Impossible to avoid them if you program under DOS.

[David T. Ashley]

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45**********************@news.orange.fr...

>
You can't program on DOS without knowing those things.
Apparently you have forgotten how it was, or never used it.
I do remember how it was...

10 or more years ago that definitely was the case (tiny, compact, large,
huge, etc. memory models), but now with a modern machine under Windows isn't
the notion of memory model all gone?

I use Visual C++, and I don't remember a memory model setting (these days).

???

[Coos Haak]

Op Thu, 14 Dec 2006 11:52:19 -0500 schreef David T. Ashley:

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45**********************@news.orange.fr...

>>
You can't program on DOS without knowing those things.
Apparently you have forgotten how it was, or never used it.
I do remember how it was...

10 or more years ago that definitely was the case (tiny, compact, large,
huge, etc. memory models), but now with a modern machine under Windows isn't
the notion of memory model all gone?

I use Visual C++, and I don't remember a memory model setting (these days).

???

Windows (32 bit) isn't DOS (16 bit), and the models here mentions matter.
--
Coos

[jacob navia]

David T. Ashley a écrit :

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45**********************@news.orange.fr...

>>You can't program on DOS without knowing those things.
Apparently you have forgotten how it was, or never used it.
I do remember how it was...

10 or more years ago that definitely was the case (tiny, compact, large,
huge, etc. memory models), but now with a modern machine under Windows isn't
the notion of memory model all gone?

I use Visual C++, and I don't remember a memory model setting (these days).

???

There isn't any more. For beginners this is better since
all the complexities of 3 types of pointers are gone.

Actually, for non-beginners too :-)

[Simon Biber]

jacob navia wrote:

CBFalconer wrote:

>This is more likely to produce good habits, assuming an appropriate
C compiler system, than using a non-standard systems which
promulgates various non-portable extensions, and doesn't provide an
easy and obvious way to inhibit all of them. In particular the
DJGPP system will do just fine under DOS.

Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models", making the difference between near and far pointers,
all that aren't any extensions of course.

Yeah, of course

If you use the system that Chuck recommended under DOS, DJGPP, then you
won't be dealing with any tiny/compact/medium/large "memory models" or
any different types of pointers. DJGPP programs run in a 32-bit
environment using the go32 DOS extender.

--
Simon.

[jacob navia]

Simon Biber a écrit :

jacob navia wrote:

>CBFalconer wrote:

>>This is more likely to produce good habits, assuming an appropriate
C compiler system, than using a non-standard systems which
promulgates various non-portable extensions, and doesn't provide an
easy and obvious way to inhibit all of them. In particular the
DJGPP system will do just fine under DOS.

Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models", making the difference between near and far pointers,
all that aren't any extensions of course.

Yeah, of course

If you use the system that Chuck recommended under DOS, DJGPP, then you
won't be dealing with any tiny/compact/medium/large "memory models" or
any different types of pointers. DJGPP programs run in a 32-bit
environment using the go32 DOS extender.

Right. You agree then with me that MSDOS is not really for learning,
what I was saying.

DJGPP is NOT dos, since, as you point out,

DJGPP programs run in a 32-bit environment using the go32 DOS
extender

This is not the case of Miracl C, the subject of this thread.

jacob

[CBFalconer]

jacob navia wrote:

CBFalconer wrote:

>jacob navia wrote:

>>Richard Bos wrote:

... snip ...

>>>
Tell that to the MS-DOS program that's still running the back-end
of our A2 full-colour scanner.

USING MS-DOS programs, and even developing embedded software in
MSDOS is OK. But LEARNING C with MSDOS?

This is more likely to produce good habits, assuming an appropriate
C compiler system, than using a non-standard systems which
promulgates various non-portable extensions, and doesn't provide an
easy and obvious way to inhibit all of them. In particular the
DJGPP system will do just fine under DOS.

Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models", making the difference between near and far pointers,
all that aren't any extensions of course.

What memory models? What 'near' and 'far' pointers? Those are
non-standard, and don't appear in DJGPP. You are obviously
unfamiliar with what 'standard C' implies. My default compile time
flags under DJGPP/gcc are:

-W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal -gstabs+
-O1

and I have a high expectation of portability.

(Richard Heathfield goes further)

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[CBFalconer]

jacob navia wrote:

Richard Heathfield wrote:

>jacob navia said:

.... snip ...

>>>
Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models",

Why would you need to do that just to learn C? The language knows
nothing of such things.

You can't program on DOS without knowing those things.
Apparently you have forgotten how it was, or never used it.
I do remember how it was...

Amazing ignorance. I haven't even thought about such things for
quite a few years. I suggest you get and use DJGPP.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>jacob navia said:

<snip>

>>>
Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models",

Why would you need to do that just to learn C? The language knows nothing
of such things.

You can't program on DOS without knowing those things.

Yes, you can. I did.

Apparently you have forgotten how it was, or never used it.
I do remember how it was...

>>

>>>making the difference between near and far pointers,

Why would you need to do that just to learn C? The language knows nothing
of such things.

Impossible to avoid them if you program under DOS.

Wrong. DOS hosts several conforming C compilers.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

CBFalconer said:

jacob navia wrote:

>Richard Heathfield wrote:

>>jacob navia said:

... snip ...

>>>>
Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models",

Why would you need to do that just to learn C? The language knows
nothing of such things.

You can't program on DOS without knowing those things.
Apparently you have forgotten how it was, or never used it.
I do remember how it was...

Amazing ignorance. I haven't even thought about such things for
quite a few years.

And even when you thought about them, you didn't need them for C
programming. If Mr Navia thinks a knowledge of memory models or near/far
pointers is necessary for writing C programs on a machine that just happens
to run MS-DOS, he's mistaken.

I suggest you get and use DJGPP.

Yes. Or, of course, Microsoft C, or Turbo C, or indeed any conforming
implementation of C that works on MS-DOS.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

Simon Biber said:

<snip>

If you use the system that Chuck recommended under DOS, DJGPP, then you
won't be dealing with any tiny/compact/medium/large "memory models" or
any different types of pointers.

Nor will you if you use any other conforming C implementation, since C knows
nothing of such things.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Simon Biber]

jacob navia wrote:

Simon Biber a écrit :

>If you use the system that Chuck recommended under DOS, DJGPP, then
you won't be dealing with any tiny/compact/medium/large "memory
models" or any different types of pointers. DJGPP programs run in a
32-bit environment using the go32 DOS extender.

Right. You agree then with me that MSDOS is not really for learning,
what I was saying.

I agree that old 16-bit C compilers for MS-DOS are not good for learning
on. They tend to be buggy and not fully compliant to C89 let alone C99.

DJGPP is NOT dos, since, as you point out,

DJGPP programs run in a 32-bit environment using the go32 DOS
extender

Let's not get into a silly and completely off-topic discussion of what
is DOS and what is not DOS. Programs compiled with DJGPP work on pure
MS-DOS as well as within the Windows NTVDM emulator (and other emulators
like DOSBox).

You just need the supplied CWSDPMI system, which is silently loaded when
your run the program, much like the MSVCRT.DLL or libc.so files are on
more advanced operating systems.

--
Simon.

[Richard Heathfield]

Simon Biber said:

<snip>

I agree that old 16-bit C compilers for MS-DOS are not good for learning
on. They tend to be buggy and not fully compliant to C89

That has not been my experience. There are enough compilers that are
sufficiently conforming for the purpose. I'm not claiming DOS would be my
first choice for learning C (although in fact it is the platform on which I
did learn it!), but it's good enough.

let alone C99.

Well, that's certainly true, but who uses C99? :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Bos]

jacob navia <ja***@jacob.remcomp.frwrote:

CBFalconer wrote:

jacob navia wrote:

>Richard Bos wrote:

>>Tell that to the MS-DOS program that's still running the back-end
of our A2 full-colour scanner.

USING MS-DOS programs, and even developing embedded software in
MSDOS is OK. But LEARNING C with MSDOS?

This is more likely to produce good habits, assuming an appropriate
C compiler system, than using a non-standard systems which
promulgates various non-portable extensions, and doesn't provide an
easy and obvious way to inhibit all of them. In particular the
DJGPP system will do just fine under DOS.

Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models", making the difference between near and far pointers,

You make it more and more obvious that your experience with advanced
MS-DOS C implementations - DJGPP, in particular - is limited to having
once stood downwind of one.
For your futile information, none of what you mention need be used if
you compile with DJGPP.

Richard

[Richard Heathfield]

Richard Bos said:

jacob navia <ja***@jacob.remcomp.frwrote:

>Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models", making the difference between near and far pointers,

You make it more and more obvious that your experience with advanced
MS-DOS C implementations - DJGPP, in particular - is limited to having
once stood downwind of one.
For your futile information, none of what you mention need be used if
you compile with DJGPP.

Nor with Turbo C, nor with Microsoft C...

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[CBFalconer]

Richard Heathfield wrote:

Simon Biber said:

<snip>

>I agree that old 16-bit C compilers for MS-DOS are not good for
learning on. They tend to be buggy and not fully compliant to C89

That has not been my experience. There are enough compilers that
are sufficiently conforming for the purpose. I'm not claiming DOS
would be my first choice for learning C (although in fact it is the
platform on which I did learn it!), but it's good enough.

I use Turboc (2.01 I believe) to check that I haven't made
unwarranted assumptions about the sizeof(int). Available free from
the Borland museum. Now 17 years old.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[ais523]

jacob navia wrote:

Richard Heathfield wrote:

jacob navia said:

>making the difference between near and far pointers,

Why would you need to do that just to learn C? The language knows nothing of
such things.

Impossible to avoid them if you program under DOS.

Not true. I learnt C on DOS, using the C mode of the Borland C++
compiler. (Luckily, it's sufficiently well behaved to identify a file
ending .c as C rather than C++.) If you set the memory model to 'large'
(no need to change it from that setting, ever, while you're learning),
the pointers are all set to 'far' by default and the whole
implementation can be perfectly conforming to C89 with a couple of
extra compiler flags (which even change the implementation keyword
'far' to '__far' to prevent infringing on the user namespace). The
other memory models and near pointers can both be treated as
extensions, for use when you want to write smaller or more
memory-efficient programs; in this sense it's no different from the
extensions of other implementations.
--
ais523

[Default User]

Richard Heathfield wrote:

Simon Biber said:

<snip>

I agree that old 16-bit C compilers for MS-DOS are not good for
learning on. They tend to be buggy and not fully compliant to C89

That has not been my experience. There are enough compilers that are
sufficiently conforming for the purpose. I'm not claiming DOS would
be my first choice for learning C (although in fact it is the
platform on which I did learn it!), but it's good enough.

I, like many I'm sure, cut my teeth on good old Turbo C. On the whole,
other than the somewhat clunky editor with the IDE, it was a pretty
good system.

I particularly liked the manual that came with it, the form was similar
to man pages, except that they didn't group functions. I prefered that.
I used the manual for a long time after I stopped using the compiler,
to the point where it completely fell apart.

Brian

[Randy Howard]

jacob navia wrote
(in article <45**********************@news.orange.fr>):

Richard Heathfield wrote:

>jacob navia said:

>>CBFalconer wrote:

jacob navia wrote:
Richard Bos wrote:
>

... snip ...
>Tell that to the MS-DOS program that's still running the back-end
>of our A2 full-colour scanner.
>
USING MS-DOS programs, and even developing embedded software in
MSDOS is OK. But LEARNING C with MSDOS?
This is more likely to produce good habits, assuming an appropriate
C compiler system, than using a non-standard systems which
promulgates various non-portable extensions, and doesn't provide an
easy and obvious way to inhibit all of them. In particular the
DJGPP system will do just fine under DOS.
Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models",

Why would you need to do that just to learn C? The language knows nothing
of
such things.

You can't program on DOS without knowing those things.

You absolutely can.

Apparently you have forgotten how it was, or never used it.
I do remember how it was...

I remember how it was long before there was DOS. You're full of
it. writing tricky TSR code under DOS is one thing. Writing
standard C code is quite another, and very doable without such
knowledge.

>>making the difference between near and far pointers,

Why would you need to do that just to learn C? The language knows nothing
of
such things.

Impossible to avoid them if you program under DOS.

Totally false.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[jacob navia]

Richard Bos a écrit :

jacob navia <ja***@jacob.remcomp.frwrote:

>>CBFalconer wrote:

>>>jacob navia wrote:
Richard Bos wrote:

>Tell that to the MS-DOS program that's still running the back-end
>of our A2 full-colour scanner.

USING MS-DOS programs, and even developing embedded software in
MSDOS is OK. But LEARNING C with MSDOS?

This is more likely to produce good habits, assuming an appropriate
C compiler system, than using a non-standard systems which
promulgates various non-portable extensions, and doesn't provide an
easy and obvious way to inhibit all of them. In particular the
DJGPP system will do just fine under DOS.

Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models", making the difference between near and far pointers,

You make it more and more obvious that your experience with advanced
MS-DOS C implementations - DJGPP, in particular - is limited to having
once stood downwind of one.
For your futile information, none of what you mention need be used if
you compile with DJGPP.

Richard

This thread (I repeat) was about MIRACL C.

OK?

I am referring to THAT environment guys, and I do not care
about the wonderful DJGPP since the original poster
doesn't use it!

I knew everything about DOS extenders, when I used them.
I have forgotten everything about thme since I do not use
them any more. But this is off topic for this thread.

To refresh your minds here is the original question I
was answering to:

< QUOTE >
I need to do an array with around 15000 integers in it.
I have declared it as unsigned letter[13000];
But the compiler is saying that this is too much.
How can I create an array for 15000 integers?

I am using "Miracle C compiler".

This is the error i am recieving:

"c:\documents and settings\david\desktop\asdasdasdasdasdasdasdad22.c :
line 6: too many locals declared
'unsigned letter[15000]'
aborting compile"

< END QUOTE>

MANY problems like this will appear when you use PLAIN OLD MSDOS
as this user is seeing. Those questions are difficult to
answer for a beginner so I recommended a modern environment where
those problems do not appear immediately.

This problems WILL appear eventually since if you replace 15000
with 15000000000 then the 32 bit implementation will
have the same problem, but when the student needs
15000000000 then it is (hopefully) more advanced :-)

[Mark McIntyre]

On Sat, 16 Dec 2006 21:38:11 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>This thread (I repeat) was about MIRACL C.

Repeat all you like, but this thread was about "how to create an array
for 15000 integers?".

>"c:\documents and settings\david\desktop\asdasdasdasdasdasdasdad22.c :

MANY problems like this will appear when you use PLAIN OLD MSDOS

The line above your comment proves that he is *not* using plain old
MSDOS. However I suspect you will disagree about that so ILTAAEFTR.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[CBFalconer]

jacob navia wrote:

>

.... snip ...

>
I need to do an array with around 15000 integers in it.
I have declared it as unsigned letter[13000];
But the compiler is saying that this is too much.
How can I create an array for 15000 integers?

Either declare it as static, or as file scope, or assign the space
with malloc.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Tom]

I had a similar problem before and the good folks in here listened to
my silliness about ram disks and then one realized my error and
directed me towards malloc(). When you use malloc() you do not exceed
your program's image size limitations and other limits as well. I now
load various data files in their entirety and the speed enhancement of
re-reading the data repeatedly is sweet. For example: 20+ years of US
T-bill ticks with contract tags is one file of 181,000+ KB of data
that is opened at the same time as a statistical data file with a size
of 159,000+ KB. Both of these files are composed of binary structures
and are treated like huge arrays with simple indexing. malloc() works
miracles at times. :)

[Richard Bos]

jacob navia <ja***@jacob.remcomp.frwrote:

Richard Bos a écrit :

jacob navia <ja***@jacob.remcomp.frwrote:

>CBFalconer wrote:

jacob navia wrote:

Richard Bos wrote:

Tell that to the MS-DOS program that's still running the back-end
of our A2 full-colour scanner.

USING MS-DOS programs, and even developing embedded software in
MSDOS is OK. But LEARNING C with MSDOS?

This is more likely to produce good habits, assuming an appropriate
C compiler system, than using a non-standard systems which
promulgates various non-portable extensions, and doesn't provide an
easy and obvious way to inhibit all of them. In particular the
DJGPP system will do just fine under DOS.

Mmmm... grasping the difference between the tiny/compact/medium/large
"memory models", making the difference between near and far pointers,

You make it more and more obvious that your experience with advanced
MS-DOS C implementations - DJGPP, in particular - is limited to having
once stood downwind of one.
For your futile information, none of what you mention need be used if
you compile with DJGPP.

This thread (I repeat) was about MIRACL C.

Even if that were true - which it isn't - that would not be any excuse
for you to make sweeping, false, and off-topic generalisations about the
platform that implementation runs on. Which is precisely what you did in
your very first post to this thread.

Richard

[jacob navia]

Richard Bos a écrit :

jacob navia <ja***@jacob.remcomp.frwrote:

>>This thread (I repeat) was about MIRACL C.

Even if that were true - which it isn't -

The original poster wrote

I am using "Miracle C compiler".

But obviously you can't read.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Richard Bos a écrit :

>jacob navia <ja***@jacob.remcomp.frwrote:

>>>This thread (I repeat) was about MIRACL C.

Even if that were true - which it isn't -

The original poster wrote

I am using "Miracle C compiler".

But obviously you can't read.

Obviously the fact that the original poster mentioned that he's using
a particular compiler does not necessarily imply that the thread is,
or should be, about that compiler.

The original poster also wrote (or his news software wrote on his
behalf):

Newsgroups: comp.lang.c

We may reasonably infer from this that the thread is about C.

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

[kjm.2me]

I think it would be possible, if make your array with a file.

At first divide the array to some parts.

And make sure only a using bit of the array loaded to a main memory.

I hope that everything will be fine....

Jong-Min Kim.

[CBFalconer]

"kj*****@gmail.com" wrote:

>
I think it would be possible, if make your array with a file.

At first divide the array to some parts.
And make sure only a using bit of the array loaded to a main memory.

Incomprehensible. See the following links.

--
If you want to post a followup via groups.google.com, ensure
you quote enough for the article to make sense. Google is only
a poor interface to usenet. There is no reason to assume your
readers can, or ever will, see any previous articles.
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[jacob navia]

Keith Thompson wrote:

jacob navia <ja***@jacob.remcomp.frwrites:

>>Richard Bos a écrit :

>>>jacob navia <ja***@jacob.remcomp.frwrote:

This thread (I repeat) was about MIRACL C.

Even if that were true - which it isn't -

The original poster wrote

I am using "Miracle C compiler".

But obviously you can't read.

Obviously the fact that the original poster mentioned that he's using
a particular compiler does not necessarily imply that the thread is,
or should be, about that compiler.

The original poster also wrote (or his news software wrote on his
behalf):

Newsgroups: comp.lang.c

We may reasonably infer from this that the thread is about C.

Since Miracl C is a real mode DOS compiler, I answered

"You are using Miracl C, what is a DOS C ompiler. Under DOS you just
can't do anything big like that, and specially the stack is a precious
ressource to be used with utmost care. "

What is wrong with that answer?

Nothing but the desire of all "regulars" of having fun
each time I write something, in destroying it,
making lies about what I said, etc.

Look at this guy: Mr "Bos":

"... to make sweeping, false, and off-topic generalisations about the
platform that implementation runs on"

So, telling the user that the "stack is a precious ressource
to be used with utmost care" under MSDOS is a "sweeping, false and
off topic generalization".

WHAT THE HELL IS GOING ON HERE ?????

[Random832]

2006-12-19 <ln************@nuthaus.mib.org>,
Keith Thompson wrote:

jacob navia <ja***@jacob.remcomp.frwrites:

>Richard Bos a écrit :

>>jacob navia <ja***@jacob.remcomp.frwrote:
This thread (I repeat) was about MIRACL C.
Even if that were true - which it isn't -

The original poster wrote

> I am using "Miracle C compiler".

But obviously you can't read.

Obviously the fact that the original poster mentioned that he's using
a particular compiler does not necessarily imply that the thread is,
or should be, about that compiler.

The original poster also wrote (or his news software wrote on his
behalf):

Newsgroups: comp.lang.c

We may reasonably infer from this that the thread is about C.

In all fairness, on a compiler that adheres to the bare minimum object
size limits (as many DOS compilers do), if you have an array of 15000
integers [and, we'll assume that sizeof(int) is at least 2, since though
technically legal it's VERY rare for it to be 1], you've got room for
precious little else anywhere, let alone "on the stack" (ObTranslation:
STACK = STorage, AutomatiC duration [can't think of anything with a K]).

[Richard Heathfield]

Random832 said:

<snip>

(ObTranslation:
STACK = STorage, AutomatiC duration [can't think of anything with a K]).

Keith? :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Bebert]

CBFalconer wrote:

Amazing ignorance. I haven't even thought about such things for
quite a few years. I suggest you get and use DJGPP.

why should someone STILL use such abominations like dos extenders
and MS-DOGs in 2006 ?

is this a joke ?

[Richard Heathfield]

Bebert said:

CBFalconer wrote:

>Amazing ignorance. I haven't even thought about such things for
quite a few years. I suggest you get and use DJGPP.

why should someone STILL use such abominations like dos extenders
and MS-DOGs in 2006 ?

1) Because they want to. Reason plays no part here. If wishes were wishes,
we'd wish for our wishes, and round and round it goes.
2) Because they're told to, by their boss, professor, or other Significant
Authority Figure. Reason plays no part here either. "Because I say so,
that's why!"
3) Because they're constrained by cost factors that make them unable to
afford a more advanced operating system (either because it's too expensive
per se, or because its hardware demands are beyond their means). Consider,
for example, charities, third world schools, etc. Just last year, I visited
the headquarters of an international charitable organisation where *all* of
the computers were running Windows 95, which is basically a DOS extender
with delusions of grandeur.
4) Because they're unwilling to change a working mission-critical system.
5) Because they're *unable* to change the operating system (e.g. because the
machine is in orbit or something).
6) All the reasons I haven't thought of in the minute or two I was thinking
about it.

is this a joke ?

No, it's just that you didn't think it through properly.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Bos]

jacob navia <ja***@jacob.remcomp.frwrote:

Richard Bos a écrit :

jacob navia <ja***@jacob.remcomp.frwrote:

>This thread (I repeat) was about MIRACL C.

Even if that were true - which it isn't -

The original poster wrote

I am using "Miracle C compiler".

That does not mean that the thread is about that compiler. Especially
not in this group.

But obviously you can't read.

That's rich, coming from you.

Richard

[Random832]

2006-12-20 <45****************@news.xs4all.nl>,
Richard Bos wrote:

jacob navia <ja***@jacob.remcomp.frwrote:

>Richard Bos a écrit :

jacob navia <ja***@jacob.remcomp.frwrote:
This thread (I repeat) was about MIRACL C.

Even if that were true - which it isn't -

The original poster wrote

> I am using "Miracle C compiler".

That does not mean that the thread is about that compiler. Especially
not in this group.

But do you think that on such a compiler, which may only support the
minimum environmental limits, that declaring an array of 15000 of
anything in automatic storage is _advisable_?

[Keith Thompson]

Random832 <ra****@random.yi.orgwrites:

2006-12-20 <45****************@news.xs4all.nl>,
Richard Bos wrote:

>jacob navia <ja***@jacob.remcomp.frwrote:

>>Richard Bos a écrit :
jacob navia <ja***@jacob.remcomp.frwrote:
This thread (I repeat) was about MIRACL C.

Even if that were true - which it isn't -

The original poster wrote

I am using "Miracle C compiler".

That does not mean that the thread is about that compiler. Especially
not in this group.

But do you think that on such a compiler, which may only support the
minimum environmental limits, that declaring an array of 15000 of
anything in automatic storage is _advisable_?

Possibly not. *Any* implementation may impose different limits on
automatic vs. static storage. It's certainly worth pointing out that
the limit on static storage is typically higher than the limit on
automatic storage.

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

[Richard Bos]

Random832 <ra****@random.yi.orgwrote:

2006-12-20 <45****************@news.xs4all.nl>,
Richard Bos wrote:

jacob navia <ja***@jacob.remcomp.frwrote:

Richard Bos a écrit :
jacob navia <ja***@jacob.remcomp.frwrote:
This thread (I repeat) was about MIRACL C.

Even if that were true - which it isn't -

The original poster wrote

I am using "Miracle C compiler".

That does not mean that the thread is about that compiler. Especially
not in this group.

But do you think that on such a compiler, which may only support the
minimum environmental limits, that declaring an array of 15000 of
anything in automatic storage is _advisable_?

Of course not. But that does not warrant the extrapolation, wrong _and_
off-topic as it is, to all MS-DOS systems.

Richard