|
From: Robert W. <rj...@du...> - 2003-09-29 18:34:46
|
> > Look like great, a minor build problem, make clean > > remove default.supp but it's not rebuilded > > Hmm, that seems to be a problem with Valgrind in general. I'll > investigate. Isn't the default.supp built by ./configure? Perhaps the thing to do is to have it built by make instead, based on the results from ./configure. Regards, Robert. |
|
From: Nicholas N. <nj...@ca...> - 2003-09-29 20:51:49
|
On Mon, 29 Sep 2003, Robert Walsh wrote: > > > Look like great, a minor build problem, make clean > > > remove default.supp but it's not rebuilded > > Isn't the default.supp built by ./configure? Perhaps the thing to do is > to have it built by make instead, based on the results from ./configure. I pulled in the other direction... I just committed a change so that default.supp is now only deleted by "make distclean". Thanks for the advice. N |
|
From: Erik C. <er...@ar...> - 2003-09-29 19:57:37
|
On Mon, Sep 29, 2003 at 09:16:34PM +0000, Philippe Elie wrote:
> Erik Corry wrote:
>> On Mon, Sep 29, 2003 at 06:53:12PM +0000, Philippe Elie wrote:
>>
>>> int main(void)
>>> {
>>> char * p1 = malloc(1000);
>>> char * p2 = malloc(1000);
>>> printf("%p %p %p\n", p1, p2, &p1[p2 - p1]);
>>>
>>> p1[p2 - p1 + 1] = 0; /* expect error here */
>>
>> You are only allowed to subtract pointers if they are pointers
>> into the same array object.
>
> I know and ?
So perhaps the new skin should mark the result of an
inter-object pointer-pointer subtraction as a poisoned value
which poisons anything you use it for. Then you give a warning
or an error if a poisoned value is ever used as a pointer.
I don't know how many errors that would give for typical
programs. It seems to me like a sick thing to do.
Likewise for a multiplication of a pointer with an integer:
You can do it, but you may never use the result as a pointer
again.
Just an idea.
> >So it's a bit dodgy, though of course it is legal gcc, just not
> >legal C. And it could be legal some-other-language-that-you-compile-
> >and-feed-to-valgrind.
>
> that's a real problem, is there any existing languages which use
> malloc and allow weirds things like overrunning a heap block in
> such way you access another block ?
Arguably the C-like language implemented by gcc is an example of such
a language.
--
Erik Corry er...@ar...
A: Because it messes up the order in which people normally read text.
Q: Why is top-replying such a bad thing?
A: Top-replying.
Q: What is the most annoying thing in email?
|
|
From: Nicholas N. <nj...@ca...> - 2003-09-30 07:33:37
|
On Mon, 29 Sep 2003, Erik Corry wrote: > So perhaps the new skin should mark the result of an > inter-object pointer-pointer subtraction as a poisoned value > which poisons anything you use it for. Then you give a warning > or an error if a poisoned value is ever used as a pointer. I currently do exactly this "poisoning", but I allow a poisoned value to be used as a pointer, because in practice it's necessary. > I don't know how many errors that would give for typical > programs. It seems to me like a sick thing to do. I just tried it... 2568 times for 'date' :) I would guess most are because of strcpy(). > Likewise for a multiplication of a pointer with an integer: > You can do it, but you may never use the result as a pointer > again. Yep, that's what it does. > > that's a real problem, is there any existing languages which use > > malloc and allow weirds things like overrunning a heap block in > > such way you access another block ? > > Arguably the C-like language implemented by gcc is an example of such > a language. (: N |