or strings). Does that
sound ok?
Tanton
-Original Message-
From: Jarkko Hietaniemi
To: Timur Safin
Cc: Gibbs Tanton - tgibbs; 'Josh Wilmes '; [EMAIL PROTECTED]
Sent: 9/17/2001 3:24 PM
Subject: Re: "Automated" Purify Run
On Tue, Sep 18, 2001 at 12:06:32AM +0400, Timur Safin
On Tue, Sep 18, 2001 at 12:06:32AM +0400, Timur Safin wrote:
> Hi Jarkko,
>
> Here is that the SUSV2 prescribe to do in this situation.
>
> The Single UNIX ® Specification, Version 2, Copyright © 1997 The Open Group
> "
> NAME
> malloc - a memory allocator
> ...
I'm reading the same pag
On Tue, Sep 18, 2001 at 12:06:32AM +0400, Timur Safin wrote:
> Here is that the SUSV2 prescribe to do in this situation.
Unfortunately, it's no good programming to standards; we have to program
around them.
--
I cannot and will not cut my conscience to fit this year's fashions.
-
From: "Jarkko Hietaniemi" <[EMAIL PROTECTED]>
To: "Gibbs Tanton - tgibbs" <[EMAIL PROTECTED]>
Cc: "'Josh Wilmes '" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, September 17, 2001 11:36 PM
Subject: Re: "Automated"
On Mon, Sep 17, 2001 at 10:38:26PM +0300, Jarkko Hietaniemi wrote:
> How about always allocating size+1 and stomping '\0' to the [size]th bytes?
I'm trying to kill off that age-old C-ism and brainwash people into believing
that a null in a string is just as significant as any other byte, so that
On Mon, Sep 17, 2001 at 02:33:53PM -0500, Gibbs Tanton - tgibbs wrote:
> Okey Dokey. With that being the case, it appears we should rethink
> string_grow/string_make. If we get a length of 0, we should allocate 1 byte
> and store '\0' in it
Nope. If we get a length of 0, we don't do anything. S
eing 0, but this way
it will be portable.
Does this sound ok?
Tanton
-Original Message-
From: Jarkko Hietaniemi
To: Gibbs Tanton - tgibbs
Cc: 'Josh Wilmes '; ''[EMAIL PROTECTED] ' '
Sent: 9/17/2001 2:26 PM
Subject: Re: "Automated" Purify Run
On
PROTECTED] ' '
Sent: 9/17/2001 2:23 PM
Subject: Re: "Automated" Purify Run
Purify instrumented foo (pid 11272)
ABR: Array bounds read:
* This is occurring while in:
_doprnt[libc.so.1]
printf [libc.so.1]
main
On Mon, Sep 17, 2001 at 02:18:16PM -0500, Gibbs Tanton - tgibbs wrote:
> The hourly should be fine...can you do me one other favor and run the
> following c snippet through Purify:
>
> int main() {
> char* c = (char*)malloc(0);
I can tell without Purify that malloc(0) is unportable.
(As is cal
Josh Wilmes
> To: Gibbs Tanton - tgibbs
> Cc: '[EMAIL PROTECTED] '
> Sent: 9/17/2001 1:18 PM
> Subject: Re: "Automated" Purify Run
>
> It should now be running once an hour. (it broke due to some makefile
> changes yesterday).
>
> I can't really
CTED] '
Sent: 9/17/2001 1:18 PM
Subject: Re: "Automated" Purify Run
It should now be running once an hour. (it broke due to some makefile
changes yesterday).
I can't really do it easily on-demand, due to the way this is set up.
--Josh
At 13:05 on 09/17/2001 CDT, Gibb
s only running every day. Can we get it to
> run every hour? Perhaps even on demand? I think I have fixed all of the
> memory access errors but one.
>
> -Original Message-
> From: Josh Wilmes
> To: [EMAIL PROTECTED]
> Sent: 9/15/2001 5:16 PM
> Subject: "A
mated" Purify Run
This time i've filtered out all the memory leak related data so all that
shows up are legitimate errors. (hopefully)
I have set up a cheesy script to update the following URL with the
current output
of purify on the current CVS test_prog (test,test2,test3,euclid) ev
This time i've filtered out all the memory leak related data so all that
shows up are legitimate errors. (hopefully)
I have set up a cheesy script to update the following URL with the current output
of purify on the current CVS test_prog (test,test2,test3,euclid) every hour.
http://www.hitchh
14 matches
Mail list logo
