Malloc 2: The revenge of Malloc 
Author Message
 Malloc 2: The revenge of Malloc

Hi...

I have a question about malloc:::

I know how to allocate a single array:

x=(type *)malloc(size*sizeof(type));

Where x is type 'type' and size 'size'. Now,  this is fine for INTs, but I
want to do the same with a multidimensional char array, like this:

char[number of string][size of each string];

So I can put a word in the array like this.

Array [0]='Hello there'=11 chars
Array++;
Array [1]='Blah'=4 chars

This is because I'm reading words from a file. Actually, I'm writing a
program which will read in about 10,000 HTML files and create a huge word
index for them, for a CD-ROM full of HTML stuff (for my own use). This will
make it easy to search 600mb over 30,000 files in a few seconds. However, I
need to get the words into the computer's memory so my program can compare
them (to get rid of redundancy - why index 'the' for the same file 500
times when once will suffice?)

Thanks,

Jeremy.
--
Replace 'X' in e-mail with 'J' if you wish to e-mail me



Thu, 19 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc

See the FAQ for the group (section 6.16):
ftp://rtfm.mit.edu/pub/faqs/C-faq/faq

It has some very good examples.

:Hi...

:I have a question about malloc:::

:I know how to allocate a single array:

:x=(type *)malloc(size*sizeof(type));

:Where x is type 'type' and size 'size'. Now,  this is fine for INTs, but I
:want to do the same with a multidimensional char array, like this:

:char[number of string][size of each string];

:So I can put a word in the array like this.

:Array [0]='Hello there'=11 chars
:Array++;
:Array [1]='Blah'=4 chars

:This is because I'm reading words from a file. Actually, I'm writing a
:program which will read in about 10,000 HTML files and create a huge word
:index for them, for a CD-ROM full of HTML stuff (for my own use). This will
:make it easy to search 600mb over 30,000 files in a few seconds. However, I
:need to get the words into the computer's memory so my program can compare
:them (to get rid of redundancy - why index 'the' for the same file 500
:times when once will suffice?)

:Thanks,

:Jeremy.
:--
:Replace 'X' in e-mail with 'J' if you wish to e-mail me



Thu, 19 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc


Quote:
> Hi...

> I have a question about malloc:::

It's okay, I did it this way:

Define:

char *word[200];

Sets up an array of 200 words with indeterminate lengths, and:

word[5]=(char *)malloc(strlen("Hi there how ya doing")*sizeof(char));
strcpy(word[5],"Hi there how ya doing";

Would, I think, make the 5th word in the array contain the text 'Hi there
how ya doing' without crashing the machine.

I think this is correct!! :-)

I think this works because the char definition says "char *word", so
because of the '*' being there, the "[200]" applies not to the number of
characters in the char, but the number of words in the array (BTW, 'words'
is referring to *real* words, "Hello" and "Blah").

BTW, I think this is a great newsgroup, except for all the people asking
about the wrong flavours of C and causing a mess. I always write in ANSI C,
because the learning curve vs simplicity vs code portability makes it
perfect. Although I think they should have put directory cataloguing in
ANSI C. I end up writing a batch file that pipes the directory to a file
and them runs my program, which recurses through the files. ;-)

Cheers,

Jeremy.
--
Replace 'X' in e-mail with 'J' if you wish to e-mail me



Thu, 19 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc
Instead of thinking of a two dimensional array, think of an array of pointers
where each member in the array points to a string. You can allocate memory for
the basic array using malloc where the size of the block is the number of
pointers you want times the size of a pointer to char.

Now, as you read a string from your file (into some char array that you have
allocated), you can use malloc to allocate memory based on the lenght of the
string + 1, store the pointer to this memory in your array and then copy the
string into this memory.

Quote:

> Hi...

> I have a question about malloc:::

> I know how to allocate a single array:

> x=(type *)malloc(size*sizeof(type));

> Where x is type 'type' and size 'size'. Now,  this is fine for INTs, but I
> want to do the same with a multidimensional char array, like this:

> char[number of string][size of each string];

> So I can put a word in the array like this.

> Array [0]='Hello there'=11 chars
> Array++;
> Array [1]='Blah'=4 chars

> This is because I'm reading words from a file. Actually, I'm writing a
> program which will read in about 10,000 HTML files and create a huge word
> index for them, for a CD-ROM full of HTML stuff (for my own use). This will
> make it easy to search 600mb over 30,000 files in a few seconds. However, I
> need to get the words into the computer's memory so my program can compare
> them (to get rid of redundancy - why index 'the' for the same file 500
> times when once will suffice?)

> Thanks,

> Jeremy.
> --
> Replace 'X' in e-mail with 'J' if you wish to e-mail me



Thu, 19 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc

Quote:

>char *word[200];

>word[5]=(char *)malloc(strlen("Hi there how ya doing")*sizeof(char));
>strcpy(word[5],"Hi there how ya doing";

>Would, I think, make the 5th word in the array contain the text 'Hi there
>how ya doing' without crashing the machine.

>I think this is correct!! :-)

No. The block of memory you have allocated is not large enough: you
need to allocate an extra byte for the string terminator. You also
shouldn't cast the return value of malloc; that can hide bugs. And you
don't need to multiply by the size of the string by sizeof(char), as
by definition that is equal to 1.

So,

  word[ 5 ] = malloc( strlen( "Hi there how ya doing" ) + 1 );
  strcpy( word[ 5 ], "Hi there how ya doing" );

But I'd write this as,

  const char *mystring = "Hi there how ya doing";
  word[ 5 ] = malloc( strlen( mystring ) + 1 );
  strcpy( word[ 5 ], mystring );

so that if I needed to change the string placed in word[ 5 ], I'd only
need to change it in one place.

Quote:
>I think this works because the char definition says "char *word", so
>because of the '*' being there, the "[200]" applies not to the number of
>characters in the char, but the number of words in the array (BTW, 'words'
>is referring to *real* words, "Hello" and "Blah").

Yes. char *word[ 200 ] defines an an array of 200 pointers to
characters (200 strings).

Quote:
>BTW, I think this is a great newsgroup, except for all the people asking
>about the wrong flavours of C and causing a mess. I always write in ANSI C,
>because the learning curve vs simplicity vs code portability makes it
>perfect. Although I think they should have put directory cataloguing in
>ANSI C

All decent C compilers/operating systems support the directory
handling provided by POSIX.1. Not quite as portable as ANSI C, but
pretty close. Use it if you can.

-- Mat.



Fri, 20 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc

Quote:

> All decent C compilers/operating systems support the directory
> handling provided by POSIX.1.

A lot of compilers don't. And often they're the only ones you can get.

Stephan
(initiator of the campaign against grumpiness in c.l.c)



Fri, 20 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc

: >
: > All decent C compilers/operating systems support the directory
: > handling provided by POSIX.1.
:
: A lot of compilers don't.

Do you mean that they don't ship with suitable libraries, or that such
libraries simply aren't available?

-- Mat.



Fri, 20 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc

Quote:



> > Hi...

> > I have a question about malloc:::

> It's okay, I did it this way:

> Define:

> char *word[200];

> Sets up an array of 200 words with indeterminate lengths, and:

> word[5]=(char *)malloc(strlen("Hi there how ya doing")*sizeof(char));
> strcpy(word[5],"Hi there how ya doing";

> Would, I think, make the 5th word in the array contain the text 'Hi there
> how ya doing' without crashing the machine.

> I think this is correct!! :-)

ummm... no, it's not. Most significantly, you're not allocating enough
space for your string. You've forgotten about the nul terminator at the
end. There's the syntax error in the strcpy() statement - you've left
out a closing paren. Also, sizeof (char) is ALWAYS one! That's right, 1.
Also, you'd do wellif you lost the cast to (char *) at the end - it's
generally considered to be bad style in these parts.

--
 { Sunil Rao }
"And India acquired yet another willing convert to the philosophy of
 the meaningfully meaningless...  Or was it the meaninglessly
 meaningful?  Did anyone know what was happening?"  --  Gita Mehta



Fri, 20 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc

Quote:

>> All decent C compilers/operating systems support the directory
>> handling provided by POSIX.1.            ^^^^^^^

>A lot of compilers don't. And often they're the only ones you can get.


    Not quite as portable as ANSI C, but pretty close. Use it if you can.
                                                       ^^^^^^^^^^^^^^^^^^
which you deleted, in order to make your pointless point.

Show me one (hosted) implementation that does not SUPPORT the directory
handling functions defined by POSIX.1.  Note the keyword "support" rather
than "provide".

As for the availability of these functions, the FAQ claims that:

    Implementations also exist for MS-DOS, VMS, and other systems.

Dan
--
Dan Pop
CERN, IT Division

Mail:  CERN - EP, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland



Fri, 20 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc

Quote:



> : >
> : > All decent C compilers/operating systems support the directory
> : > handling provided by POSIX.1.
> :
> : A lot of compilers don't.

> Do you mean that they don't ship with suitable libraries, or that such
> libraries simply aren't available?

Both AFAIK. See my (meek) reply to Dans flame. Whoops, what I forgot
to mention in my reply to Dan: by now I am convinced that "A lot"
is very probably a slight exaggeration. Maybe "A few compilers don't"
would have saved me :-)

Stephan
(initiator of the campaign against grumpiness in c.l.c)



Fri, 20 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc

Quote:



> >> All decent C compilers/operating systems support the directory
> >> handling provided by POSIX.1.            ^^^^^^^

> >A lot of compilers don't. And often they're the only ones you can get.


>     Not quite as portable as ANSI C, but pretty close. Use it if you can.
>                                                        ^^^^^^^^^^^^^^^^^^
> which you deleted, in order to make your pointless point.

Actually I removed it, because it was besides my pointless point, which
related
to the text I did quote: "All decent C compilers/operating systems ...".
Guess what ? I'm one of those guys who look up if their current (good)
compiler is implicitely being called non-decent :-)

Quote:
> Show me one (hosted) implementation that does not SUPPORT the directory
> handling functions defined by POSIX.1.  Note the keyword "support" rather
> than "provide".

As far as I can judge: "INMOS ANSI-C ToolSet 3rd Generation" (2nd as
well
and I don't know about 4th, because it's not compatible with the
hardware
we use). Another might be the Texas Instruments C compiler for the C40,
but I am very unsure about this, because: I used it a few years ago and
I am not sure if it was complete hosted implementation.

My general experience is that hosted ANSI-C implementations for specific
rare hardware lack the comfort of any but the minimum requirements.

Quote:
> As for the availability of these functions, the FAQ claims that:

>     Implementations also exist for MS-DOS, VMS, and other systems.

OK, but one closing remark about my pointless point: no I am not a C
implementor and I might lack special knowledge of finer and finest
destinctions. I just saw a statement that broadly declassified all C
compilers without some special non ANSI-C extension as being "not
decent".

(As usual I cannot really refute your statement which is based on
superior
knowledge and experience. I just thought it's worth pointing out that my
reply was not just some quick flame without at least some thought to it)

Stephan
(initiator of the campaign against grumpiness in c.l.c)



Fri, 20 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc
:I have a question about malloc:::
: [snip] but I
:want to do the same with a multidimensional char array, like this:
:char[number of string][size of each string];

As far as I know, there is no way to malloc() a *genuine* multidimensional
array. However, you can do something very similar by mallocing an array of
pointers, each of which point to a malloced area of memory. Also, this way,
you can allocate memory dynamically- which I'm guessing is what you wanted
to do here? :-

:So I can put a word in the array like this.
:
:Array [0]='Hello there'=11 chars
:Array++;
:Array [1]='Blah'=4 chars

BTW, you don't need to cast the void pointer returned by malloc expilicitly.
C allows you to assign (void *) to any other pointer type, on the basis that
you know what you're doing.


  (Remove "BYESPAM" spam filter when replying by mail)



Fri, 20 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc

Quote:



>> >> All decent C compilers/operating systems support the directory
>> >> handling provided by POSIX.1.            ^^^^^^^

>> >A lot of compilers don't. And often they're the only ones you can get.


>>     Not quite as portable as ANSI C, but pretty close. Use it if you can.
>>                                                        ^^^^^^^^^^^^^^^^^^
>> which you deleted, in order to make your pointless point.

>Actually I removed it, because it was besides my pointless point, which
>related
>to the text I did quote: "All decent C compilers/operating systems ...".

This is called "quoting out of context", a lame practice.

Quote:
>Guess what ? I'm one of those guys who look up if their current (good)
>compiler is implicitely being called non-decent :-)

Nobody called your hosted compiler non-decent, unless it cannot support
the opendir/readdir functions.  What makes you think this is the case,
indeed?

Quote:
>> Show me one (hosted) implementation that does not SUPPORT the directory
>> handling functions defined by POSIX.1.  Note the keyword "support" rather
>> than "provide".

>As far as I can judge: "INMOS ANSI-C ToolSet 3rd Generation" (2nd as
>well
>and I don't know about 4th, because it's not compatible with the
>hardware
>we use). Another might be the Texas Instruments C compiler for the C40,
>but I am very unsure about this, because: I used it a few years ago and
>I am not sure if it was complete hosted implementation.

Are you sure these are hosted implementations?  Do they provide a
complete and meaningful implementation of the standard C library and do
executables produced by them run under an operating system?

An operating system meaningfully supporting functions like fopen, remove
and rename is very likely to provide a method of accessing the names of
the files that already exist (even if this implies reading raw disk
sectors or tape blocks).  And this is all that is needed to implement
the POSIX.1 directory handling functions.  Even if the OS doesn't
support the concept of directory tree, i.e. all the files are in one
place, as it was the case in CP/M-80 and MSDOS 1.

Quote:
>My general experience is that hosted ANSI-C implementations for specific
>rare hardware lack the comfort of any but the minimum requirements.

My general experience is that hosted ANSI-C implementations do provide
an interface to the underlying operating system that is hosting the
implementation.  And this is usually enough to implement the functions
we're talking about.

Quote:
>> As for the availability of these functions, the FAQ claims that:

>>     Implementations also exist for MS-DOS, VMS, and other systems.

>OK, but one closing remark about my pointless point: no I am not a C
>implementor and I might lack special knowledge of finer and finest
>destinctions.

The distinction between "provide" and "support" is not that fine.

Quote:
>I just saw a statement that broadly declassified all C
>compilers without some special non ANSI-C extension as being "not
>decent".

This would have been the case if the original poster wrote "provide"
instead of "support".  But he didn't.  Before replying to a post, try
to understand what the poster actually wanted to say.  It's neither the
first nor the last occasion when you reacted after a very superficial
reading of the text you're replying to.

Quote:
>knowledge and experience. I just thought it's worth pointing out that my
>reply was not just some quick flame without at least some thought to it)

I am even more convinced, now, after reading this post, that it *was* a
quick flame without some thought to it.  Proof: by your own admission,
you reacted to what you perceived as an insult to your compilers and
not to the actual contents of the original post.

I agree with the original poster: a C compiler which doesn't give you
direct access to the services of the underlying operating system is not
decent.  I have never such seen such an implementation, and I've used ones
for very spartan environments (e.g. ZX-Spectrum or CP/M-80).

For freestanding environments, it doesn't make much sense talking about
how to read a directory, so it is pointless to argue that you can't
implement opendir() there.

Dan
--
Dan Pop
CERN, IT Division

Mail:  CERN - EP, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland



Sat, 21 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc


Quote:

>:I have a question about malloc:::
>: [snip] but I
>:want to do the same with a multidimensional char array, like this:
>:char[number of string][size of each string];

>As far as I know, there is no way to malloc() a *genuine* multidimensional
>array.

C doesn't support multidimensional arrays at all so it is unclear what
"a *genuine* multidimensional array" means in the context of C. What C
does support is arrays of arrays (or arrays etc.) such as

   int array3[XDIM][YDIM][ZDIM];

You certainly can create a datastructure of this form using malloc:

   int (*ptr3)[YDIM][ZDIM] = malloc(XDIM * sizeof *ptr3);

   if (ptr3 == NULL) { /* Allocation failed */ }

The two arrays (array3 and the one created using malloc) are laid out
in the same way in memory. The only difference is that the malloc'd
array doesn't have a name so must be accessed through an auxiliary pointer,
and is released using free(). The malloc'd array can be accesses using
ptr3[x][y][z] i.e. similarly to array3[x][y][z].

--
-----------------------------------------


-----------------------------------------



Sat, 21 Apr 2001 03:00:00 GMT  
 Malloc 2: The revenge of Malloc
Dammit... the original post in this thread is gone. So bear in mind I
haven't got that to refer back to...
:C doesn't support multidimensional arrays at all so it is unclear what
:"a *genuine* multidimensional array" means in the context of C.

Chris Torek has already slapped my hands for this mistake. It was sloppy use
of language- I meant arrays of arrays, but functionally, I tend to consider
them as multidimensional arrays.
No misleading indoctrination of newbies intended ;-)

However, I hope I'm correct in saying that there's no way to dynamically
allocate a genuine array (of whatever type, including another array) at
runtime.


  (Remove "BYESPAM" spam filter when replying by mail)



Sun, 22 Apr 2001 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. malloc vs 'no-malloc' - help

2. C question : redefining a new malloc() calling standard malloc()

3. to malloc() or not to malloc(), that is the question

4. malloc crashes - malloc(256) returns 0(!) (_MT)

5. To malloc or not to malloc, that's the question!

6. memory to free or not to free, to malloc or not to malloc ?

7. To malloc (new) or not to malloc? When is the question.

8. malloc & free in c#

9. Override malloc,calloc,realloc and free?

10. std::bad_alloc ctor calls malloc????

11. Crash in Malloc

12. STL in managed C++ crashing in malloc.c and keeping chars from becoming SBytes

 

 
Powered by phpBB® Forum Software