Paul Sander wrote :
||
|| An "isValid" field isn't valid if the structure isn't initialized properly.
|| When this is a concern, the value of the pointer itself becomes significant
|| (like it is with the NULL pointer, but when its value must also be
|| distinguishable from NULL). In such
--- Forwarded mail from [EMAIL PROTECTED]
Paul Sander wrote :
||
|| An "isValid" field isn't valid if the structure isn't initialized properly.
|| When this is a concern, the value of the pointer itself becomes significant
|| (like it is with the NULL pointer, but when its value must also be
||
Just for people to think about...
In working with object oriented code, we OFTEN create and return zero
length arrays when we are returning an array and have nothing to return
(ex: zero records from a database fetch.)
Accepting a zero length request, and returning a zero byte long
allocation
I concur strongly with Derek's sentiments and would add some more comments:
I often use custom memory allocators to help debug wild pointer errors and
rather than zeroing out allocated memory, I will often write a repeating
multibyte sentinal value (such as 0xbaad) into the memory block so
--- Forwarded mail from [EMAIL PROTECTED]
Noel L Yap wrote:
I've noticed that xmalloc does not zero out the memory that's just been
allocated.
Right. It shouldn't have to. Well-written programs do not access
uninitialized memory.
This doesn't jive well when adding new fields to
This is getting a bit off-topic, but...
--- Forwarded mail from [EMAIL PROTECTED]
[EMAIL PROTECTED] on 05/02/2000 03:13:34 PM
Although looking at the xmalloc call, I don't know if it's such
a good thing for it to take a 0 length request and turn it into
a 1 byte request. Why would we need to
[EMAIL PROTECTED] on 05/02/2000 06:58:16 PM
For safety, I propose that xmalloc zero out the memory it allocates. Any
comments or rebuttals?
For safety, I would prefer it does not. I don't think we should
use non-portable solutions to cover up the faults of badly-written
software.
[EMAIL PROTECTED] on 05/03/2000 12:44:09 AM
I was looking at that, too. I tend to feel that 0-byte allocations should be
allowed (returning NULL) and, if systems' frees don't handle NULL properly,
there should be an xfree() that'll do so.
I can see the occasional need to allocate a unique
Derek Scherger wrote:
For safety, I propose that xmalloc zero out the memory it allocates. Any
comments or rebuttals?
For safety, I would prefer it does not. I don't think we should
use non-portable solutions to cover up the faults of badly-written
software. I'd feel more
Donald Sharp writes:
I was/am volunteering to waste my own time. Would you accept it
if it was done?
No. It's not worth my time to apply a patch.
-Larry Jones
I've got an idea for a sit-com called "Father Knows Zilch." -- Calvin
Noel L Yap writes:
Hopefully, many eyes will tend to spot wild-pointer errors.
I prefer the cybernetic eyes of Purify and similar tools -- I run a
Purified version of CVS through the test suite every now and then and
there are currently no errors (although there are still a *lot* of
leaks).
[ On Wednesday, May 3, 2000 at 11:46:27 (-0400), Larry Jones wrote: ]
Subject: Re: question (preference?) about xmalloc
Noel L Yap writes:
Hopefully, many eyes will tend to spot wild-pointer errors.
I prefer the cybernetic eyes of Purify and similar tools -- I run a
Purified version
[smc] David Thornley wrote: [...]
If xmalloc is to initialize memory, I'd prefer it to be initialized
to something obviously bad. Jonathan Gilligan had some very good
suggestions. Now, "obviously bad" is system-specific, but it's better
than initializing to a value selected to be
Donald Sharp [EMAIL PROTECTED] writes:
Although looking at the xmalloc call, I don't know if it's such a good
thing for it to take a 0 length request and turn it into a 1 byte
request. Why would we need to ask for a 0 length portion of memory?
malloc of 0 bytes on some platforms returns
[EMAIL PROTECTED] on 05/02/2000 03:13:34 PM
i agree in principle ;). It probably would be better to
use calloc, within the xmalloc call( as that calloc will zero
out the memory for you ), then malloc.
Larry's convinced me otherwise. IMHO, the "right" way to fix the problem is to
have
On Tue, May 02, 2000 at 03:28:15PM -0400, Noel L Yap wrote:
[EMAIL PROTECTED] on 05/02/2000 03:13:34 PM
i agree in principle ;). It probably would be better to
use calloc, within the xmalloc call( as that calloc will zero
out the memory for you ), then malloc.
Larry's convinced me
Noel L Yap writes:
I was looking at that, too. I tend to feel that 0-byte allocations should be
allowed (returning NULL) and, if systems' frees don't handle NULL properly,
there should be an xfree() that'll do so.
The problem with that is that code that calls malloc almost always
assumes
[ On Tuesday, May 2, 2000 at 14:01:09 (-0400), Noel L Yap wrote: ]
Subject: question (preference?) about xmalloc
For safety, I propose that xmalloc zero out the memory it allocates. Any
comments or rebuttals?
Generally speaking it is not safe (i.e. not portable) to assume that
memset()ing
Noel L Yap wrote:
I've noticed that xmalloc does not zero out the memory that's just been
allocated.
Right. It shouldn't have to. Well-written programs do not access
uninitialized memory.
This doesn't jive well when adding new fields to existing structures
(specially these structures
Donald Sharp writes:
would this be a good thing(tm) for someone to go and do?
No. The existing methodology may fall slightly short of some people's
ideal, but it's a widely used methodology and it works just fine.
Changing it at this point would be a lot of work for very little gain.
could be made a macro.
would this be a good thing(tm) for someone to go and do?
donald
Noel
[EMAIL PROTECTED] on 05/02/2000 04:50:40 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: question (preference?) about xmalloc
Noel L Yap writes
I was/am volunteering to waste my own time. Would you accept it
if it was done?
donald
On Tue, May 02, 2000 at 05:57:57PM -0400, Larry Jones wrote:
Donald Sharp writes:
would this be a good thing(tm) for someone to go and do?
No. The existing methodology may fall slightly short of
For safety, I propose that xmalloc zero out the memory it allocates. Any
comments or rebuttals?
For safety, I would prefer it does not. I don't think we should
use non-portable solutions to cover up the faults of badly-written
software. I'd feel more comfortable using the software
23 matches
Mail list logo
