> On May 21, 2016, at 4:33 AM, Mouse <mo...@rodents-montreal.org> wrote: > >>> Most executables are not performance-critical enough for >>> dynamic-linker overhead to matter. (For the few that are, or for >>> the few cases where lots are, yes, static linking can help.) >> I keep telling myself that whenever I launch Firefox after a reboot >> ... > > Do you have reason to think dynamic-linker overhead is a perceptible > fraction of that delay? > >>> [file formats and protocols] >> First off, the C standard mandates that the order of fields in a >> struct cannot be reordered, > > Yes. (I think this is a Bad Thing, but I can see why they did it.)
Given that C is a systems implementation language, how would you define HW related data structures where the order of the fields is critical (ie HW defines them). > >> so that just leaves padding and byte order to deal with. > > And data type size. (To pick a simple example, if your bytes are > nonets, you will have an interesting time generating an octet stream by > overlaying a struct onto a buffer.) > > And alignment. Not all protocols and file formats place every datatype > at naturally-aligned boundaries in the octet stream. That’s why there are #pragmas and other compiler directives (i.e. “packed”) to handle this. > >> Now, it may sound cavalier of me, but of the three compilers I use at >> work (gcc, clang, Solaris Sun Works thingy) I know how to get them to >> layout the structs exactly as I need them > > Great. ...for code that doesn't mind writing off portability to other, > including future, hardware and compilers. > > I still don't see why you're citing "it works for my work environment" > as justification for "the C standard should write off anything else”. My biggest complaint about the C standard is that the order that bits within a bit field are compiler defined. This basically means that they are completely unusable for anything that requires interoperability. TTFN - Guy
