[9fans] memory bug in 5l

[9fans] memory bug in 5l

[yoann padioleau]

in 5l/obj.c#zaddr()
there is:
	case D_FCONST:
		while(nhunk < sizeof(Ieee))
			gethunk();
		a->ieee = (Ieee*)hunk;
		nhunk -= NSNAME;
		hunk += NSNAME;

I think it’s a copy paste bug, it should
be sizeof(Ieee) instead of those NSNAME
(or even better the whole code could be factorized
in a call to a->ieee = malloc(sizeof(Ieee));

Re: [9fans] memory bug in 5l

[yoann padioleau]

Also, by curiosity, does anybody know why 5a/, 5l/, 5c/
(and the other architecture variants) are redefining
malloc and free? Why not using the malloc and free
from the libc?


On Dec 9, 2014, at 4:21 PM, yoann padioleau <aryx.padator@gmail.com> wrote:

> in 5l/obj.c#zaddr()
> there is:
> 	case D_FCONST:
> 		while(nhunk < sizeof(Ieee))
> 			gethunk();
> 		a->ieee = (Ieee*)hunk;
> 		nhunk -= NSNAME;
> 		hunk += NSNAME;
> 
> I think it’s a copy paste bug, it should
> be sizeof(Ieee) instead of those NSNAME
> (or even better the whole code could be factorized
> in a call to a->ieee = malloc(sizeof(Ieee));
> 

Re: [9fans] memory bug in 5l

[Steve Simon]

the compilers use a very simple allocator which is designed for speed
rather than efficiency - as i remember it never frees anything and just
allocates from a heap.

it also works if you use libc's malloc and that will allow you to link big things
(like gs) on small memory machines. in reality memory is cheap and no one
likes to wait when they don't have to.

-Steve



> On 10 Dec 2014, at 00:24, yoann padioleau <aryx.padator@gmail.com> wrote:
> 
> Also, by curiosity, does anybody know why 5a/, 5l/, 5c/
> (and the other architecture variants) are redefining
> malloc and free? Why not using the malloc and free
> from the libc?
> 
> 
>> On Dec 9, 2014, at 4:21 PM, yoann padioleau <aryx.padator@gmail.com> wrote:
>> 
>> in 5l/obj.c#zaddr()
>> there is:
>>   case D_FCONST:
>>       while(nhunk < sizeof(Ieee))
>>           gethunk();
>>       a->ieee = (Ieee*)hunk;
>>       nhunk -= NSNAME;
>>       hunk += NSNAME;
>> 
>> I think it’s a copy paste bug, it should
>> be sizeof(Ieee) instead of those NSNAME
>> (or even better the whole code could be factorized
>> in a call to a->ieee = malloc(sizeof(Ieee));
> 

Re: [9fans] memory bug in 5l

[yoann padioleau]

There is a related bug still in this file in ldobj() I think:

	if(nhunk < sizeof(Prog))
		gethunk();
	p = (Prog*)hunk;
	nhunk -= sizeof(Prog);
	hunk += sizeof(Prog);

it should be while(chunk < sizeof(Prog))
(or even better again, a simple call to malloc(sizeof(Prog))


On Dec 9, 2014, at 4:21 PM, yoann padioleau <aryx.padator@gmail.com> wrote:

> in 5l/obj.c#zaddr()
> there is:
> 	case D_FCONST:
> 		while(nhunk < sizeof(Ieee))
> 			gethunk();
> 		a->ieee = (Ieee*)hunk;
> 		nhunk -= NSNAME;
> 		hunk += NSNAME;
> 
> I think it’s a copy paste bug, it should
> be sizeof(Ieee) instead of those NSNAME
> (or even better the whole code could be factorized
> in a call to a->ieee = malloc(sizeof(Ieee));
> 

Re: [9fans] memory bug in 5l

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 204 bytes --]

On Wed, Dec 10, 2014 at 1:19 AM, yoann padioleau <aryx.padator@gmail.com>
wrote:

> it should be while(chunk < sizeof(Prog))


a hunk is always much bigger than sizeof(Prog) so it's the same as if

[-- Attachment #2: Type: text/html, Size: 497 bytes --]

Re: [9fans] memory bug in 5l

[yoann padioleau]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

Right, but the same code in 8l does the while
loop, and most of the code in 5l does the while loop,
so for consistency it seems it should also be a while loop
here.


On Dec 10, 2014, at 2:07 AM, Charles Forsyth <charles.forsyth@gmail.com> wrote:

> 
> On Wed, Dec 10, 2014 at 1:19 AM, yoann padioleau <aryx.padator@gmail.com> wrote:
> it should be while(chunk < sizeof(Prog))
> 
> a hunk is always much bigger than sizeof(Prog) so it's the same as if


[-- Attachment #2: Type: text/html, Size: 1154 bytes --]