[Tinycc-devel] Re: [PATCH 7/7] tcc -E: Let output_default be <file>.o instead of a.out

[Kirill Smelkov]

On Mon, Jun 21, 2010 at 06:26:35PM +0200, grischka wrote:
> Kirill Smelkov wrote:
> >On Fri, Jun 18, 2010 at 09:24:28PM +0200, grischka wrote:
> >>Did you consider pushing the feature(s) on the tinycc mob branch?
> >
> >Yes. And I though mob was a bit destabilized by "last member of union"
> >patches, so I decided not to continue that.
> 
> Well, looks like he fixed something but broke something else instead.
> I've reverted the commits for now.

Thanks.

Btw, as shinichiro.h already said, we need test cases for new
features... Guilty - I was lazy to add one for my -MD, but that does not
count because it needs test infrastructure to be extended a bit :)

> >Yes, I've read tinycc.git intro text about mob, and it's really up to
> >you on how to pick patches. I just though posting by mail is also ok,
> >and as your comments show, having a look on them before inclusion allows
> >(hopefully) to merge them in a bit more good shape.
> 
> Sure that is good ;)
> 
> But I will not push other peoples' patches.  So once you are happy
> with what you did you need to do that yourself.  No need to hurry
> though.
> 
> In any case you could push the simple fixes (typos etc) first, and
> then the MD/MF patch as one single commit.
> 
> Also it is easier IMO to look at patches in the git webview.  Maybe
> you can just post a link to your branch next time instead of sending
> 30 emails.

Ok, and sorry for 30 emails - i did not intened to spam the list
initially. Also instead of webview, maybe it is more easier to apply
patches to temporary branch and view them with gitk? Anyway "for whom
how" - if any more patches are coming from me - I'll post one link.

(And for projects where they post patches by mail, I tuned my mail
 client to color inlined patches the same way git does - very handy... )


> > snprintf(buf, sizeof(buf), "%s", target);
> tcc usually does "pstrcpy(buf, sizeof(buf), target);"

Thanks, corrected.

> > static char outfile_default[1024];
> Hm hm ...

I know, yes. But what would be the better one? I've already described my
rationale about not mallocing and other variants. And besides,
get_tok_str() uses the same approach...

> Anyway what I like about your new feature is that the main()
> function now looks cleaner than before ;)

Yep :)


Thanks,
Kirill