Jeff Morriss
changed
bug 9323
| What |
Removed |
Added |
| Status |
CONFIRMED
|
RESOLVED
|
| Resolution |
---
|
FIXED
|
Comment # 10
on bug 9323
from Jeff Morriss
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > > I tried to modify the function to use g_strlcpy in order to respect both the
> > > > length *and* any possible null-terminator but that just moved the source of
> > > > the error to the g_strlcpy call. That makes me suspect the length being
> > > > passed in is incorrect, but I cannot track down how.
> > >
> > > I didn't try that yet but the length looks OK to me (length is 48 though the
> > > 'line' is "Accept-Charset" through the end of the packet and into wiretap's
> > > unused space).
> >
> > Actually the problem there is in the g_strlcpy() documentation. To quote:
> >
> > "src must be nul-terminated;"!
>
> Dangit, I assumed that because "At most dest_size - 1 characters will be
> copied" it didn't need to be null-terminated if it was longer than that.
> Welp.
Yeah, I thought the same thing. Then I happened across that line...
> I think the best way to properly include this logic is to enhance
> string_fvalue_set (ftype-string.c) to correctly handle already_copied==TRUE
> (instead of asserting), then use g_strndup (simpler than g_malloc+strncpy)
> in proto_tree_set_string and pass that into fvalue_set() with
> already_copied=TRUE.
Nice idea. I was dreading the idea of passing length down to all the ftype_set
functions or researching whether it was safe to (always) move the strdup up a
level.
Fixed in r52905 and put on the roadmap for 1.10.3 and 1.8.11.
You are receiving this mail because:
- You are watching all bug changes.