[prev in list] [next in list] [prev in thread] [next in thread] 

List:       net-snmp-coders
Subject:    Re: Oid Type rationalization in 5.6.1
From:       Dave Shield <D.T.Shield () liverpool ! ac ! uk>
Date:       2011-05-10 22:20:07
Message-ID: BANLkTinQXkt+20LE0ovyO0Sbf8q+fFN1nQ () mail ! gmail ! com
[Download RAW message or body]

On 10 May 2011 18:02, Leo Cacciari <leo.cacciari@gmail.com> wrote:
>     Anyhow, this only confirms what I said: old typedef with
> u_long was wrong, new one is right.

I don't think there's any real argument about that.
If we were starting from a blank canvas, then we would
use explicit 32-bit types for 32-bit quantities.

But unfortunately that's not the case - we've inherited a lot
of design decisions (some from the underlying CMU code,
others from earlier incarnations of UCD or Net-SNMP code).

So the question is how best to manage the transition from
a sub-optimal (and/or fundamentally broken) state, to an
improved one - with the minimal amount of pain.

This is something we've had to face on a number of occasions,
some minor, some more major (e.g. the complete re-working
of the internal model of how the agent implements MIB modules!)

One design policy that we've tried to keep to is that incompatible
changes (however desirable they might be), should only be made
as part of a major release, not a minor one.   We slipped up here.
The "right time" to make this change was probably with 5.7,
not 5.6.1.
   But that's water under the bridge - we need to decide how best
to go forward from where we are *now* - not where we'd have liked
to be.



>                      If any binary incompatibility
> arises, then it will be on platform with 64bits longs, where the old
> typedef produced not-conforming implementation with 64bits oid.

Also bear in mind that there are two incompatibilities here.
One is an ABI change (which probably only affects 64-bit systems).
The other is an API change, which could affect other code as well.
Both of these are undesirable (but have happened)
  The question is how we deal with them.

But that's probably best thrashed out on Wes' new thread.
(tomorrow! - I'm going to bed now...)

Dave

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
[prev in list] [next in list] [prev in thread] [next in thread]