small bitmap.c patch [off-topic]

[Christopher R. Hertel]

> [This is waaayyy off-topic, but what the hell, it's Monday...]

Yes and no.  These are technical issues which impact programming
decisions. 

> Anyways, I'm not advocating the use of structures for sending
> binary messages - even if you limit yourself to particular
> hardware and software this can be difficult.  I merely point
> out that the C standards committee made a big mistake by
> opening up the idea of compiler-optimized structures. 

An interesting opinion.  While I agree that allowing reordering removes 
some functionality from the lanuage it also acknowledges architectural 
differences between machines.

> There
> will always be size and alignment issues which the spec has to
> acknowledge, but to add *reordering* to the list of things a
> compiler can do is just dangerous. 

Only if the programmer makes assumptions about the structure ordering.  :)

> The following structure,
> according to the current specs, could be reordered causing
> problems in the compiled program:
> 
>     struct
>     {
>       int  foo;
>       char bar[1];
>     }

This is exactly the kind of structure that caused problems when I 
compiled the code on my SGI Indy at work.  

> This is a pretty common way to store variable-length data;

On architetures which support it, when the code is written by someone who
understands that architecture. 

> the last member of the structure is an array of length 1.
> When the structure is allocated, the memory for the array is
> also allocated, in one chunk, and in a way that is guaranteed
> to be OK for the processor's alignment requirements. 

I am well aquainted with this trick.  I used it just the other day, but 
the program was quick & dirty and intended for use in testing a solution 
for a Grad Class I'm taking.  (Yeah, I'm back in class again... I think 
I'm older than the Prof.)

> More
> importantly, it is a more compact representation and provides
> contiguous storage, which is usually more important for
> overall performance.

Agreed (though it should be "more important"--the "ly" is unnecessary.)

> The spec would call for a structure like:
> 
>     struct
>     {
>       int  foo;
>       char *bar;
>     }
> 
> You *could* save on a double memory allocation overhead by
> allocating one chunk of memory and setting "bar" to the
> pointer + sizeof(struct), but the result is still less efficient
> code (not only for initialization, but when accessing the "bar"
> member array) and you will use more memory for the base structure
> (8 or 16 bytes when using a pointer, vs. 4 or 8 bytes for the
> member array)
> 
> Anyways, I'm just an old 6502 and 6809 asm programmer who (at the
> time) thought that 64k was cool, and still wants to write code that
> works well on today's hardware... :)

In summary, I believe that the C spec. was trying to accomodate hardware
with different memory ordering semantics and such.  Also, at the time
memory was more of a luxury so re-ordering structures was probably
important for memory efficiency.  Any such specification is a compromise
and Samba, of necessity, is full of additional compromises. 

There are probably tricks that can be played to get around this.  For 
example, you could do this:

  struct garble
    {
    int foo;
    int bar;
    }

  p = (struct garble *)malloc( sizeof( struct garble ) + strlen( data ) );
  q = (char *)&p[1];

The problems with the above are:
  1) Alignment might cause some shifting of the actual location of q.  It
     might be necessary to round up the value passed to malloc() to the
     next highest word multiple.
  2) The pointer to the data is still not part of the structure, and adding
     that pointer adds another sizeof( void * ) bytes to the structure size.

Is it worth while?  I don't know.

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services

    Ideals are like stars; you will not succeed in touching them
    with your hands...you choose them as your guides, and following
    them you will reach your destiny.  --Carl Schultz