Wireshark-dev: Re: [Wireshark-dev] Sprintf weirdness
From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Wed, 2 Jun 2010 07:03:13 +0200
Hi,With "%lu" you tell sprintf to expect a 32 bit value on the stack, while in fact you put 64 bit sized value 0 there. That reads like two times 32 bit sized value 0, hence the results you see.
The rest is left as an exercise to the reader ;) Thanks, Jaap Send from my iPhone On 2 jun 2010, at 06:01, Ian Schorr <ian.schorr@xxxxxxxxx> wrote:
Hello list, This isn't exactly a Wireshark-specific question, but it's coming up while I'm working on a dissector, and I'm sure someone here will know the answer, so... =) I'm trying to use sprintf() to append to an existing string with some formatted text. Obviously there's several ways to do this, but sprintf() seemed to be most efficient for the way I'm doing things. I end up appending this string to the Info Column later, but that seems irrelevant. For example, I have 4 variables: - string mystring, with value "LOCK" - guint32 last_fh_hash, with value "2056735708" - guint64 file_offset, with value 0 - guint64 lock_length, with value 10 The weird thing is that when I do this: sprintf (mystring, "%s FH: 0x%08x Offset: %lu Length: %lu", mystring,last_fh_hash,file_offset,lock_length); ...then "mystring" becomes "LOCK FH: 0x7a974bdc Offset: 0 Length: 0". Length is WRONG. It is wrong in a very consistent way. But if I do this: sprintf (mystring, "%s FH: 0x%08x", mystring,last_fh_hash); sprintf (mystring, "%s Offset: %u", mystring,file_offset); sprintf (mystring, "%s Length: %u", mystring,lock_length); Then the resulting value of mystring is correct. "LOCK FH: 0x7a974bdc Offset: 0 Length: 10". In fact, if I flip the positions of "file_offset" and "lock_length" then things are fine, regardless of their values. It's difficult to reproduce or debug. I have a number of similar statements scattered throughout code and each has varying degrees of strangeness. Some work properly. In some cases the values are actually flipped (one variable printed one place, the other in another). In some cases the values are actually empty. I can't imagine it has anything to do with the way the string was declared or memory allocated in the first place, it looks like sprintf() is simply writing out the wrong values to memory for some reason. Anybody have any thoughts on why that might be? I'm assuming I've done something silly, though having a tough time guessing where. I haven't tested yet to see if this is something specific to the dev platform I'm using. At the moment that's Windows. Thanks, Ian ___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
- Follow-Ups:
- Re: [Wireshark-dev] Sprintf weirdness
- From: Ian Schorr
- Re: [Wireshark-dev] Sprintf weirdness
- References:
- [Wireshark-dev] Sprintf weirdness
- From: Ian Schorr
- [Wireshark-dev] Sprintf weirdness
- Prev by Date: Re: [Wireshark-dev] Sprintf weirdness
- Next by Date: Re: [Wireshark-dev] Sprintf weirdness
- Previous by thread: Re: [Wireshark-dev] Sprintf weirdness
- Next by thread: Re: [Wireshark-dev] Sprintf weirdness
- Index(es):