Le jeudi 15 novembre 2012 18:34:51, grischka a écrit : > [email protected] wrote: > > I already did a general function to store a value but I adopted a > > different approach: > > > > #define put_sym_attr(s,index,field,val) \ > > > > alloc_sym_attr(s, index); \ > > s->sym_attrs[index].field = val > > > > where alloc_sym_attr is the old put_got_offset without the assignment > > line at the end. See attached file for the full patch (only tested on > > x86-64 so far, I'll try to compile it on arm later). > > To my taste that macro with 4 args (and omitted ';') is a too clever > workaround to avoid letting alloc_sym_attr() return a value.
I did it because I saw this kind of macro many times. > > Compare > put_sym_attr(s1, sym_index, got_offset, s1->got->data_offset); > with > alloc_sym_attr(s1, sym_index)->got_offset = s1->got->data_offset; > > Clearly the latter is better readable (since '=' is C for 'put') and > without the additional macro your patch will be shorter which is > what counts in the end. ;) Two points for you. I especially appreciate the argument about following the spirit of C (I know you didn't name it this way :)). > > Also, in general, there is always an certain ugliness with 'void' > functions. Thus if a function can return some useful value, then it > should do so. Think of 'strcpy'. (In that sense and opposed to the > related GCC warning it is of course not wrong not to use a return > value.) You're right, I never thought about void function being ugly but I see your point. > > > + typeof(s1->sym_attrs) tab; > > Is this C? Note that not just GCC and TCC might be used to compile > tcc. (E.g. more recent MS compilers from the VCExpress editions used > to work) I thought so but it seems I've been intoxicated by gccism. I checked the C99 standard and it's not inside. In this case it can easily be changed by void * while still keeping sym_attrs an anonymous struct. > > Thanks, > > --- grischka Tom
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
