Otto Moerbeek | 20 Sep 2007 21:45

Re: [diff] strcpy/strcat -> strlcpy/strlcat


On Wed, 19 Sep 2007, Gilles Chehade wrote:

> Hi,
> 
> Here's a diff to replace remaining strcpy/strcat with strlcpy/strlcat in pcc/cc

This diff looks good to me,

	-Otto

> 
> Gilles
> 
> 
> Index: cpp/cpp.c
> ===================================================================
> RCS file: /local/cvsroot/pcc/cc/cpp/cpp.c,v
> retrieving revision 1.61
> diff -u -p -r1.61 cpp.c
> --- cpp/cpp.c	18 Sep 2007 20:15:58 -0000	1.61
> +++ cpp/cpp.c	19 Sep 2007 22:44:28 -0000
>  <at>  <at>  -427,7 +427,9  <at>  <at>  line()
>  		llen = c;
>  	}
>  	yytext[strlen(yytext)-1] = 0;
> -	strcpy((char *)lbuf, &yytext[1]);
> +	if (strlcpy((char *)lbuf, &yytext[1], SBSIZE) >= SBSIZE)
> +		error("line exceeded buffer size");
> +		
(Continue reading)

Anders Magnusson | 20 Sep 2007 22:28
Picon

Re: [diff] strcpy/strcat -> strlcpy/strlcat

Otto Moerbeek wrote:
> On Wed, 19 Sep 2007, Gilles Chehade wrote:
>
>   
>> Hi,
>>
>> Here's a diff to replace remaining strcpy/strcat with strlcpy/strlcat in pcc/cc
>>     
>
> This diff looks good to me,
>
> 	-Otto
>   
To me too :-) I've added it.

-- Ragge

>> Gilles
>>
>>
>> Index: cpp/cpp.c
>> ===================================================================
>> RCS file: /local/cvsroot/pcc/cc/cpp/cpp.c,v
>> retrieving revision 1.61
>> diff -u -p -r1.61 cpp.c
>> --- cpp/cpp.c	18 Sep 2007 20:15:58 -0000	1.61
>> +++ cpp/cpp.c	19 Sep 2007 22:44:28 -0000
>>  <at>  <at>  -427,7 +427,9  <at>  <at>  line()
>>  		llen = c;
>>  	}
(Continue reading)

Perry E. Metzger | 20 Sep 2007 22:35
Gravatar

Re: CVS repo


"Simon 'corecode' Schubert" <corecode <at> fs.ei.tum.de> writes:
> Perry E. Metzger wrote:
>>> Thanks a lot!  I guess I won't be able to convince you to switch to a
>>> DSCM like git or mercurial?  The repo however is a good starting point
>>> for offline usage.
>> 
>> It would be straightforward for an interested party to turn the CVS
>> repo into a git or mercurial repo that others could track, with new
>> commits to the master repo going into the tracking repo as they
>> happen. That way, Ragge woudln't have to change the way he worked but
>> others could trade patch sets and such.
>
> Yes, I'm volunteering to do so.  However with the current setup I'd only
> be able to update the repo once per night.  If I could rsync/pull a tar
> ball every hour, that would be awesome.

If Ragge were to set up a mailing list that sent out commit alerts,
you could script "real time" updates of a shadow repo.

Perry

Stefan Kempf | 20 Sep 2007 23:31

[patch] Translation of while loops

Hello,

currently, while (x) { body; } is translated like this:

contlab:
	if (!x)
		goto brklab;
	body;
	goto contlab;
brklab:

How about changing it to:

if (!x)
	goto brklab;
lentlab:
	body;
contlab:
	if (x)
		goto lentlab;
brklab:

Only one branch is needed to check the loop condition in every iteration
(while two are needed in the former). This form becomes especially
interesting if pcc will ever perform loop-invariant code motion and such.
This can certainly be applied to for-loops as well, but I didn't
implement it yet.

If you think this is useful, please test the diff.

(Continue reading)

Simon 'corecode' Schubert | 21 Sep 2007 00:23
Picon
Favicon

Re: [patch] Translation of while loops

Stefan Kempf wrote:
> Only one branch is needed to check the loop condition in every iteration
> (while two are needed in the former).

However this increases the size of the code, right?  One of those two
branches is unconditional, so maybe that's not so bad?

Just some input, I'm really new to compilers and code generation.

> This form becomes especially
> interesting if pcc will ever perform loop-invariant code motion and such.

Why would your modification help in this case?

cheers
  simon

Stefan Kempf | 21 Sep 2007 01:49

Re: [patch] Translation of while loops

Simon 'corecode' Schubert wrote:
> Stefan Kempf wrote:
> > Only one branch is needed to check the loop condition in every iteration
> > (while two are needed in the former).
> 
> However this increases the size of the code, right?  One of those two
> branches is unconditional, so maybe that's not so bad?

Right, the code size could increase. But if the compiler is able to find
out that the loop is entered at least once, the first check can
be eliminated later on and then the code becomes a little smaller
(the unconditional jump is gone). As this is not implemented in pcc,
one could do this:

goto contlab;
lentlab:
	body;
contlab:
	if (x)
		goto lentlab;
brklab:

Code size will stay the same, you have two branches on the first entry of
the loop, but only one for every other iteration. But maybe you're right
that that unconditional branch at the end of the loop doesn't hurt too much.

> > This form becomes especially
> > interesting if pcc will ever perform loop-invariant code motion and such.
> 
> Why would your modification help in this case?
(Continue reading)

Ted Unangst | 21 Sep 2007 06:31
Picon

simple program with internal errors

int a() { return 1; }
int main()
{
    int b = 0;
    a() + ++b;
    printf("b %d\n", b);
}

compiling this stops with:
t.c, line 6: compiler error: tmpalloc2

changing a to be a local variable makes it go away.

but deleting the printf, i get instead:
t.c, line 1: compiler error: register error

Otto Moerbeek | 21 Sep 2007 09:47

Re: simple program with internal errors


On Thu, 20 Sep 2007, Ted Unangst wrote:

> int a() { return 1; }
> int main()
> {
>     int b = 0;
>     a() + ++b;
>     printf("b %d\n", b);
> }
> 
> compiling this stops with:
> t.c, line 6: compiler error: tmpalloc2
> 
> changing a to be a local variable makes it go away.
> 
> but deleting the printf, i get instead:
> t.c, line 1: compiler error: register error

 
The smallest (probably) equal test cases I could find are

int a();
int b;
void f()
{
        a() + ++b;
}

and
(Continue reading)

Anders Magnusson | 21 Sep 2007 10:25
Picon

Re: simple program with internal errors

It's something that goes wrong in deluseless() or close; the function 
call ends up outside the function.
I'll look at it, probably quick to fix.

-- Ragge

Otto Moerbeek wrote:
> On Thu, 20 Sep 2007, Ted Unangst wrote:
>
>   
>> int a() { return 1; }
>> int main()
>> {
>>     int b = 0;
>>     a() + ++b;
>>     printf("b %d\n", b);
>> }
>>
>> compiling this stops with:
>> t.c, line 6: compiler error: tmpalloc2
>>
>> changing a to be a local variable makes it go away.
>>
>> but deleting the printf, i get instead:
>> t.c, line 1: compiler error: register error
>>     
>
>  
> The smallest (probably) equal test cases I could find are
>
(Continue reading)

Otto Moerbeek | 21 Sep 2007 10:25

Re: user/5586: PCC initializes a struct incorrectly (fwd)


On Thu, 20 Sep 2007, Otto Moerbeek wrote:

> 
> This bug seems to occur for multi-dimensinal arrays preceded by some
> other field:
> 
> [otto <at> pepper:154]$ cat init.c 
> struct s {
>         int f;
>         int a[2][2];
> };
> 
> struct s v = { 0x99, {{0x100, 0}, {0x101, 0}} };
> [otto <at> pepper:155]$ /usr/local/libexec/ccom_x86   init.c  
>         .data
>         .align 4
>         .globl v
> v:
>         .long 0x100
>         .long 0x0
>         .long 0x101
>         .long 0x0
>         .zero 4
> [otto <at> pepper:156]$ 

Did a lot of digging, no solution yet. Though I find the following
extremely suspect:

	-Otto
(Continue reading)


Gmane