[eeps] EEP extended packet options

[Tony Rogvall]

Hi!
I am a EEP newbie, and it's fun to get reactions immediately ;-)

I will not defend the naming of the options proposed. The intention here is to get
the functionality. I will probably propose something similar for the pipe driver if this EEP is accepted.

I wanted to touch as few files as possible to get the work done.

I will update the proposal. Since we MUST keep the {packet,<n>} options, I still 
think that {packet, - <n>} is not too bad. A immediate question is if {packet,8} is
to defined in parallell to {packet,{8,big}} ?

Well...

Thanks

/Tony

 

On 8 sep 2010, at 16.59, Daniel Goertzen wrote:

> Funny, I just tripped on the endian issue about 2 weeks ago.  I would love
> to see better packet control.
> 
> The negative number idea would seem non-obvious when reading code.  If you
> are proposing a definitions like...
> 
> {packet, {size,8}}
> 
> why not also do that for endian control...
> 
> 
> {packet, {4, little}}
> {packet, {4, big}}
> {packet, {4, native}}
> 
> 
> I intentionally put the number before the endian indicator so that the order
> resembles bit syntax more closely.  Also, the endian indicators are the same
> as used in bit syntax.  I think leveraging people's knowledge of bit-syntax
> would be a plus.
> 
> A minor nitpick... I would suggest {fixed, 8} (or {8, fixed}) over {size,
> 8}.  "size" can be ambiguous in this context, "fixed" is less so.
> 
> Regards,
> Dan.
> 
> 
> On Wed, Sep 8, 2010 at 1:03 AM, Tony Rogvall <tony@REDACTED> wrote:
> 
>> 
>> ________________________________________________________________
>> eeps (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:eeps-unsubscribe@REDACTED