Re: [Tinycc-devel] Allow configuration of tcc libraries search path

[Thomas Preud'homme]

Le jeudi 7 juillet 2011 00:06:37, grischka a écrit :
> Thomas Preud'homme wrote:
> >> Also, I'd claim that using strtok is somehow un-tcc'ish, seen that
> >> there are zero occurrences anywhere else. ;)
> > 
> > Ah. Then what tcc'ish function should I use?
> 
> The one that you write yourself ;)  Say along the lines of
> 
>     while (*p && *p != ':')
>       ++p;
> 
> Reason why strtok is bad is because it does non-obvious things
> which in turn leads to non-obvious code and bugs.
> 
> For example all those variables called 'tok_somthing'
> 
>        char *tok, *tok_extra_libdir = NULL, *tok_save_ptr,
>        size_t toklen = 0, old_toklen = 0;
> 
> is more or less stuff that literally nobody really wants to read,
> including the person who wrote it.  Which means that bugs will
> stay undetected more likely.
Yeah, I realized these mistake a bit later, when I was introducing 
tcc_split_path_components.
> 
> Now thank you for proving this point as with missing free,  missing
> buffer space for terminating '\0' (as with 'toklen'), missing statement
> 'old_toklen = toklen' somewhere.  Aside from the fact that strtok_r
> does not seem to be part of the C standard which (I think) is effectively
> a problem if someone wants to build the cross compilers on windows.
I always forget about non posix systems. Thanks for reminding me. You made a 
very good point about using only C standard.

And also sorry for introducing so stupid bugs.
> 
> So, considered the extra stuff that you need to setup for 'strtok',
> (variables, copying the const string to rw memory) plus the extra
> bugs that need to be fixed each, the extra email text to get there,
> plus that even then the code will still be ugly, and considered that
> strtok doesn't do really much, it is very likely much more effective
> not to use strtok.
> 
> Anyway, this was the long version of:  Why I hate strtok.  Or say
> strncpy, for that matter.  (Incidentally tcc has 'pstrcpy'.)
I didn't know strncpy's flaws until recently but now I can't agree more.
> 
> >> Btw, I'm still thinking about 0.9.26.
> > 
> > Great :) Please wait this is fixed then. I did a snapshot of the master
> > branch for distribution in Debian. I plan to let it stay in Debian
> > experimental for a few weeks (my initial plan is 1 month but I could do
> > 2 weeks) and then upload it in Debian unstable where it will have more
> > coverage. So if you want you can wait a month and I'll tell you if I
> > have any bug report when it hit unstable. Note that I'm also fine for
> > releasing now, especially since it would simplify my work.
> 
> Not sure how this would simplify your work but surely I can wait a month ;)
No need to have a snaphot of master + patches, it would just be plain 0.9.26 
tarball + pure debian packaging stuff.

Anyway, I'm not sure I'll be motivated enough to backport this patch on 0.9.25 
but I want to bring the patch quickly in Debian as it will allow me to fix a 
release critical bug. Hence I will probably upload directly master's snapshot 
in debian unstable and give it good exposure/testing.

If you're fine with the current patch I'll upload it this afternoon and will 
let you know if any bug is reported. By the way, the patch for include path 
only allow to look several subdirectories of /usr/local/include and 
/usr/include but a CONFIG_TCC_INCPREFIX could easily be introduced to provide 
a different include path. Do you think I should introduce it?
> 
> Thanks,
> 
> --- grischka
Best regards,

Thomas Preud'homme

signature.asc
Description: This is a digitally signed message part.