char *ptr="some stupid string";
char array[]="some stupid string";

First, when a char pointer is initialized with a string, is sufficient
memory allocated?  Aside from "ptr" being an lvalue, while "array" is
only an rvalue, is there any other difference between "ptr" and "array"?

void foo(char *ptr);      // function prototype

void main(void)
{
        foo("literal string");

Last, I have written programs which (successfully) use free() to
release calloc()'d memory (as opposed to using cfree() to release
the memory). What are the differences between these two functions?
I believe that calloc() is nearly identical to (and probably uses)
malloc(), so is this practice really acceptable?

Thanks alot.

So in your first example, the string is put somewhere [it doesn't
matter where, but it generally wont get erased] and ptr is
initialised with a pointer to the first character of the string,
whereas for the array the individual elements of the array are
intialised with the characters of your string.  

In the second, a STATIC copy of the string is stored at compile
time somewhere in your program, and code is compiled to pass
a pointer to the first character of "literal string" to foo().
Strings are not generally pushed on and off stacks, except when
initialising auto (the default storage for local variables)
character arrays in ANSI C. I hope that answers your question.
If foo actually changes a character in your string, then the
next time that actual statement is re-run, the revised string
will be passed to foo().

But if you wanted to allocate space for 100 long ints, you'd write:
        ptr = calloc(sizeof(long int), 100)

I may have got the parameters the wrong way round for calloc(), but
in practise it rarely matters as calloc usally looks like this:

void /* or char in K&R C */ *calloc(us,no)
int us,no;
{
        return malloc(us*no);

Paul Harrison

[Opinions are mine, not UEA's]

Related to this question is the old 'what happens if I have an array
allocated in one file, and give an extern reference as a POINTER in
another source file?'

$ cat 1.c
char array[1024];
$ cat 2.c
extern char *array;

file 2.c is incorrect.

$ cat 2.a.c
extern char array[];

is correct (assuming these 2 files are linked together).
--

Terry Gardner | The Home Depot, Inc. | One Paces West
2727 Paces Ferry Road, NW | Atlanta, GA
Voice (404)433-8211x5124

        char *cptr;
        cptr = "hello";

since cptr is a char pointer, "hello" must be also...

--
==============================================================================
#include <std/disclaimer.h>

           Jim Jagielski                    NASA/GSFC, Code 711.4

         "Ah! I see you have the machine that goes 'BING!'"

(Questions deleted her, not really relevant to this posting)

|> cfree() and free(): not much except that cfree() isn't in the ANSI
|> library, so use free().
|> malloc() and calloc(): these are similar, malloc allocates bytes
|> whereas calloc allocates units. malloc needs one parameter, being
|> the number of bytes. calloc needs two: the size of each unit in
|> bytes and the number of units. So if you wanted to allocate space
|> for a [sorry, read 'char's, not 'byte's.] hundred chars, you'd
|> write   ptr = malloc(100)
|>
|> But if you wanted to allocate space for 100 long ints, you'd write:
|>   ptr = calloc(sizeof(long int), 100)

Also, calloc is guaranteed to initialize the allocated space to all zeros,
whereas malloc does not. (The 'c' standing for 'clear' ?)

|>
|> I may have got the parameters the wrong way round for calloc(), but
|> in practise it rarely matters as calloc usally looks like this:

Yes, reverse the order, ptr = calloc(100, sizeof(ling int));

|> void /* or char in K&R C */ *calloc(us,no)
|> int us,no;
|> {
|>   return malloc(us*no);
|> }
|

More like

void *calloc(size_t nobj, size_t size)
{       void *ptr;

        ptr = malloc(nobj * size);
        if(ptr) memset(ptr, 0, nobj * size);

        return ptr;

Opinions are mine ?
------------------------------------------------------------



------------------------------------------------------------
"Ohm, sweet ohm"                                 (Kraftwerk)

Warner
--

"Red hair is caused by sugar and lust," the woman, who was blond, confided.
"Highly evolved beings do not indulge in sugar and lust." -- Tom Robbins

        Sudheer.
------------------
...{harvard, uunet}!andrew.cmu.edu!sa1z

In answer to your first question, most compilers should treat the
two strings identically (although I have used some cross compilers
which do not -- i.e. ASCII data gets pushed on the call stack
instead of the address of the string...), and if they don't, then
they (the compilers) are in error.  When you use a string literal
in a program, such as "some stupid string", the compiler will store
that data within the program, so no space needs to be "allocated" per
se;  rather, that string has an address in the program's data space.

Secondly, when you pass the literal string to a function expecting
a char pointer, nothing as elaborate as you have hypothesized happens.
The literal string (i.e. "literal string") will be put into the
program's data space (as above) and the address to that data space
will be passed to the function -- i.e. the function will get a char
pointer to the area that the compiler put your literal string into.
The thing to keep in mind is that unless your compiler is _VERY_
smart, each time you use a literal string space will be used for
it in the progam's data space, even if the strings are the same.  In
other words, if your function calls foo("literal string") three
different times, three separate instances of the string "literal
string" will exist in your program's data space, and foo will get
a different pointer value for each call.

Finally, memory allocation schemes are machine dependent.  However,
in most schemes that I have seen, calloc() will call malloc, and
then explicitly clear all of the bytes that you asked for.  Since
I am not familiar with cfree() (I think your compiler's libs may
have some non-standard extensions...), I can't comment too generally
on that.  But, given that most calloc's operate in the manner that
I have stated, then free() should work just fine.

You may wish to use your compiler's option to produce assembly
output in the future;  this way, you can see exactly what the
machine/program is doing.  Of course, you could always use the
#pragma dwim (do what I mean) :=)

---------------------------------------------------------------------
-Jefrem M. Iwaniw, Sr. Consultant, Pelican Software   0
"To know even one life has breathed easier because  _/ \
 you have lived;  This is to have succeeded."      (_)
                         -Ralph Waldo Emerson       |_
My own opinions, not my clients'.
---------------------------------------------------------------------

Bossman> malloc() and calloc() are similar, except that calloc()
Bossman> actually clears the memory that is allocated to all zeros.
Bossman> This is very useful for allocating arrays of NULL pointers.

RE> Actually, it's quite useless for doing that.  All zeroes is not the
RE> same as a NULL pointer.

Well, if you accept K&R as an authority, you can assume that NULL
is the integer 0 as far as the compiler is concerned.  I'll quote
gratuitously:

K&R ed. 1 page 192:

Of course, it's possible there are a few compilers floating around
that don't store null pointers as zeroed memory.  I'm interested in
knowing if anyone out there finds one.

#include <stdio.h>

main() {
    char **p;

    p = (char **) calloc(1, sizeof(char *));
    if (*p == NULL) {
        puts("Zeroed memory functions as NULL pointer.");
    } else {
        puts("Zeroed memory does not function as NULL pointer.");
    }

Greg Hudson

You have to be careful when using literal strings, since only enough space to
hold all of the string's data and the null terminator are alloccated by the
compiler, so if you attempt to concatenate another string to a literal string
(or use any function that adds characters to the string), you will actually
be overwriting other memory in your global data space. Thus if you wish to
add something to the end of the string "some stupid string", you would have
to do it like so:

char array[255] = "some stupid string";

...

        strcat(array," This is added!!");

+------------------------------------------+----------------------------------+
| Kendall Bennett,                         | Internet:                        |



+------------------------------------------+----------------------------------+
| CoSysop (Bossman), PC Connection Australia:                  +61 3 688 0909 |
+-----------------------------------------------------------------------------+

John Boutland.

Bossman> malloc() and calloc() are similar, except that calloc()
Bossman> actually clears the memory that is allocated to all zeros.
Bossman> This is very useful for allocating arrays of NULL pointers.

Actually, it's quite useless for doing that.  All zeroes is not the
same as a NULL pointer.

--

A null pointer might be represented by all bits zero, but it need not.

When assigning or casting a constant zero to a pointer, the compiler
is obligated to generate the correct representation for a null pointer
of that type -- which might or might not be all bits zero.

So, if T is a some type,

        /* p becomes a null pointer of type T* */
        T* p = 0;

        /*  p gets all bits zero, which might not be a null pointer */
        T* p = calloc(1, sizeof(T*));

        /*  p gets all bits zero, which might not be a null pointer */
        int i = 0;
        T* p = i;       /* 'i' is not a constant zero */
--

{uunet,harvard}!think!barmar