seema wrote:

> (gdb)
> 406 buf = (char *) malloc((nSize+1)*sizeof(char));
> (gdb)
> 407 szMessage = (char *) malloc((nSize+1)*sizeof(char));
> (gdb) p szMessage
> $3=0xa0a0990 "02137A02137A--14-140-75-75-c-80-edc-edctech"
> (gdb) p buf
> $4 = 0xa098988 "02137A02137A)"
>
> Is it perfectly normal ? I think if I print it should show

> ""

No, gdb is right. Since you only allocate with malloc, the address malloc
returns points to an uninitialized area of memory. There can be everything
within it, most likely the content of a block which was allocated in the
same place before (and was freed before).
To initialise the memory you can use memset().

lg,
Michael

seema wrote:
> Hi all,
>
> I am new to unix programming I was debugging a problem on linux.
> surprisingly after allocating memory to a pointer I am getting strange
> behaviour,
>
> (gdb)
> 406 buf = (char *) malloc((nSize+1)*sizeof(char));
> (gdb)
> 407 szMessage = (char *) malloc((nSize+1)*sizeof(char));
> (gdb) p szMessage
> $3=0xa0a0990 "02137A02137A--14-140-75-75-c-80-edc-edctech"
> (gdb) p buf
> $4 = 0xa098988 "02137A02137A)"
>
> Is it perfectly normal ? I think if I print it should show

> ""
>
> Thanks
> Seema
>
As noted before GDB is correct. If you want the memory initialized you
can use 'calloc', or 'malloc' with a 'memset' call

-Jim

On Oct 25, 3:57 am, seema wrote:
> Hi all,
>
> I am new to unix programming I was debugging a problem on linux.
> surprisingly after allocating memory to a pointer I am getting strange
> behaviour,
>
> (gdb)
> 406 buf = (char *) malloc((nSize+1)*sizeof(char));
> (gdb)
> 407 szMessage = (char *) malloc((nSize+1)*sizeof(char));
> (gdb) p szMessage
> $3=0xa0a0990 "02137A02137A--14-140-75-75-c-80-edc-edctech"
> (gdb) p buf
> $4 = 0xa098988 "02137A02137A)"
>
> Is it perfectly normal ? I think if I print it should show

> ""
>
> Thanks
> Seema

It *is* showing the address:
(gdb) p szMessage
$3=0xa0a0990 "02137A02137A--14-140-75-75-c-80-edc-edctech"
The address of szMessage is 0xa0a0990
Since szMessage is (presumably) of type "char *", the debugger also
tries to show the string stored there. As others have pointed out,
you haven't stored anything there yet, so what's there is what
happened
to be there the last time that space was used, which happens to
contain
the characters
02137A02137A--14-140-75-75-c-80-edc-edctech
through the first occurrance of a nul character.
--
Fred Kleinschmidt

Jim Marshall writes:

> seema wrote:
>> I am new to unix programming I was debugging a problem on linux.
....
>> 406 buf = (char *) malloc((nSize+1)*sizeof(char));
....
> As noted before GDB is correct. If you want the memory initialized
> you can use 'calloc', or 'malloc' with a 'memset' call

In addition, note that casting malloc return value in C is
unnecessary, and frequently hides bugs. Don't do that.

If compiler gives you warnings about assigning pointer to integer,
then you are missing '#include '

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

On Thu, 25 Oct 2007 07:51:20 -0700, fred.l.kleinschmidt@boeing.com
wrote:

>On Oct 25, 3:57 am, seema wrote:
>>
>> 407 szMessage = (char *) malloc((nSize+1)*sizeof(char));
>> (gdb) p szMessage
>> $3=0xa0a0990 "02137A02137A--14-140-75-75-c-80-edc-edctech"
>> (gdb) p buf
>> $4 = 0xa098988 "02137A02137A)"
>>
>> Is it perfectly normal ? I think if I print it should show

>> ""

>It *is* showing the address:
> (gdb) p szMessage
> $3=0xa0a0990 "02137A02137A--14-140-75-75-c-80-edc-edctech"
>The address of szMessage is 0xa0a0990


Actually, the address _contained within_ szMessage is 0xa0a0990, since
that's the whole point of the "szMessage = malloc(...)" statement.

And it probably shouldn't be called szMessage (zero-terminated
string), but rather pcMessage (pointer-to-char) or possibly pszMessage
(pointer-to-zero-terminated string).

And I'm astonished that no-one's whinged about the "sizeof(char)" in
the malloc statement since sizeof(char) is guaranteed always to be 1,
as stipulated in http://www.faqs.org/faqs/C-faq/faq/ section 7.8 :-)


Good grief, I'm bored this afternoon!

--
PGP key ID 0xEB7180EC

On Oct 25, 11:12 am, Keith Willis wrote:
> On Thu, 25 Oct 2007 07:51:20 -0700, fred.l.kleinschm...@boeing.com
> wrote:
>
> >On Oct 25, 3:57 am, seema wrote:
>
> >> 407 szMessage = (char *) malloc((nSize+1)*sizeof(char));
> >> (gdb) p szMessage
> >> $3=0xa0a0990 "02137A02137A--14-140-75-75-c-80-edc-edctech"
> >> (gdb) p buf
> >> $4 = 0xa098988 "02137A02137A)"
>
> >> Is it perfectly normal ? I think if I print it should show

> >> ""
> >It *is* showing the address:
> > (gdb) p szMessage
> > $3=0xa0a0990 "02137A02137A--14-140-75-75-c-80-edc-edctech"
> >The address of szMessage is 0xa0a0990
>
>
> Actually, the address _contained within_ szMessage is 0xa0a0990, since
> that's the whole point of the "szMessage = malloc(...)" statement.

Well put!


> And it probably shouldn't be called szMessage (zero-terminated
> string), but rather pcMessage (pointer-to-char) or possibly pszMessage
> (pointer-to-zero-terminated string).

Frankly, the name that the programmer selected for that (or any other
variable) is up to the programmer and his (or her) related standards.
Apparently, the standard /you/ use requires prefixes on variable
names, with the prefix providing some sort of (unenforcable) type
qualification. Your standards are not /the/ standards. For all you
know, the programmer has followed a naming standard that requires all
variables that store malloc()ed values to start with a lower case 's',
or even that the programmer will later use this malloc()ed area to
store a text error message (a la IBM's prefix qualified error
messages) that starts with the letters "sz". ;-)

> And I'm astonished that no-one's whinged about the "sizeof(char)" in
> the malloc statement since sizeof(char) is guaranteed always to be 1,
> as stipulated inhttp://www.faqs.org/faqs/C-faq/faq/section 7.8 :-)

You are right. However, not because of the strength of the C FAQ, but
because of the strength of the C language definition. sizeof(char) is
guaranteed, by the official definition of the ISO C language (C89 and
C99) to be exactly 1. The number of bits in a char is implementation-
dependant (again, by the ISO C language standard) and must be /at a
minimum/ 8 bits. A char /can be/ more than 8 bits long.

>
>
> Good grief, I'm bored this afternoon!
>
> --
> PGP key ID 0xEB7180EC

fred.l.kleinschmidt@boeing.com wrote:
> On Oct 25, 3:57 am, seema wrote:
>> Hi all,
>>
>> I am new to unix programming I was debugging a problem on linux.
>> surprisingly after allocating memory to a pointer I am getting strange
>> behaviour,
>>
>> (gdb)
>> 406 buf = (char *) malloc((nSize+1)*sizeof(char));
>> (gdb)
>> 407 szMessage = (char *) malloc((nSize+1)*sizeof(char));
>> (gdb) p szMessage
>> $3=0xa0a0990 "02137A02137A--14-140-75-75-c-80-edc-edctech"
>> (gdb) p buf
>> $4 = 0xa098988 "02137A02137A)"
>>
>> Is it perfectly normal ? I think if I print it should show

>> ""

> It *is* showing the address:

I think the original poster meant to emphasize that he expected it
to show an empty string (hence the '""') *after* the address.
However, apparently his Usenet reader wrapped the text at an
inopportune spot.

- Logan

seema wrote:
> Hi all,
>
> I am new to unix programming I was debugging a problem on linux.
> surprisingly after allocating memory to a pointer I am getting strange
> behaviour,
>
> (gdb)
> 406 buf = (char *) malloc((nSize+1)*sizeof(char));
> (gdb)
> 407 szMessage = (char *) malloc((nSize+1)*sizeof(char));
> (gdb) p szMessage
> $3=0xa0a0990 "02137A02137A--14-140-75-75-c-80-edc-edctech"
> (gdb) p buf
> $4 = 0xa098988 "02137A02137A)"
>
> Is it perfectly normal ? I think if I print it should show

> ""

Why would you expect the memory to contain an empty string? Is it
because you expect the allocated memory to be filled with zero bytes?
And if you expect that, why would you assume you are going to get
zero bytes when the documentation doesn't say that you do?

- Logan

Lew Pitcher wrote:

> because of the strength of the C language definition. sizeof(char) is
> guaranteed, by the official definition of the ISO C language (C89 and
> C99) to be exactly 1. The number of bits in a char is implementation-
> dependant (again, by the ISO C language standard) and must be /at a
> minimum/ 8 bits. A char /can be/ more than 8 bits long.

True for C in general, but since this is a UNIX newsgroup it is
worth noting that the current UNIX/POSIX standard requires char to
have exactly 8 bits. (On older UNIX/POSIX systems it can have more
than 8 bits.)

--
Geoff Clare

In <1193309838.530267.51520@i13g2000prf.googlegroups.c om> seema writes:

> (gdb)
> 406 buf = (char *) malloc((nSize+1)*sizeof(char));
> (gdb)
> 407 szMessage = (char *) malloc((nSize+1)*sizeof(char));
> (gdb) p szMessage
> $3=0xa0a0990 "02137A02137A--14-140-75-75-c-80-edc-edctech"
> (gdb) p buf
> $4 = 0xa098988 "02137A02137A)"

> Is it perfectly normal ? I think if I print it should show

> ""

Yes, it's normal. You allocated space but you didn't initialize it, so
it contains whatever random collection of characters happened to
sitting at that memory location.

If you want to initialize the malloced area to be an empty string, do it
yourself.

--
John Gordon A is for Amy, who fell down the stairs
gordon@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"