Re: [vox-tech] malloc() is ... old school?
On Fri, Mar 21, 2003 at 03:41:39PM -0800, Tim Riley wrote:
>
>
> "Micah J. Cowan" wrote:
>
> > On Fri, Mar 21, 2003 at 02:45:37PM -0800, Tim Riley wrote:
> > >
>
>
>
> > void **memory;
> > memory = calloc(1, sizeof *memory);
> > if (*memory) ...
> >
>
> vs.
>
> PERSON *person = (PERSON *)calloc( 1, sizeof( PERSON ) );
>
> if ( person->zip_code )
> {
> printf( "The zip code is populated with %s\n",
> person->zip_code );
> }
>
> My assertion is that the sky is blue, and your argument is
> no, the grass is green.
>
Do you even bother to read my posts? The above quote from me was *not*
an example of how to initialize (*memory) to NULL. Read the context.
This thread is over. I am rather insulted that you have repeatedly
refused to read what I write, assuming that I've said whatever you
thought I was going to say, and quoting me out of context.
-Micah
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
"Micah J. Cowan" wrote:
> On Fri, Mar 21, 2003 at 02:45:37PM -0800, Tim Riley wrote:
> >
> void **memory;
> memory = calloc(1, sizeof *memory);
> if (*memory) ...
>
vs.
PERSON *person = (PERSON *)calloc( 1, sizeof( PERSON ) );
if ( person->zip_code )
{
printf( "The zip code is populated with %s\n",
person->zip_code );
}
My assertion is that the sky is blue, and your argument is
no, the grass is green.
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
On Fri, Mar 21, 2003 at 02:45:37PM -0800, Tim Riley wrote:
>
>
> Jeff Newmiller wrote:
>
> > On Fri, 21 Mar 2003, Tim Riley wrote:
> >
>
>
>
> >
> > > >
> > > > Especially this one by the author of the FreeBSD C Library (last paragraph):
> > > >
> > > > http://groups.google.com/groups?q=NULL+calloc()+group:comp.lang.c+author:Chris+author:Torek&selm=18764%40dog.ee.lbl.gov
> >
> > Tim, I don't get the impression you actually read this last URL.
> >
>
> Very true -- too many words. My simple mind looks for simple explanations
> located in simple sentences.
>
> The truth of the matter is that I've never been
> burned using the following code:
>
> char *memory = (char *)0;
>
> if ( !memory )
> {
> printf( "memory is not set\n" );
> }
Neither have I, nor will either of us. This has nothing to do with
what we've been discussing. The above is 100% guaranteed to do what
you expect by the ISO standard. Setting it via calloc() or memset()
would not be.
On a system which does not represent the null pointer as all-bits
zero, the above code would automatically convert the integer value 0
to the appropriate representation. This is required even without the
explicit casst to (char*).
Likewise, when you test it in the if statement, the null pointer is
required to compare equal to zero, and !memory is required to be
false. This is not being debated here.
What I have been trying to communicate in my posts, but clearly
failing somehow, is that
void **memory;
memory = malloc(sizeof *memory);
*memory = 0;
if (*memory) ...
which is perfectly fine (assuming the appropriate test of malloc()'s
return), is *not* the same as:
void **memory;
memory = calloc(1, sizeof *memory);
if (*memory) ...
which is not fine. No automatic conversion is required (or even
allowed) in the latter case, so *memory is not guaranteed to hold a
null pointer.
You clearly have not bothered reading anything I'm posting, so I might as
well discontinue posting.
> Is this your point?
No. Read my posts to find my point.
> If it is, this contradicts "The C Programming Language -- ANSI C"
> by Kernighan and Ritchie on page 102. It says, "...the constant zero
> may be assigned to a pointer, and a pointer may be compared with
> the constant zero. The symbolic constant NULL is often used in place
> of zero as a mnemonic to indicate more clearly that this is a special value
> for a pointer."
Which is what I've been saying all along. Note especially, the key
phrase "zero... is a special value for a pointer."
> This implies that NULL always equals zero.
Yes.
> Therefore, it is safe to use calloc() to allocate memory to
> structures with pointers and use those pointers in
> "if" statements like this:
No. That NULL always compares equal to zero does *not* mean that it is
represented the same as integer zero.
Assigning zero to a pointer variable is not the same as setting its
bits to zero, or setting it to the same internal representation as an
integer whose value is zero.
-Micah
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
Jeff Newmiller wrote:
> On Fri, 21 Mar 2003, Tim Riley wrote:
>
>
> > >
> > > Especially this one by the author of the FreeBSD C Library (last paragraph):
> > >
> > > http://groups.google.com/groups?q=NULL+calloc()+group:comp.lang.c+author:Chris+author:Torek&selm=18764%40dog.ee.lbl.gov
>
> Tim, I don't get the impression you actually read this last URL.
>
Very true -- too many words. My simple mind looks for simple explanations
located in simple sentences.
The truth of the matter is that I've never been
burned using the following code:
char *memory = (char *)0;
if ( !memory )
{
printf( "memory is not set\n" );
}
If instead the code were:
char *memory = (char *)0;
if ( memory != NULL )
{
printf( "memory is not set\n" );
}
else
{
printf( "NULL is defined as %d\n", NULL );
}
and a number were outputted, then calloc() alone will not
suffice as a memory allocation function.
Then the following would be required:
char *memory = NULL;
if ( memory != NULL )
{
printf( "memory is not set\n" );
}
Is this your point?
If it is, this contradicts "The C Programming Language -- ANSI C"
by Kernighan and Ritchie on page 102. It says, "...the constant zero
may be assigned to a pointer, and a pointer may be compared with
the constant zero. The symbolic constant NULL is often used in place
of zero as a mnemonic to indicate more clearly that this is a special value
for a pointer."
This implies that NULL always equals zero. Therefore,
it is safe to use calloc() to allocate memory to
structures with pointers and use those pointers in
"if" statements like this:
PERSON *person = (PERSON *)calloc( 1, sizeof( PERSON ) );
if ( !person )
{
fprintf( stderr,
"Memory allocation failed in %s/%s()\n",
__FILE__, __FUNCTION__ );
exit( 1 );
}
if ( person->zip_code )
{
printf( "The zip code is populated with %s\n",
person->zip_code );
}
else
{
printf( "The zip code is not populated.\n" );
}
and the behavior will be the not populated statement outputted.
It is my preference to use calloc() alone instead of malloc() with
a bunch of initializations to avoid unnecessary typing.
>
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
On Fri, Mar 21, 2003 at 01:01:39PM -0800, Jeff Newmiller wrote: > > > > > > And I submit that without the core dump, the bug of having forgotten > > > to set *person's fields just got much, much harder to track down. > > > > > > > Core dumps are useful for tracking down bugs. > > While I am not very comfortable with bunches of NULL pointers in records, > I am not sure that depending on the garbage in a malloc'd memory block to > be non-NULL is a good idea either. No, it's not. But it is at least a good deal more likely to be non-NULL. But you're right: a more reliable way to ensure core dumps when you make an error of this sort is to *specifically* initialize all values to something you *know* will dump core. I've heard from people that do this. Of course, this really doesn't get you anywhere, since you could forget to initialize your pointers to garbage just as easily as you can forget to initialize them to something more meaningful. And linking with electric fence will get you about the same level of reliability, with much less work. Turning on -W -Wall -O2 and not ignoring the resulting warnings can be very helpful for detecting initialization problems, too. But I still prefer the direct, blunt forcefulness that a core dump presents... :-) -Micah ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
On Fri, 21 Mar 2003, Tim Riley wrote:
>
>
> "Micah J. Cowan" wrote:
>
> > On Thu, Mar 20, 2003 at 04:52:15PM -0800, Tim Riley wrote:
> > >
> > >
> > > "Micah J. Cowan" wrote:
> > >
> > > > On Thu, Mar 20, 2003 at 10:15:43AM -0800, Tim Riley wrote:
> > > > >
> >
> > >
> > > The vulnerability with malloc() occurs when working with pointers.
> > > It's common to test if a pointer has been set
> > > by placing it inside an "if" statement before referencing it.
> > > If you always use calloc(), all of your pointers will be
> > > initialized with zero.
> >
> > All bits zero != NULL. This is a common misbelief, which happens to be
> > true on a number of platforms. But it is not guaranteed to be true,
> > and is not on several platforms, though I conced that they are not the
> > mainstream. See:
> >
> > Sec. 5 of the C FAQ: ~http://www.eskimo.com/~scs/C-faq/s5.html
> >
> > Any number of comp.lang.c posts:
> > http://groups.google.com/groups?as_q=NULL%20calloc%28%29&as_ugroup=comp.lang.c
> >
> > Especially this one by the author of the FreeBSD C Library (last paragraph):
> >
> > http://groups.google.com/groups?q=NULL+calloc()+group:comp.lang.c+author:Chris+author:Torek&selm=18764%40dog.ee.lbl.gov
Tim, I don't get the impression you actually read this last URL.
> >
> >
>
> "man calloc" on a Linux machine says bluntly:
>calloc() allocates memory for an array of nmemb elements
>of size bytes each and returns a pointer to the allocated
>memory. The memory is set to zero.
>
>malloc() allocates size bytes and returns a pointer to the
>allocated memory. The memory is not cleared.
I am not sure what you are trying to demonstrate by citing the man pages
from a particular (unspecified) distribution... because such documentation
can at best be specific to that installation, and at worst may indicate
nothing about how the Standard C _library_ should behave.
That said, I haven't seen anyone asserting that calloc _doesn't_ set the
memory to zero. Micah's point is that a pattern of zero bits is not the
same as NULL in every case. I would warn that this is also technically
true for floating point values. (Subtle point: assigning the numeric value
of zero to a pointer _is_ required to result in a NULL pointer, but the
compiler may treat this as a special case.)
>
>
> > > For the following example
> > > it's clear that a core dump might occur; however, if the program were
> > > 1000 lines long and the variables set in different locations, tracing
> > > could be a bear.
> > >
> > > typedef struct
> > > {
> > > char *name;
> > > char *address;
> > > char *city;
> > > char *state;
> > > char *zip_code;
> > > } PERSON;
> > >
> > > int main( int argc, char **argv )
> > > {
> > > PERSON *person = malloc( sizeof( PERSON ) );
> > >
> > > person->name = "fred";
> >
> > A core dump could occur right here, with or without calloc(),
> > considering you didn't check malloc()'s return.
>
> Allocation error checking was intentionally left out for simplicity.
>
> >
> >
> > > if ( person->name && person->zip_code )
> > > {
> > > printf( "For person = %s, got zip code = %s\n",
> > > person->name, person->zip_code );
> > > }
> > > }
> > >
> > > If calloc() had been used, no one would have noticed the delay and no
> > > core would be dumped.
> >
> > Provided that one is using a system on which NULL happens to be
> > all-bits-zero.
>
> What ANSI C implementation are you referring to here?
The issue is what hardware the ANSI C implementation has to work with.
Apparently both Data General and Control Data Corporation both made
hardware that behaved this way. Also apparently they included some
run-time code to fix pointers that made this assumption because it was
just too pervasive in available source code.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=486%40sas.UUCP
There may be other examples... it isn't really that important to me. What
is important is what the Standard says.
> > Which we all are on this list, but can we guarantee
> > that the code you write won't be ported to such a system?
> >
>
> Isn't this a Linux users group?
Yes. What does that have to do with the hardware you run Linux on?
> What system are you referring to?
See above. I have not encountered either of these systems... but I try to
be careful to segregate code that is system dependent from code that
conforms strictly to standards, as a matter of good practice.
There are thousands of application programming interfaces out there, and
using them creates dependencies. Programming in the large leads you to
seriously consider how many APIs you want to depend on... because of
code bloat, and because of potential future porting efforts. Part of
succeeding at that is using your standard interfaces to their utmost... so
knowing Standard C is worthwhile no matter what system you use... even
Linux.
> Does it not have gcc? Is
Re: [vox-tech] malloc() is ... old school?
On Fri, Mar 21, 2003 at 11:22:56AM -0800, Tim Riley wrote:
>
>
> "Micah J. Cowan" wrote:
>
> > On Thu, Mar 20, 2003 at 04:52:15PM -0800, Tim Riley wrote:
> > >
> > >
> > > "Micah J. Cowan" wrote:
> > >
> > > > On Thu, Mar 20, 2003 at 10:15:43AM -0800, Tim Riley wrote:
> > > > >
> >
> > >
> > > The vulnerability with malloc() occurs when working with pointers.
> > > It's common to test if a pointer has been set
> > > by placing it inside an "if" statement before referencing it.
> > > If you always use calloc(), all of your pointers will be
> > > initialized with zero.
> >
> > All bits zero != NULL. This is a common misbelief, which happens to be
> > true on a number of platforms. But it is not guaranteed to be true,
> > and is not on several platforms, though I conced that they are not the
> > mainstream. See:
> >
> > Sec. 5 of the C FAQ: ~http://www.eskimo.com/~scs/C-faq/s5.html
> >
> > Any number of comp.lang.c posts:
> > http://groups.google.com/groups?as_q=NULL%20calloc%28%29&as_ugroup=comp.lang.c
> >
> > Especially this one by the author of the FreeBSD C Library (last paragraph):
> >
> > http://groups.google.com/groups?q=NULL+calloc()+group:comp.lang.c+author:Chris+author:Torek&selm=18764%40dog.ee.lbl.gov
> >
> >
>
> "man calloc" on a Linux machine says bluntly:
>calloc() allocates memory for an array of nmemb elements
>of size bytes each and returns a pointer to the allocated
>memory. The memory is set to zero.
>
>malloc() allocates size bytes and returns a pointer to the
>allocated memory. The memory is not cleared.
Yes. And?
What have I said that disagrees with this?
As I've already said, "zero" != NULL. Read my comment again.
> > > For the following example
> > > it's clear that a core dump might occur; however, if the program were
> > > 1000 lines long and the variables set in different locations, tracing
> > > could be a bear.
> > >
> > > typedef struct
> > > {
> > > char *name;
> > > char *address;
> > > char *city;
> > > char *state;
> > > char *zip_code;
> > > } PERSON;
> > >
> > > int main( int argc, char **argv )
> > > {
> > > PERSON *person = malloc( sizeof( PERSON ) );
> > >
> > > person->name = "fred";
> >
> > A core dump could occur right here, with or without calloc(),
> > considering you didn't check malloc()'s return.
>
> Allocation error checking was intentionally left out for simplicity.
Okay: but considering the message you were trying to send, it helps a
little to include a comment to this effect.
> > > if ( person->name && person->zip_code )
> > > {
> > > printf( "For person = %s, got zip code = %s\n",
> > > person->name, person->zip_code );
> > > }
> > > }
> > >
> > > If calloc() had been used, no one would have noticed the delay and no
> > > core would be dumped.
> >
> > Provided that one is using a system on which NULL happens to be
> > all-bits-zero.
>
> What ANSI C implementation are you referring to here?
These: http://www.eskimo.com/~scs/C-faq/q5.17.html
Unsure whether these are all ISO C, but it really doesn't matter. The
fact that it is allowed by the ISO C standards ought to be enough for
a portability-minded programmer to avoid assuming that a calloc()'d
pointer will be NULL.
>
> > Which we all are on this list, but can we guarantee
> > that the code you write won't be ported to such a system?
> >
>
> Isn't this a Linux users group? What system are you referring to?
Yes; but is this thread only about ISO C implementations for Linux, or
is it about the ISO C language itself? If the former is our only
consideration, then I apologize for making an issue out of this: you
may employ whatever system-specific coding conventions you wish.
> Does it not have gcc? Is it open source so we can fix it?
"Fix it?" Why fix an ISO-conformant C implementation? On any systems
which have such a C implementation, the reason is most likely that the
system already has its own convention for how the null pointer should
be represented; "fixing" it would be ill-advised. In any case, as long
as you are coding properly, it should never be an issue: converting a
zero-value integer to a pointer will still yield the null pointer
value; and null pointers will always compare equal to the integer 0
regardless of how the null pointer is represented internally. These
are ISO requirements. What's not an ISO requirement is that something
like:
memset(ptr_ptr, 0, sizeof *ptr_ptr);
or:
ptr_ptr = calloc(1, sizeof *ptr_ptr);
leaves ptr_ptr[0] as a null pointer.
>
> >
> > And I submit that without the core dump, the bug of having forgotten
> > to set *person's fields just got much, much harder to track down.
> >
>
> Core dumps are useful for tracking down bugs.
>
Exactly. So why use a coding style which would silently hide the bug
of having forgotten to properly set (*person)'s fields, possibly
wreaking havoc in much more sinister and subtle ways, instea
Re: [vox-tech] malloc() is ... old school?
"Micah J. Cowan" wrote:
> On Thu, Mar 20, 2003 at 04:52:15PM -0800, Tim Riley wrote:
> >
> >
> > "Micah J. Cowan" wrote:
> >
> > > On Thu, Mar 20, 2003 at 10:15:43AM -0800, Tim Riley wrote:
> > > >
>
> >
> > The vulnerability with malloc() occurs when working with pointers.
> > It's common to test if a pointer has been set
> > by placing it inside an "if" statement before referencing it.
> > If you always use calloc(), all of your pointers will be
> > initialized with zero.
>
> All bits zero != NULL. This is a common misbelief, which happens to be
> true on a number of platforms. But it is not guaranteed to be true,
> and is not on several platforms, though I conced that they are not the
> mainstream. See:
>
> Sec. 5 of the C FAQ: ~http://www.eskimo.com/~scs/C-faq/s5.html
>
> Any number of comp.lang.c posts:
> http://groups.google.com/groups?as_q=NULL%20calloc%28%29&as_ugroup=comp.lang.c
>
> Especially this one by the author of the FreeBSD C Library (last paragraph):
>
> http://groups.google.com/groups?q=NULL+calloc()+group:comp.lang.c+author:Chris+author:Torek&selm=18764%40dog.ee.lbl.gov
>
>
"man calloc" on a Linux machine says bluntly:
calloc() allocates memory for an array of nmemb elements
of size bytes each and returns a pointer to the allocated
memory. The memory is set to zero.
malloc() allocates size bytes and returns a pointer to the
allocated memory. The memory is not cleared.
> > For the following example
> > it's clear that a core dump might occur; however, if the program were
> > 1000 lines long and the variables set in different locations, tracing
> > could be a bear.
> >
> > typedef struct
> > {
> > char *name;
> > char *address;
> > char *city;
> > char *state;
> > char *zip_code;
> > } PERSON;
> >
> > int main( int argc, char **argv )
> > {
> > PERSON *person = malloc( sizeof( PERSON ) );
> >
> > person->name = "fred";
>
> A core dump could occur right here, with or without calloc(),
> considering you didn't check malloc()'s return.
Allocation error checking was intentionally left out for simplicity.
>
>
> > if ( person->name && person->zip_code )
> > {
> > printf( "For person = %s, got zip code = %s\n",
> > person->name, person->zip_code );
> > }
> > }
> >
> > If calloc() had been used, no one would have noticed the delay and no
> > core would be dumped.
>
> Provided that one is using a system on which NULL happens to be
> all-bits-zero.
What ANSI C implementation are you referring to here?
> Which we all are on this list, but can we guarantee
> that the code you write won't be ported to such a system?
>
Isn't this a Linux users group? What system are you referring to?
Does it not have gcc? Is it open source so we can fix it?
>
> And I submit that without the core dump, the bug of having forgotten
> to set *person's fields just got much, much harder to track down.
>
Core dumps are useful for tracking down bugs.
>
> -Micah
> ___
> vox-tech mailing list
> [EMAIL PROTECTED]
> http://lists.lugod.org/mailman/listinfo/vox-tech
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
On Thu, Mar 20, 2003 at 04:52:15PM -0800, Tim Riley wrote:
>
>
> "Micah J. Cowan" wrote:
>
> > On Thu, Mar 20, 2003 at 10:15:43AM -0800, Tim Riley wrote:
> > >
> > >
> > > > The first library had malloc(). Always
> > > > using calloc() would be a ridiculously inefficient way to obtain
> > > > memory if you're going to just set it again anyway.
> > >
> > > It might seem inefficient to set memory twice, but you're looking
> > > at it from the CPU's point of view. Instead, by looking at it from
> > > the programmer's point of view, the extra nanoseconds it takes
> > > to always get a clean data structure is worth hours of time savings
> > > by not having to trace a core dump.
> >
> > You're saying that you'd rather have your program silently set the
> > wrong memory location than to vomit? In my experience, the earlier in
> > the development stage you catch a bug, the better.
> >
> > What situation are you thinking of where an accidentally unset,
> > malloc()ed structure would cause a core dump upon access that would
> > not be duplicated had calloc() been used?
>
> The vulnerability with malloc() occurs when working with pointers.
> It's common to test if a pointer has been set
> by placing it inside an "if" statement before referencing it.
> If you always use calloc(), all of your pointers will be
> initialized with zero.
All bits zero != NULL. This is a common misbelief, which happens to be
true on a number of platforms. But it is not guaranteed to be true,
and is not on several platforms, though I conced that they are not the
mainstream. See:
Sec. 5 of the C FAQ: ~http://www.eskimo.com/~scs/C-faq/s5.html
Any number of comp.lang.c posts:
http://groups.google.com/groups?as_q=NULL%20calloc%28%29&as_ugroup=comp.lang.c
Especially this one by the author of the FreeBSD C Library (last paragraph):
http://groups.google.com/groups?q=NULL+calloc()+group:comp.lang.c+author:Chris+author:Torek&selm=18764%40dog.ee.lbl.gov
> For the following example
> it's clear that a core dump might occur; however, if the program were
> 1000 lines long and the variables set in different locations, tracing
> could be a bear.
>
> typedef struct
> {
> char *name;
> char *address;
> char *city;
> char *state;
> char *zip_code;
> } PERSON;
>
> int main( int argc, char **argv )
> {
> PERSON *person = malloc( sizeof( PERSON ) );
>
> person->name = "fred";
A core dump could occur right here, with or without calloc(),
considering you didn't check malloc()'s return.
> if ( person->name && person->zip_code )
> {
> printf( "For person = %s, got zip code = %s\n",
> person->name, person->zip_code );
> }
> }
>
> If calloc() had been used, no one would have noticed the delay and no
> core would be dumped.
Provided that one is using a system on which NULL happens to be
all-bits-zero. Which we all are on this list, but can we guarantee
that the code you write won't be ported to such a system?
And I submit that without the core dump, the bug of having forgotten
to set *person's fields just got much, much harder to track down.
-Micah
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
"Micah J. Cowan" wrote:
> On Thu, Mar 20, 2003 at 10:15:43AM -0800, Tim Riley wrote:
> >
> >
> > > The first library had malloc(). Always
> > > using calloc() would be a ridiculously inefficient way to obtain
> > > memory if you're going to just set it again anyway.
> >
> > It might seem inefficient to set memory twice, but you're looking
> > at it from the CPU's point of view. Instead, by looking at it from
> > the programmer's point of view, the extra nanoseconds it takes
> > to always get a clean data structure is worth hours of time savings
> > by not having to trace a core dump.
>
> You're saying that you'd rather have your program silently set the
> wrong memory location than to vomit? In my experience, the earlier in
> the development stage you catch a bug, the better.
>
> What situation are you thinking of where an accidentally unset,
> malloc()ed structure would cause a core dump upon access that would
> not be duplicated had calloc() been used?
The vulnerability with malloc() occurs when working with pointers.
It's common to test if a pointer has been set
by placing it inside an "if" statement before referencing it.
If you always use calloc(), all of your pointers will be
initialized with zero. For the following example
it's clear that a core dump might occur; however, if the program were
1000 lines long and the variables set in different locations, tracing
could be a bear.
typedef struct
{
char *name;
char *address;
char *city;
char *state;
char *zip_code;
} PERSON;
int main( int argc, char **argv )
{
PERSON *person = malloc( sizeof( PERSON ) );
person->name = "fred";
if ( person->name && person->zip_code )
{
printf( "For person = %s, got zip code = %s\n",
person->name, person->zip_code );
}
}
If calloc() had been used, no one would have noticed the delay and no
core would be dumped.
>
>
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
On Thu, Mar 20, 2003 at 10:15:43AM -0800, Tim Riley wrote: > > > > The first library had malloc(). Always > > using calloc() would be a ridiculously inefficient way to obtain > > memory if you're going to just set it again anyway. > > It might seem inefficient to set memory twice, but you're looking > at it from the CPU's point of view. Instead, by looking at it from > the programmer's point of view, the extra nanoseconds it takes > to always get a clean data structure is worth hours of time savings > by not having to trace a core dump. You're saying that you'd rather have your program silently set the wrong memory location than to vomit? In my experience, the earlier in the development stage you catch a bug, the better. What situation are you thinking of where an accidentally unset, malloc()ed structure would cause a core dump upon access that would not be duplicated had calloc() been used? > But in no way were the authors of calloc() being "ridiculous" in their > implementation. I never claimed this. calloc() is a wonderful tool. It just should not be used exclusively instead of malloc(), which is what the professor claimed. -Micah ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
"Micah J. Cowan" wrote: > On Wed, Mar 19, 2003 at 06:08:13PM -0800, Peter Jay Salzman wrote: > > i've heard this from two people now. > > > > some students are being taught they should stay clear of malloc() and > > instead use calloc() because calloc() is the "old school" way of getting > > memory dynamically. they're taught that malloc() may not be present in > > all implementations of the C library. again, because calloc() is "old > > school". presumably, malloc() is ... new fangled. ;) > > This is absolutely untrue. Why are you so *absolutely* sure of yourself? It has been documented that people demean others as a way of self- promotion. > The first library had malloc(). Always > using calloc() would be a ridiculously inefficient way to obtain > memory if you're going to just set it again anyway. It might seem inefficient to set memory twice, but you're looking at it from the CPU's point of view. Instead, by looking at it from the programmer's point of view, the extra nanoseconds it takes to always get a clean data structure is worth hours of time savings by not having to trace a core dump. But in no way were the authors of calloc() being "ridiculous" in their implementation. > > > Even if there is a grain of truth in it, it could only be for > *extremely* old, pre-ANSI implementations which didn't even bother > with being portable, since the first libraries had malloc(), and > malloc() is obviously in the first edition of K&R C. > > IMO, the professor (like way too many C teachers) is an idiot. "Judge not, and ye shall not be judged." > > ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
On Wed, Mar 19, 2003 at 06:28:41PM -0800, Peter Jay Salzman wrote: > begin Rod Roark <[EMAIL PROTECTED]> > > Stirring up some dust... my 1978 K&R mentions alloc() and > > calloc() but not malloc(). Then I have this 1985 "Advanced > > UNIX - A Programmer's Guide" which does talk about malloc(). > > wow -- my gut reaction was wrong! okay, so there is some kind of basis > for that statement. thanks, rod! So was mine, apparently. > > btw, is alloc() == alloca()? > IIRC (possibly not), alloc() =~ malloc(). FWIW, alloca() is not and has never been portable. It's not in any standard that I know of: certainly not C or POSIX. -Micah ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
On Wed, Mar 19, 2003 at 06:08:13PM -0800, Peter Jay Salzman wrote: > i've heard this from two people now. > > some students are being taught they should stay clear of malloc() and > instead use calloc() because calloc() is the "old school" way of getting > memory dynamically. they're taught that malloc() may not be present in > all implementations of the C library. again, because calloc() is "old > school". presumably, malloc() is ... new fangled. ;) This is absolutely untrue. The first library had malloc(). Always using calloc() would be a ridiculously inefficient way to obtain memory if you're going to just set it again anyway. Even if there is a grain of truth in it, it could only be for *extremely* old, pre-ANSI implementations which didn't even bother with being portable, since the first libraries had malloc(), and malloc() is obviously in the first edition of K&R C. IMO, the professor (like way too many C teachers) is an idiot. Anyway, these days *no one* should be worrying about compatibility with pre-ANSI compilers. Standard C exists on pretty much every platform, and could easily be ported to the one or two archaic servers used somewhere in the world which might not have an implementation. > actually, both people used the words "old school", so i'm assuming > that's some kind of quote by the professor. > > just for my own self-edification, does anyone know anything about this > "old school" and "new school" business? i've never heard of it before. Actually, even 1989 C standard should be "old school" by now, as we've had a new standard for 4 years now. Strange that there's still only one fully-conforming implementation of it... *sigh*... I'd love to write exclusively in C99 these days, but since it's still abysmally unportable (GCC's support is still *way* off)... gotta stick to "old school" C89... -Micah ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
Ive not heard of this, and I have been programming C(with malloc) since 1992. I don't see a problem with malloc, in fact the only problem I've seen is the programmers abusing the poor pointers and never using free. :P Mike - Original Message - From: "Peter Jay Salzman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, March 19, 2003 6:08 PM Subject: [vox-tech] malloc() is ... old school? > i've heard this from two people now. > > some students are being taught they should stay clear of malloc() and > instead use calloc() because calloc() is the "old school" way of getting > memory dynamically. they're taught that malloc() may not be present in > all implementations of the C library. again, because calloc() is "old > school". presumably, malloc() is ... new fangled. ;) > > actually, both people used the words "old school", so i'm assuming > that's some kind of quote by the professor. > > just for my own self-edification, does anyone know anything about this > "old school" and "new school" business? i've never heard of it before. > > pete > ___ > vox-tech mailing list > [EMAIL PROTECTED] > http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
On Wednesday 19 March 2003 06:28 pm, Peter Jay Salzman wrote: > begin Rod Roark <[EMAIL PROTECTED]> > > > Stirring up some dust... my 1978 K&R mentions alloc() and > > calloc() but not malloc(). Then I have this 1985 "Advanced > > UNIX - A Programmer's Guide" which does talk about malloc(). > > wow -- my gut reaction was wrong! okay, so there is some kind of basis > for that statement. thanks, rod! > > btw, is alloc() == alloca()? Hm, I don't think so. K&R says it allocates from "a stack" but it doesn't look like it means the caller's stack frame. It also says you must free() in reverse order of the alloc()s. Also it doesn't seem to be supported in recent Linux distributions, which shows one example of why "old school" is not necessarily safest. -- Rod ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
begin Rod Roark <[EMAIL PROTECTED]> > Stirring up some dust... my 1978 K&R mentions alloc() and > calloc() but not malloc(). Then I have this 1985 "Advanced > UNIX - A Programmer's Guide" which does talk about malloc(). wow -- my gut reaction was wrong! okay, so there is some kind of basis for that statement. thanks, rod! btw, is alloc() == alloca()? > In 2003, I think malloc() is pretty safe. :-) heh. i would think a prof would steer students to malloc() to avoid the overhead of clearing memory if it's not necessary. consider the dates you give, it still seems like a strange thing to say... pete > -- Rod > > On Wednesday 19 March 2003 06:08 pm, Peter Jay Salzman wrote: > > i've heard this from two people now. > > > > some students are being taught they should stay clear of malloc() and > > instead use calloc() because calloc() is the "old school" way of getting > > memory dynamically. they're taught that malloc() may not be present in > > all implementations of the C library. again, because calloc() is "old > > school". presumably, malloc() is ... new fangled. ;) > > > > actually, both people used the words "old school", so i'm assuming > > that's some kind of quote by the professor. > > > > just for my own self-edification, does anyone know anything about this > > "old school" and "new school" business? i've never heard of it before. > > > > pete > > ___ > vox-tech mailing list > [EMAIL PROTECTED] > http://lists.lugod.org/mailman/listinfo/vox-tech -- Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
Stirring up some dust... my 1978 K&R mentions alloc() and calloc() but not malloc(). Then I have this 1985 "Advanced UNIX - A Programmer's Guide" which does talk about malloc(). In 2003, I think malloc() is pretty safe. :-) -- Rod On Wednesday 19 March 2003 06:08 pm, Peter Jay Salzman wrote: > i've heard this from two people now. > > some students are being taught they should stay clear of malloc() and > instead use calloc() because calloc() is the "old school" way of getting > memory dynamically. they're taught that malloc() may not be present in > all implementations of the C library. again, because calloc() is "old > school". presumably, malloc() is ... new fangled. ;) > > actually, both people used the words "old school", so i'm assuming > that's some kind of quote by the professor. > > just for my own self-edification, does anyone know anything about this > "old school" and "new school" business? i've never heard of it before. > > pete ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
begin Gabriel Rosa <[EMAIL PROTECTED]> > On Wed, Mar 19, 2003 at 06:08:13PM -0800, Peter Jay Salzman wrote: > > i've heard this from two people now. > > > > some students are being taught they should stay clear of malloc() and > > instead use calloc() because calloc() is the "old school" way of getting > > memory dynamically. they're taught that malloc() may not be present in > > all implementations of the C library. again, because calloc() is "old > > school". presumably, malloc() is ... new fangled. ;) > > > > actually, both people used the words "old school", so i'm assuming > > that's some kind of quote by the professor. > > > > just for my own self-edification, does anyone know anything about this > > "old school" and "new school" business? i've never heard of it before. > > > > From what I remember, and from a quick manpage check, calloc is the one that > zeros the allocated chunk for you. there's another very slight difference - the way you specify the amount of memory. > I would assume that's the real reason why people would instruct their students > in the use of calloc vs malloc. i think you'd be hard pressed to find a c lib > implementation that didn't have malloc, so the "old school" argument is > probably just a way to sound like you know what you're doing :) i'm completely man/info page taught, so i figured there was more to the story than i know about. but yeah, that was kind of my first reaction too.:-/ pete -- Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] malloc() is ... old school?
On Wed, Mar 19, 2003 at 06:08:13PM -0800, Peter Jay Salzman wrote: > i've heard this from two people now. > > some students are being taught they should stay clear of malloc() and > instead use calloc() because calloc() is the "old school" way of getting > memory dynamically. they're taught that malloc() may not be present in > all implementations of the C library. again, because calloc() is "old > school". presumably, malloc() is ... new fangled. ;) > > actually, both people used the words "old school", so i'm assuming > that's some kind of quote by the professor. > > just for my own self-edification, does anyone know anything about this > "old school" and "new school" business? i've never heard of it before. > >From what I remember, and from a quick manpage check, calloc is the one that zeros the allocated chunk for you. I would assume that's the real reason why people would instruct their students in the use of calloc vs malloc. i think you'd be hard pressed to find a c lib implementation that didn't have malloc, so the "old school" argument is probably just a way to sound like you know what you're doing :) -Gabe ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
