I've a code in which I don't know how many elements an array may
contain, BUT I know the max. no. of values it may have. So I do this
malloc(MAXLEN), however I can use realloc(...) each time I add a new
element to this array.
Now my question is: will doing realloc everytime slow down the code very
much? My project is concerned about high performance.
Pushkar Pradhan
33  7325 
On Mon, 24 Nov 2003 22:06:19 -0600, Pushkar Pradhan wrote: I've a code in which I don't know how many elements an array may
contain, BUT I know the max. no. of values it may have. So I do this
malloc(MAXLEN), however I can use realloc(...) each time I add a new
element to this array.
Now my question is: will doing realloc everytime slow down the code very
much?
Yes, but that's not a problem. Don't realloc for every element. Each time
you run out of elements, use realloc to double the size of the array.
"Sheldon Simms" <sh**********@yahoo.com> wrote in message
news:pa****************************@yahoo.com... On Mon, 24 Nov 2003 22:06:19 -0600, Pushkar Pradhan wrote:
I've a code in which I don't know how many elements an array may
contain, BUT I know the max. no. of values it may have. So I do this
malloc(MAXLEN), however I can use realloc(...) each time I add a new
element to this array.
Now my question is: will doing realloc everytime slow down the code very
much?
Yes, but that's not a problem. Don't realloc for every element. Each time
you run out of elements, use realloc to double the size of the array.
< not on-topic, but maybe to the point>
But if all elements will have to be in memory soon or later,
why not malloc for all of them at the beginning (possibly
with realloc after initial assumption about size won't hold)?
While later on there may not be enough space to allocate
bigger continuous chunk, it can be on the beginning. If it is
not, why bother to start crunching? All later subsequent
allocations (for other stuff) could be smaller and "fit" into
possibly fragmented memory.
</ not on-topic, but maybe to the point>
On Mon, 24 Nov 2003 22:06:19 -0600, Pushkar Pradhan
<pu*****@gri.msstate.edu> wrote in comp.lang.c: I've a code in which I don't know how many elements an array may
contain, BUT I know the max. no. of values it may have. So I do this
malloc(MAXLEN), however I can use realloc(...) each time I add a new
element to this array.
Now my question is: will doing realloc everytime slow down the code very
much? My project is concerned about high performance.
Pushkar Pradhan
The C standard does not specify performance of anything. Much depends
on your particular compiler and operating system, which you can either
test or ask about in a group that supports your system.
There is a good chance that at least some reallocation calls will be
expensive in terms of time. Perhaps a better memory allocation
strategy would be in order.
If you really need to shrink the memory block, is it possible that you
can do it after all elements are added, instead of after each one?
If that is not possible, you could start out with an allocation for
some fraction of the maximum size, for example 25%. If you used that
up you could allocate another 25%, and another and another.
Other possibilities are to pick some likely size and always double it
or multiply it by 1.5 each time you need to grow the block.
You should investigate the typical needs of the program, if possible.
The maximum number of elements might be 1000, but perhaps most of the
time it will need 100 or less.
--
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++ ftp://snurse-l.org/pub/acllc-c++/faq
In <3F**************@gri.msstate.edu> Pushkar Pradhan <pu*****@gri.msstate.edu> writes: I've a code in which I don't know how many elements an array may
contain, BUT I know the max. no. of values it may have. So I do this
malloc(MAXLEN), however I can use realloc(...) each time I add a new
element to this array.
Now my question is: will doing realloc everytime slow down the code very
much? My project is concerned about high performance.
If you know the maximum number of elements, try to allocate memory for
all of them. When you know the exact number, call realloc to release
the unused memory. This way, the whole job takes one malloc and one
realloc call. This is important if performance is a concern, because
malloc and friends tend to be expensive in terms of CPU cycles.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
"Sheldon Simms" <sh**********@yahoo.com> schrieb im Newsbeitrag
news:pa****************************@yahoo.com... Yes, but that's not a problem. Don't realloc for every element. Each time
you run out of elements, use realloc to double the size of the array.
That's actually very good strategy with which I made good experiences.
If he uses a structure type, he can write a set of functions to handle the
case universally, like
#include <stddef.h>
#include <string.h>
#include <stdlib.h>
#include <limits.h>
typedef struct { void* buf; size_t elsz; size_t size; size_t used; }
dynamic_array_t;
typedef dynamic_array_t* dynamic_array_pointer_t;
dynamic_array_pointer_t create_dynamic_array( size_t elsz, size_t
initial ) {
dynamic_array_pointer_t da = (dynamic_array_pointer_t) malloc(
sizeof(dynamic_array_t) );
if ( da == 0 ) return 0;
da->buf = malloc( elsz * initial ); da->elsz = elsz; da->size =
initial; da->used = 0; return da;
}
void delete_dynamic_array( dynamic_array_pointer da ) { free( da.buf );
free( da ); }
void* address_dynamic_array_element_readonly( dynamic_array_pointer da,
size_t index ) {
if ( index >= da->used ) return 0;
{ char* p = (char*) da->buf; return p+( da->elsz * index ); }
}
void* address_dynamic_array_element_readwrite( dynamic_array_pointer da,
size_t index ) {
if ( index >= da->used ) {
if ( index >= da->size ) {
size_t newsz; void* newbf;
if ( index >= UINT_MAX / da->elsz ) return 0;
if ( da->size >= UINT_MAX / 2U ) newsz = UINT_MAX /
da->elsz; else newsz = da->size * 2U;
if ( index >= newsz ) newsz = index + 1U;
newbf = malloc( da->elsz * newsz ); if ( newbf == 0 ) return
0;
if ( da->used ) memcpy( newbf, da->buf, da->used *
da->elsz );
free( da->buf ); da->buf = newbf; da->size = newsz;
}
da->used = index + 1U;
}
{ char* p = (char*) da->buf; return p+( da->elsz * index ); }
}
Here, the functions create_dynamic_array() and delete_dynamic_array() handle
array creation / destruction, and address_dynamic_array_element_readonly()
and address_dynamic_array_element_readwrite() access the array for reading
and writing and return a pointer to an indexed array element. If during
write indexing, the index goes beyond the array size, it is automatically
resized to either twice the size, or a size including the indexed element.
This way, you can have arbitrary access to the array and can use it for many
kinds of purposes.
"Ekkehard Morgenstern" <ek******************@onlinehome.de> schrieb im
Newsbeitrag news:bq*********@online.de... void delete_dynamic_array( dynamic_array_pointer da ) { free(
da.buf ); free( da ); }
of course this should read " free( da->buf ) " not " free( da.buf ); ".
In <bq*********@online.de> "Ekkehard Morgenstern" <ek******************@onlinehome.de> writes: void* address_dynamic_array_element_readonly( dynamic_array_pointer da,
void* address_dynamic_array_element_readwrite( dynamic_array_pointer da,
1 2 3
12345678901234567890123456789012345
Not even C99 guarantees that many significant initial characters in
an external identifier. Apart from being brain dead from both a stylistic
and a practical point of view, such identifiers are not even portable.
6 Any identifiers that differ in a significant character are
different identifiers. If two identifiers differ only in
nonsignificant characters, the behavior is undefined.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
"Dan Pop" <Da*****@cern.ch> schrieb im Newsbeitrag
news:bq**********@sunnews.cern.ch... void* address_dynamic_array_element_readwrite( dynamic_array_pointer
da, 1 2 3
12345678901234567890123456789012345
Not even C99 guarantees that many significant initial characters in
Not true. The IEC 9899:1999 (C99) standard states that identifiers are
unlimited in length:
(6.4.2.1.2) "There is no specific limit on the maximum length of an
identifier."
Ekkehard Morgenstern <ek******************@onlinehome.de> wrote: "Dan Pop" <Da*****@cern.ch> schrieb im Newsbeitrag
news:bq**********@sunnews.cern.ch... > void* address_dynamic_array_element_readwrite( dynamic_array_pointer da, 1 2 3
12345678901234567890123456789012345
Not even C99 guarantees that many significant initial characters in
Not true. The IEC 9899:1999 (C99) standard states that identifiers are
unlimited in length:
(6.4.2.1.2) "There is no specific limit on the maximum length of an
identifier."
No, but there is a limit on the /significant/ characters
in the identifier. The relevant text is:
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:13)
...
-- 63 significant initial characters in an internal
identifier or a macro name (each universal character
name or extended source character is considered a
single character)
-- 31 significant initial characters in an external
identifier (each universal character name specifying a
short identifier of 0000FFFF or less is considered 6
characters, each universal character name specifying a
short identifier of 00010000 or more is considered 10
characters, and each extended source character is
considered the same number of characters as the
corresponding universal character name, if any)14)
Alex
On Thu, 27 Nov 2003 00:47:41 +0100, "Ekkehard Morgenstern"
<ek******************@onlinehome.de> wrote:
"Dan Pop" <Da*****@cern.ch> schrieb im Newsbeitrag
news:bq**********@sunnews.cern.ch... > void* address_dynamic_array_element_readwrite( dynamic_array_pointer
da, 1 2 3
12345678901234567890123456789012345
Not even C99 guarantees that many significant initial characters in
Not true. The IEC 9899:1999 (C99) standard states that identifiers are
unlimited in length:
(6.4.2.1.2) "There is no specific limit on the maximum length of an
identifier."
5.2.4.1.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:
[...]
- 31 significant initial characters in an external identifier...
6.4.2.1.5 As discussed in 5.2.4.1, an implementation may limit the
number of significant initial characters in an identifer; the limit
for an external name [...] may be more restrictive than for an
internal name [...]. The number of significant characters in an
identifer is implementation-defined.
- Sev
Ekkehard Morgenstern wrote: "Sheldon Simms" <sh**********@yahoo.com> schrieb im Newsbeitrag
Yes, but that's not a problem. Don't realloc for every element.
Each time you run out of elements, use realloc to double the
size of the array.
That's actually very good strategy with which I made good
experiences.
That is often a good strategy, but not always. I use it in
hashlib when expanding the hash table size, but not in ggets when
expanding an interactive (usually) input buffer, when I expand by
a constant increment. I consider the future expectations to be
widely different. Both available on my site below.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
>> Yes, but that's not a problem. Don't realloc for every element. Each time you run out of elements, use realloc to double the size of the array.
That's actually very good strategy with which I made good experiences.
You may wish to have a failure-backoff algorithm in place. It may
be very annoying that the program fails (rather than slowing down)
trying to process 1,200,000 elements because it doesn't have enough
room for 2,048,000 elements. This can get especially annoying on
implementations that, due to other uses of dynamic memory, really
needs to have 3x memory to grow from x to 2x because of fragmentation.
Then again, it may be that if the program is that tight on memory
loading the data, it's going to fail soon anyway doing something
with it, so, depending on the application, it may not matter.
Gordon L. Burditt
Gordon Burditt wrote: Yes, but that's not a problem. Don't realloc for every element. Each time
you run out of elements, use realloc to double the size of the array.
That's actually very good strategy with which I made good experiences.
You may wish to have a failure-backoff algorithm in place. It may
be very annoying that the program fails (rather than slowing down)
trying to process 1,200,000 elements because it doesn't have enough
room for 2,048,000 elements. This can get especially annoying on
implementations that, due to other uses of dynamic memory, really
needs to have 3x memory to grow from x to 2x because of fragmentation.
I usually do exponential growth with a constant less than 2, maybe 5/3
or 3/2. new=(5*old)/3;
A compromise on the amount of excess memory needed, and the time to
reallocate it.
-- glen
In <bq**********@online.de> "Ekkehard Morgenstern" <ek******************@onlinehome.de> writes: "Dan Pop" <Da*****@cern.ch> schrieb im Newsbeitrag
news:bq**********@sunnews.cern.ch... > void* address_dynamic_array_element_readwrite( dynamic_array_pointer
da, 1 2 3
12345678901234567890123456789012345
Not even C99 guarantees that many significant initial characters in
Not true. The IEC 9899:1999 (C99) standard states that identifiers are
unlimited in length:
(6.4.2.1.2) "There is no specific limit on the maximum length of an
identifier."
You may want to read the standard before starting quoting from it.
You may also want to engage your brain while reading the quotes I have
posted (there was no mention of the maximum length of an identifier
there, was it? and why do you think I've stopped counting before reaching
the end of your identifiers?).
Otherwise, all you can achieve is making a fool of yourself.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
"Dan Pop" <Da*****@cern.ch> schrieb im Newsbeitrag
news:bq***********@sunnews.cern.ch... You may also want to engage your brain while reading the quotes I have
posted (there was no mention of the maximum length of an identifier
there, was it? and why do you think I've stopped counting before reaching
the end of your identifiers?).
If the significance of identifiers is a problem at link time, I can choose
to use a different linker for which all characters in an identifier are
significant, or modify the source code accordingly.
To limit the identifier length to make code more unreadable is not the
wisest of choices.
Perhaps you should read a programming style guide, or something.
In that particular case, it would be sufficient to move the key words
distinguishing the purpose of the functions to the beginning of the
identifier name, like "access_readwrite_" and "access_readonly_". It would
not be a good idea to make the identifiers short just for the purpose of
gratifying a particular linker.
Otherwise, all you can achieve is making a fool of yourself.
Why, thank you.
"Ekkehard Morgenstern" <ek******************@onlinehome.de> wrote:
"Dan Pop" <Da*****@cern.ch> schrieb im Newsbeitrag
news:bq***********@sunnews.cern.ch... You may also want to engage your brain while reading the quotes I have
posted (there was no mention of the maximum length of an identifier
there, was it? and why do you think I've stopped counting before reaching
the end of your identifiers?).
If the significance of identifiers is a problem at link time, I can choose
to use a different linker for which all characters in an identifier are
significant, or modify the source code accordingly.
Which will unnecessarily limit the portability of your code.
To limit the identifier length to make code more unreadable is not the
wisest of choices.
Trading portability for readability is definitely worse.
Perhaps you should read a programming style guide, or something.
You may want to follow your own advice, too.
In that particular case, it would be sufficient to move the key words
distinguishing the purpose of the functions to the beginning of the
identifier name, like "access_readwrite_" and "access_readonly_".
Then why didn't you do so in the first place?
It would
not be a good idea to make the identifiers short just for the purpose of
gratifying a particular linker.
And instead make them long and protect a vast number of linkers from
being able to process your code correctly? Sorry, but that sounds
odd to me.
It's a Bad Idea[tm] to unnecessarily constrain portability to
implementations where linkers are available that guarantee more
significant characters than required by the standard. Gaining
portability for free is IMO a Good Idea[tm].
Regards
--
Irrwahn
(ir*******@freenet.de)
In <bq**********@online.de> "Ekkehard Morgenstern" <ek******************@onlinehome.de> writes: "Dan Pop" <Da*****@cern.ch> schrieb im Newsbeitrag
news:bq***********@sunnews.cern.ch... You may also want to engage your brain while reading the quotes I have
posted (there was no mention of the maximum length of an identifier
there, was it? and why do you think I've stopped counting before reaching
the end of your identifiers?).
If the significance of identifiers is a problem at link time, I can choose
Too late, you have already invoked undefined behaviour. That is, assuming
you understand the concept.
to use a different linker for which all characters in an identifier are
significant, or modify the source code accordingly.
To limit the identifier length to make code more unreadable is not the
wisest of choices.
To use identifiers longer than 31 characters is the most idiotic choice.
Perhaps you should read a programming style guide, or something.
Take your own advice. Very long identifiers impair the source code
readability, even if the implementation can handle them. They also
impair the code's portability, since there is no guarantee that another
implementation will support them, too. And if it doesn't, it's not even
require to warn you about the fact.
In that particular case, it would be sufficient to move the key words
distinguishing the purpose of the functions to the beginning of the
identifier name, like "access_readwrite_" and "access_readonly_". It would
not be a good idea to make the identifiers short just for the purpose of
gratifying a particular linker.
You really have no clue.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
"Dan Pop" <Da*****@cern.ch> schrieb im Newsbeitrag
news:bq*********@sunnews.cern.ch... You really have no clue.
Well, definitely more than you. I've been programming in C since 1986.
Perhaps you've been playing with lego's then, if you were born at all.
Most C compilers nowadays come in C/C++ compiler packages. A C++ compiler
generates names that are up to 256 characters in size, and the linker can
handle them, of course.
In C++ there's a requirement for identifiers to be significant for all
characters, which usually is 256 max. or unlimited.
Have you ever looked at the mangled identifier names generated by C++
compilers? They're almost all longer than 31 characters. If a C/C++ linker
couldn't handle that, you couldn't use C++ with it.
So whatever archaic C compiler you're using, it's none of our times.
When I began programming in C, identifiers were significant only to 6
characters. I'm glad that such limits don't exist anymore. You're talking
about pink elephants, I know of no linker that can handle only 31 characters
of significance.
"Irrwahn Grausewitz" <ir*******@freenet.de> schrieb im Newsbeitrag
news:af********************************@4ax.com... [copy of Dan Pop's post snipped]
What I said to him also applies to you. No C/C++ package linker has the
limits you talked about. So there's no "undefined behaviour".
"Ekkehard Morgenstern" <ek******************@onlinehome.de> wrote: "Irrwahn Grausewitz" <ir*******@freenet.de> schrieb im Newsbeitrag
news:af********************************@4ax.com... [copy of Dan Pop's post snipped]
What I said to him also applies to you. No C/C++ package linker has the
limits you talked about. So there's no "undefined behaviour".
Get real. Undefined behaviour is behaviour that's not defined by the
standard. Get a copy and read it. It's worth both the money and the
time to read it. If you want to discuss properties of a particular
implementation you may do so, but please not here in clc. Thank you.
Regards
--
Irrwahn
(ir*******@freenet.de)
"Ekkehard Morgenstern" <ek******************@onlinehome.de> wrote:
"Dan Pop" <Da*****@cern.ch> schrieb im Newsbeitrag
[Hint: even Backdoor Express allows you to modify the
attribution line.]
news:bq*********@sunnews.cern.ch... You really have no clue.
Well, definitely more than you. I've been programming in C since 1986.
Perhaps you've been playing with lego's then, if you were born at all.
LOL. I imagine his colleagues would've been slightly irritated,
if this were true.
<irrelevant C++ stuff snipped> clc++ is round the corner.
So whatever archaic C compiler you're using, it's none of our times.
Uh, you are one of those "all the world is a {W|L}intel-box"
guys. Every implementation in use nowadays is 'of our times'
per definition.
When I began programming in C, identifiers were significant only to 6
characters. I'm glad that such limits don't exist anymore. You're talking
about pink elephants, I know of no linker that can handle only 31 characters
of significance.
Guess what: that doesn't mean that no such beast exists.
Regards
--
Irrwahn,
int Iknowthisidentifieriswaytolongtobeusefulbutwhatthe heck = 42;
Ekkehard Morgenstern wrote: "Irrwahn Grausewitz" <ir*******@freenet.de> schrieb im Newsbeitrag
news:af********************************@4ax.com...
[copy of Dan Pop's post snipped]
What I said to him also applies to you. No C/C++ package linker has the
limits you talked about. So there's no "undefined behaviour".
It is the Standard that defines the language, not implementations.
And in the Standard
Section 6.4.2.1
6 Any identifiers that differ in a significant character are
different identifiers. If two identifiers differ only in
nonsignificant characters, the behavior is undefined.
--
Al Bowers
Tampa, Fl USA
mailto: xa******@myrapidsys.com (remove the x to send email) http://www.geocities.com/abowers822/
In <bq**********@online.de> "Ekkehard Morgenstern" <ek******************@onlinehome.de> writes: "Dan Pop" <Da*****@cern.ch> schrieb im Newsbeitrag
news:bq*********@sunnews.cern.ch... You really have no clue.
Well, definitely more than you.
I'll let the rest of c.l.c to be the judge of this one.
I've been programming in C since 1986.
Perhaps you've been playing with lego's then, if you were born at all.
But it's equally probable (from the information you possess) that I've
been programming in C since 1976 or even earlier. Furthermore, there are
people who get more experience in two years of programming in C than
others in a lifetime.
Despite your inability to compare either the quantity or the quality of
our experiences, you've posted the above. This puts you in the same
league with Mark McIntyre, our resident idiot.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
On 1 Dec 2003 12:24:58 GMT, Da*****@cern.ch (Dan Pop) wrote:
snip Despite your inability to compare either the quantity or the quality of
our experiences, you've posted the above. This puts you in the same
league with Mark McIntyre, our resident idiot.
You have enough fun insulting Mark when you respond to his posts. Do
you also need to do it gratuitously?
<<Remove the del for email>>
On 2 Dec 2003 08:54:14 GMT, in comp.lang.c , Barry Schwarz
<sc******@deloz.net> wrote: On 1 Dec 2003 12:24:58 GMT, Da*****@cern.ch (Dan Pop) wrote:
snipDespite your inability to compare either the quantity or the quality of
our experiences, you've posted the above. This puts you in the same
league with Mark McIntyre, our resident idiot.
You have enough fun insulting Mark when you respond to his posts. Do
you also need to do it gratuitously?
Don't bother on my behalf. Dan has the social skills of a blast ended
screwt, and holds a grudge like only the Swiss can, but thats ok, I
know hes a twit so I can ignore him merrily. .
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
[snips]
On Fri, 28 Nov 2003 18:46:25 +0100
"Ekkehard Morgenstern" <ek******************@onlinehome.de> wrote: When I began programming in C, identifiers were significant only to 6
characters. I'm glad that such limits don't exist anymore.
No? Okay, good. Point out where in the C standard you're guaranteed to have, say, 128 significant characters in identifiers.
Kelsey Bjarnason <ke*****@lightspeed.bc.ca> writes: On Fri, 28 Nov 2003 18:46:25 +0100
"Ekkehard Morgenstern" <ek******************@onlinehome.de> wrote:
When I began programming in C, identifiers were significant only to 6
characters. I'm glad that such limits don't exist anymore.
No? Okay, good. Point out where in the C standard you're
guaranteed to have, say, 128 significant characters in
identifiers.
The new limit is 31 characters according to 5.2.4.1#1. That's
much more reasonable than 6. If you need more, just take the
SHA-1 hash of your longer identifier, convert the first 15 bytes
of the result to hexadecimal, prepend a letter to ensure it
doesn't begin with a digit, and you're done. Easy. 120 bits of
uniqueness should be enough identifiers for anyone, but if you
still need more then you can use base-63 encoding and fit the
whole 160 bits of SHA-1 in there. (If you don't want to remember
hash values, write a preprocessor.)
--
"Some programming practices beg for errors;
this one is like calling an 800 number
and having errors delivered to your door."
--Steve McConnell
[snips]
On Wed, 03 Dec 2003 22:30:17 -0800, Ben Pfaff wrote: The new limit is 31 characters according to 5.2.4.1#1.
Yeah, but someone seems to be going on about 256 characters and God knows
what all else. 6 was pretty cheesy, 31 seems adequate.
In <pa****************************@lightspeed.bc.ca > Kelsey Bjarnason <ke*****@lightspeed.bc.ca> writes: [snips]
On Wed, 03 Dec 2003 22:30:17 -0800, Ben Pfaff wrote:
The new limit is 31 characters according to 5.2.4.1#1.
Yeah, but someone seems to be going on about 256 characters and God knows
what all else. 6 was pretty cheesy, 31 seems adequate.
6, for external identifiers only, was imposed by some platforms that were
still relevant by 1989. They've been put to sleep in the meantime, so C99
could extend it to 31, which is far too much for human generated
identifiers, but probably OK for machine generated identifiers.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Dan Pop wrote: In <pa****************************@lightspeed.bc.ca > Kelsey Bjarnason <ke*****@lightspeed.bc.ca> writes:
[snips]
On Wed, 03 Dec 2003 22:30:17 -0800, Ben Pfaff wrote:
The new limit is 31 characters according to 5.2.4.1#1.
Yeah, but someone seems to be going on about 256 characters and God knows
what all else. 6 was pretty cheesy, 31 seems adequate.
6, for external identifiers only, was imposed by some platforms that were
still relevant by 1989. They've been put to sleep in the meantime,
Nah. Not "put to sleep", just "refurbished and renovated". MVS now supports
externals/entrypoints beyond 8 characters long, and no longer requires UPPER
CASE only entrypoints.
so C99
could extend it to 31, which is far too much for human generated
identifiers, but probably OK for machine generated identifiers.
--
Lew Pitcher
Master Codewright and JOAT-in-training
Registered Linux User #112576 ( http://counter.li.org/)
Slackware - Because I know what I'm doing.
In <cc**********@merlin.l6s4x6-4.ca> Lew Pitcher <lp******@sympatico.ca> writes: Dan Pop wrote: In <pa****************************@lightspeed.bc.ca > Kelsey Bjarnason <ke*****@lightspeed.bc.ca> writes:
[snips]
On Wed, 03 Dec 2003 22:30:17 -0800, Ben Pfaff wrote:
The new limit is 31 characters according to 5.2.4.1#1.
Yeah, but someone seems to be going on about 256 characters and God knows
what all else. 6 was pretty cheesy, 31 seems adequate.
6, for external identifiers only, was imposed by some platforms that were
still relevant by 1989. They've been put to sleep in the meantime,
Nah. Not "put to sleep", just "refurbished and renovated". MVS now supports
externals/entrypoints beyond 8 characters long, and no longer requires UPPER
^^^^^^^^^^^^CASE only entrypoints.
The 6 monocase character limit was not imposed by IBM OSs, but by
DEC OSs for the PDP-11. DEC stopped supporting them, as well as the
underlying hardware, quite some time before being bought by Compaq.
These OSs used 32 bits for external symbols in the object file format.
Each 16-bit word could represent 3 characters of the RADIX-50 character
set (a character set with 050 members).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Dan Pop wrote:
(snip) The 6 monocase character limit was not imposed by IBM OSs, but by
DEC OSs for the PDP-11. DEC stopped supporting them, as well as the
underlying hardware, quite some time before being bought by Compaq.
These OSs used 32 bits for external symbols in the object file format.
Each 16-bit word could represent 3 characters of the RADIX-50 character
set (a character set with 050 members).
I am pretty sure that RT-11 is still in use.
I never had a C compiler to run on it, though.
-- glen
In <U0dBb.343570$275.1136917@attbi_s53> glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes: Dan Pop wrote:
(snip)
The 6 monocase character limit was not imposed by IBM OSs, but by
DEC OSs for the PDP-11. DEC stopped supporting them, as well as the
underlying hardware, quite some time before being bought by Compaq.
These OSs used 32 bits for external symbols in the object file format.
Each 16-bit word could represent 3 characters of the RADIX-50 character
set (a character set with 050 members).
I am pretty sure that RT-11 is still in use.
In use for running legacy applications (lab and industry automation),
not for active software development.
I never had a C compiler to run on it, though.
DECUS C supported RT-11, but I'm not aware of any standard C compiler
for the PDP-11 hardware. I wouldn't be surprised if someone ported gcc
to the PDP-11, at least as a cross-compiler, though.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: WL |
last post by:
Hey, all. I'm creating an array of strings (char **argv style) on
the fly, and using realloc to create string pointers, and malloc
for the strings itself (if that makes any sense).
I'm using the...
|
by: I_have_nothing |
last post by:
Hi!
I am new in C. I try to use dynamical allocation fuction malloc( ) and
realloc( ).
I found something strange.
After several calling realloc( ), the malloc( ) will give me a
Segmentation...
|
by: ncf |
last post by:
Hi all.
In another topic, I was informed that I had to dynamically allocate
memory instead of just trying to expand on a list. (I'm trying to learn
C, and have a strong background in PHP and...
|
by: Hrv'uljak |
last post by:
Anybody has a better solution? How to avoid memory allocation in main
function?
Thanks!
--------
#include <stdio.h>
#include <conio.h>
#include <string.h>
#include <malloc.h>
|
by: quiberon2 |
last post by:
Hi,
Sorry if it might be a stupid question but what should returns
malloc(0) ?
void *ptr = malloc(0);
I am running gcc 3.3.5 and a non-null address is returned.
( in the compiler that I am...
|
by: ravi.cs.2001 |
last post by:
Hi all,
I m relatively new to C. I have few queries related to malloc():
#1. When we perform malloc(), the memory allocated dynamically comes
from the heap area of the process in concern....
|
by: ravi |
last post by:
Hi all,
I m relatively new to C. I have few queries related to malloc():
1. When we perform malloc(), the memory allocated dynamically comes from
the heap area of the process in concern. Well,...
|
by: Bill Cunningham |
last post by:
My string.h headers declares two functions I have been using called
memfrob and strfry. They are encryption types functions. My man pages say
they are standard to linux c and gnu c. They sure...
|
by: Dave |
last post by:
Hello,
I'm teaching myself C by working my way through Steve Summit's tutorial
(http://www.eskimo.com/~scs/cclass/cclass.html). In one of the questions
(assignment 6, exercise 7), you have to...
|
by: Muzammil |
last post by:
whats the beauty of "malloc" over "new" why its helpful for
programmer.for its own memory area.??
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
