How can using an explicitly sized int32_t expose more archetectual
differences than using an archetecturely dependent long?
Brad
On Jul 23, 2011 11:43 PM, "Garrett Cooper" <[email protected]> wrote:
> On Sat, Jul 23, 2011 at 5:18 PM, Ilya Yanok <[email protected]> wrote:
>> Hi Robert,
>>
>> On 19.07.2011 00:20, Robert Story wrote:
>>> IY> Type of snmp_enableauthentraps variable is changed from int to long.
>>> IY> This fixes the bug with writing to snmpEnableAuthenTraps if server
is
>>> IY> compiled for 64bit (snmpset reports wrong length). This bug was
>>> IY> introduced a long time ago (by faeecd0 commit).
>>>
>>> Please submit all patches to the patch tracker.
>>
>> Surely I know about the patch tracker but I hoped to start some
>> discussion here cause I think my patch fixes only the manifestation of
>> the problem not the problem itself.
>>
>> Why do we use long to store 32bit integers? Shouldn't we change it to be
>> int32_t? At very least we should make it 'transparent' to the MIB code:
>> it should be possible to register watched ASN_INTEGER instance with 4
>> bytes size and this should work as expected. User (MIB code) doesn't
>> need to know internal details (type used internally to store the value).
>>
>> What do you think?
>
> This fix seems questionable, esp. because it exposes more issues
> with 32-bit vs 64-bit, as int types typically default to 4-byte
> integers on popular Unix based OSes, e.g. FreeBSD, Linux, NetBSD, etc.
> What architecture is the client/server compiled on and what
> OS/distro are they compiled on?
> Thanks,
> -Garrett
>
>
------------------------------------------------------------------------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> _______________________________________________
> Net-snmp-coders mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
------------------------------------------------------------------------------
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide. Store less, Store more with what you own, Move data to
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
