> As I said in a mail last night: "A compromise might be to define > offsets of members, and SMEMCPY from the correct location. An > optimising compiler can more easily eliminate that and convert to an > assignment where it knows it can. The situation for those using poor > compilers could be bad though - function calls every time; and they > may have been unaffected by the portability issue in the first place. " > > In other words, the price of complete portability would be poor > performance for the vast majority of existing users. And more complex > code. > > Jifl
What if you made a macro that basically did structure copying as it is done now, but allowed it to be overridden in a sys_arch.h file? Not sure this would work, I'm not a coding wizard, but what about: #define STRUCT_COPY(struct_type, inptr, outptr) \ #ifndef STRUCT_COPY_##struct_type \ memcpy(outptr, input, sizeof(struct_type)); \ #else \ STRUCT_COPY_##struct_type(inptr,outptr); \ #endif Then guys with address-alignment challenged compilers could deal with a non-efficient routine when they needed to and everyone else would get the optimal solution. Not sure if this solves the whole problem (pointer assignment?), but you get the idea.... -Mike
begin:vcard fn:Michael Williamson n:Williamson;Michael org:Critical Link LLC;Engineering adr:;;6712 Brooklawn Parkway;Syracuse;NY;13211;USA email;internet:[EMAIL PROTECTED] title:Senior Engineer tel;work:315-425-4045 x230 tel;fax:315-425-4048 tel;cell:315-663-4604 x-mozilla-html:TRUE url:http://www.criticallink.com version:2.1 end:vcard
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
