On Tue, May 10, 2011 at 06:04:47PM -0700, Wes Hardaker wrote:
> > On Tue, 10 May 2011 22:38:04 +0200, Niels Baggesen
> > said:
>
> NB> This one is still outstanding, making it impossible to compile things
> NB> outside the source directory. It is certainly a show stopper for a 5.7
> NB
> On Tue, 10 May 2011 22:38:04 +0200, Niels Baggesen
> said:
NB> This one is still outstanding, making it impossible to compile things
NB> outside the source directory. It is certainly a show stopper for a 5.7
NB> release.
What can't compile outside the source tree?
But the real answ
On 10 May 2011 18:02, Leo Cacciari 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
Den 27-03-2011 11:43, Magnus Fromreide skrev:
>> Shouldn't be considered as part of the
>> ABI ? I think it should be installed too.
>
> I do not know. Either it should be and then obviously be installed but
> that would make all the generated symbols public or it shouldn't be and
> in that case i
[I'm glad this thread is finally getting attention; it's an important one]
History:
- oid has always been typecast since the dawn of time as a u_long
- in fact, almost every int in our system is typecast as u_long,
dating back to the original CMU code. This includes 32 bit SNMP
Den 10-05-2011 19:02, Leo Cacciari skrev:
> Ok, let's say 32 bit platforms (which, by today standards would be
> subnormal ;)) Anyhow, this only confirms what I said: old typedef with
> u_long was wrong, new one is right. If any binary incompatibility
> arises, then it will be on platform with 64bi
Il 05/10/2011 06:33 PM, Bart Van Assche ha scritto:
> On Tue, May 10, 2011 at 5:46 PM, Leo Cacciari wrote:
>> For "normal" platforms, where a long _is_
>> a 32 bits integer then both typedefs lead to exactly the same binary output.
> Depends on what you call "normal". With gcc on a 64-bit Linux sy
On Tue, May 10, 2011 at 5:46 PM, Leo Cacciari wrote:
> For "normal" platforms, where a long _is_
> a 32 bits integer then both typedefs lead to exactly the same binary output.
Depends on what you call "normal". With gcc on a 64-bit Linux system a
long contains 64 bits (eight bytes), not 32:
$ un
On 05/04/2011 11:34 PM, Wes Hardaker wrote:
> RJA> Can someone explain the rationalization of changing oid definition
> RJA> from a long to a 32bit integer in net-snmp 5.6.1?
>
> Well, a couple of points:
>
> 1) an OID actually is limited to 32 bits, so the newer type makes some
>sense.
Is way
The beginning of the 5.7 release-cycle has started. The first
pre-release is now available for testing. Only bug fixes will be
applied beyond this point to the SVN trunk.
Side important note: Sometime later this month, the Net-SNMP project
will be switching to git for housing it's code-base.
h
On 10 May 2011 13:25, Niels Baggesen wrote:
> Indeed, it is the very last moment to get a fix rolling. It is still
> 15 days to release of Fedora 15.
>
> I would say that we need to revert it and make a point release of 5.6.1.1
I'm no expert on the Fedora release process, but I'd be amazed
if we
On Tue, May 10, 2011 at 12:05:41PM +0200, Bart Van Assche wrote:
> Since the policy is to preserve the API and ABI in a branch, it's
> unfortunate that this change happened in the 5.6 branch. But reverting that
> change is not an option IMHO: as you can see in one of the Fedora
> repositories (http
On Wed, May 4, 2011 at 4:49 PM, Robinson, Jayson A <
jayson.a.robin...@jpmchase.com> wrote:
> Can someone explain the rationalization of changing oid definition from a
> long to a 32bit integer in net-snmp 5.6.1?
>
>
>
> From pre net-snmp 5.6.1 ( We found this definition in every version
> histor
On 10 May 2011 00:08, Wes Hardaker wrote:
> 2) We can, however, extend [the Host Resources MIB] by adding objects to the
> Net-SNMP MIB tree that adds the needed functionality or definitions.
> For things like this, we'd need to create an extension table in the
> Net-SNMP tree, which is a bit mor
14 matches
Mail list logo
