C standards and committees (was Re: strangest systems I've sent email from)

Guy Sotomayor Jr ggs at shiresoft.com
Sat May 21 10:59:36 CDT 2016


> On May 21, 2016, at 4:33 AM, Mouse <mouse at 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



More information about the cctalk mailing list