Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #26920

Re: packed structs

From JohnF <john@please.see.sig.for.email.com>
Newsgroups comp.lang.c
Subject Re: packed structs
Date 2012-10-01 07:34 +0000
Organization PANIX Public Access Internet and UNIX, NYC
Message-ID <k4bh2t$eev$1@reader1.panix.com> (permalink)
References (5 earlier) <0.6562e3f0e92d8c6a2354.20120924015911BST.871uhs2q3k.fsf@bsb.me.uk> <k3oi08$14i$1@reader1.panix.com> <k3p8jm$vl5$1@dont-email.me> <k3peo6$quh$1@reader1.panix.com> <k4a63c$11h$1@dont-email.me>

Show all headers | View raw


Stephen Sprunk <stephen@sprunk.org> wrote:
> JohnF wrote:
>> Well, you'd use it however you liked. But for my gif situation,
>> I'd envisioned >>doing away with structs entirely<<, packed or not.
>> The smemf >>format string totally replaces<< the need for any struct.
>> And, of course, I prototyped that for myself, i.e., wrote some
>> pseudocode using the as-yet-uncompleted smemf, just to make sure
>> that idea seems to work.
>>     You can see exhaustively complete comments about the gif block
>> formats at forkosh.com/gifsave89.html by clicking the Listing link
>> along the left-hand side under "Related Pages", and scrolling down
>> to line#493 for the GIFIMAGEDESCRIP struct. My "pseudocode" for that
>> is just one smemf statement that totally replaces the struct,
>> 
>> nbitsinbuffer =  /* whitespace in smemf format string is ignored */
>>   smemf(buffer, " 2C %x  "   /* Image Descriptor identifier is hex 2C */
>>                 "    %2ld"   /* 2-byte little-endian word for X-pos */
>>                 "    %2ld"   /* 2-byte little-endian word for Top */
>>                 "    %2ld"   /* 2-byte little-endian word for Width */
>>                 "    %2ld"   /* 2-byte little-endian word for Height */
>>   /* following is the "Packed" Byte consisting of five bit fields */
>>                 "    %3b "   /* 3-bits #colorbits */
>>                 "  0 %2b "   /* 2-bits "reserved bits" */
>>                 "  0 %1b "   /* 1-bit  local colortable sort flag */
>>                 "  0 %1b "   /* 1-bit  interlace flag */
>>                 "    %1b ",  /* 1-bit  local colortable flag */
>>   col0,row0, ncols,nrows, ncolorbits, (colortable==NULL?0:1) );
>> 
>> And smemf() returns the size, in #bits, of the buffer it constructs.
>> That would usually be a multiple of 8, in which case you can just
>> fwrite(buffer,etc), or do whatever you want with it.
> 
> This example shows how far you have diverged from sprintf().  From such
> a claim, I would have expected something more like this:
> 
> nbitsinbuffer = smemf(buffer,
>    "%1lu"   /* Image Descriptor, 8-bit little-endian unsigned int */
>    "%2lu"   /* X-Pos, 16-bit little-endian unsigned int */
>    "%2lu"   /* Top, 16-bit little-endian unsigned int */
>    "%2lu"   /* Width, 16-bit little-endian unsigned int */
>    "%2lu"   /* Height, 16-bit little-endian unsigned int */
>    /* following is the "Packed" Byte consisting of five bit fields */
>    "%3b"   /* #colorbits, 3-bit field */
>    "%2b"   /* reserved, 2-bit field */
>    "%1b"   /* local colortable sort flag, 1-bit field */
>    "%1b"   /* interlace flag, 1-bit field */
>    "%1b",  /* local colortable flag, 1-bit field */
>    0x2C, col0, row0, ncols, nrows, ncolorbits, 0, 0, 0,
> (colortable==NULL?0:1) );

Thanks for the alternative spec. I'll keep it in mind.
I agree that your format's more sprintf-like. Maybe I
should "deprecate" that literal requirement. More
about why in response to your specific remarks below...

> Notice that whitespace is _not_ ignored and that there are ten arguments
> corresponding to ten format specifiers.

Both of which I'd consider bad news. Certainly, ignoring
whitespace is different. But notice that your format string
has none. And likely never would, because how often is
whitespace going to be part of a binary packet format
specification? So it's basically no use for this particular
purpose.
   And you also don't get constants in your formats.
Instead, you've got that 0x2C and 0,0,0 in the arguments
which "force-feeds" the "%1b" specifiers. And which
the user has to know about. Instead, I'm moving those
same 0x2C and 0's into the format string
preceding the %1b. Different, again, but serves
the purpose better. The user shouldn't have to
remember magic numbers like 0x2C, and where to put
them.
   Instead, maybe some .h file with all the format
strings describing the packets for some particular
protocol/whatever would embed all that info and
hide it from the user. He'd just say something like,
  #include "packetformatstrings.h"
  unsigned char *thispacketbuffer = malloc(whatever);
  ...
  smemf(thispacketbuffer, thispacketformatstring,
    all,the,numbers,I,actually,care,about,and,no,others);
And that would do the entire job, with the user taking
care of his business only, and the binary packet formatting
pretty much entirely handled for him.

> I also used %u rather than %d
> since I'm pretty sure those ints are supposed to be unsigned (but I'm
> not sure that makes a difference here).
> 
> Of course, your use of "%ld" to mean "little-endian word" rather than
> "long signed integer" is a major difference as well, though that's
> forgivable since you obviously need more control over representation
> than sprintf()'s specifiers offer.  When thinking it through, though,
> that was the point at which I decided that trying to reuse those
> specifiers was probably more trouble than it was worth.

Forget the characters %u vs %d and length modifier, flags, etc.
That's easily/trivially changed. In fact, I'd already changed
my mind to %<d or (%<u if you prefer) for little endian,
and the obvious for big, but might change it again.
Just focus on the functionality. The format string syntax,
at least so far as specifiers, flags, modifiers, etc are
concerned, can be decided later. For now, they're just
illustrative -- you have to write something while discussing it.

> S
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

packed structs JohnF <john@please.see.sig.for.email.com> - 2012-09-22 01:54 +0000
  Re: packed structs Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-21 23:22 -0400
    Re: packed structs JohnF <john@please.see.sig.for.email.com> - 2012-09-22 06:37 +0000
      Re: packed structs "BartC" <bc@freeuk.com> - 2012-09-22 13:47 +0100
        Re: packed structs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-22 14:00 +0100
        Re: packed structs JohnF <john@please.see.sig.for.email.com> - 2012-09-22 15:42 +0000
      Re: packed structs Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-22 09:13 -0400
      Re: packed structs Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-09-23 03:10 +0200
        Re: packed structs JohnF <john@please.see.sig.for.email.com> - 2012-09-23 02:10 +0000
      Re: packed structs Stephen Sprunk <stephen@sprunk.org> - 2012-09-23 11:44 -0500
        Re: packed structs JohnF <john@please.see.sig.for.email.com> - 2012-09-23 23:23 +0000
          Re: packed structs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-24 01:59 +0100
            Re: packed structs JohnF <john@please.see.sig.for.email.com> - 2012-09-24 02:54 +0000
              Re: packed structs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-24 04:38 +0100
                Re: packed structs JohnF <john@please.see.sig.for.email.com> - 2012-09-24 04:07 +0000
                Re: packed structs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-24 12:16 +0100
                Re: packed structs JohnF <john@please.see.sig.for.email.com> - 2012-09-24 11:45 +0000
              Re: packed structs "BartC" <bc@freeuk.com> - 2012-09-24 10:18 +0100
                Re: packed structs JohnF <john@please.see.sig.for.email.com> - 2012-09-24 11:04 +0000
                Re: packed structs Stephen Sprunk <stephen@sprunk.org> - 2012-09-30 14:21 -0500
                Re: packed structs JohnF <john@please.see.sig.for.email.com> - 2012-10-01 07:34 +0000
                Re: packed structs Stephen Sprunk <stephen@sprunk.org> - 2012-10-15 00:46 -0500
          Re: packed structs Stephen Sprunk <stephen@sprunk.org> - 2012-09-30 13:52 -0500
    Re: packed structs Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-22 01:31 -0700
      Re: packed structs JohnF <john@please.see.sig.for.email.com> - 2012-09-22 08:53 +0000
        Re: packed structs Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-09-22 14:17 +0000
          Re: packed structs JohnF <john@please.see.sig.for.email.com> - 2012-09-22 15:33 +0000
            Re: packed structs Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-09-22 20:43 +0000
            Re: packed structs "BartC" <bc@freeuk.com> - 2012-09-22 22:52 +0100
          Re: packed structs Keith Thompson <kst-u@mib.org> - 2012-09-22 13:47 -0700
            Re: packed structs JohnF <john@forkosh.com.com> - 2012-09-23 00:19 +0000
              Re: packed structs Ian Collins <ian-news@hotmail.com> - 2012-09-23 13:32 +1200
                Re: packed structs JohnF <john@please.see.sig.for.email.com> - 2012-09-23 02:16 +0000
        Re: packed structs Ian Collins <ian-news@hotmail.com> - 2012-09-23 10:33 +1200
          Re: packed structs Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-23 01:38 -0700
  Re: packed structs The Great Firewall of China Blue <chine.bleu@yahoo.com> - 2012-09-21 21:29 -0700
  Re: packed structs W Karas <wkaras@yahoo.com> - 2012-10-16 09:13 -0700

csiph-web