On Sun, Jul 24, 2011 at 8:57 AM, Brad Huntting <[email protected]> wrote:
> 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?
I was referring to the int -> long conversion.
Still, the question remains as to why there was a bug with an int
value in the first place, because it seems like moving to a long would
only cause more issues (if not during the compile, at runtime on
various 32-bit vs 64-bit architectures).
FWIW I'm assuming that sizeof(int32_t) == sizeof(int) on all
architectures until proven otherwise:
# 64-bit compiled python
$ uname -mo; python -c 'import ctypes; print "sizeof(int) ->",
ctypes.sizeof(ctypes.c_int)'
amd64 FreeBSD
sizeof(int) -> 4
# -m32 compiled python
$ uname -mo ; python2.6 -c 'import ctypes; print "sizeof(int) ->",
ctypes.sizeof(ctypes.c_int)'
i686 GNU/Linux
sizeof(int) -> 4
# -m32 vs -m64 on linux (just as a control)
$ cat test_m32.c
#include <stdio.h>
int
main(void)
{
printf("sizeof(int) -> %zu\n", sizeof(int));
return (0);
}
$ gcc -o test_m32_m64 test_m32.c
$ gcc -m32 -o test_m32_m32 test_m32.c
$ uname -mo
x86_64 GNU/Linux
$ ./test_m32_m64
sizeof(int) -> 4
$ ./test_m32_m32
sizeof(int) -> 4
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
