gdb and memory caching?

Russ Allbery rra at
Tue Nov 3 00:42:21 UTC 2009

Julien ÉLIE <julien at> writes:

> Then, what I do not understand is that gdb mentions that l is 7
> whereas it was changed to 5.
> Is it a gdb bug?  (Very strange.)
> Isn't gdb returning the current value of l?

I suspect the compiler may be aggressively optimizing because the code
here is invalid.

>    /* Scribble onto end of Keywords: after a magic separator. */
>    strlcpy(hc->Value + l, ",\377", innconf->keylimit + 1 - l);
>    for (chase = hc->Value + l + 2, word_index = 0;
>        word_index < distinct_words;
>        word_index++) {

>        /* Add to list. */
>        *chase++ = ',';
>        strlcpy(chase, word[word_vec[word_index].index],
>                innconf->keylimit + 1 - (chase - hc->Value));
>        chase += word_vec[word_index].length;

>        if (chase - hc->Value > (innconf->keylimit - (MAX_WORD_LENGTH + 4)))
>            break;
>    }

> chase is first set to "hc->Value + l + 2" even though it is beyond
> the end of hc->Value; then a "," is added even though it is beyond
> the end of hc->Value; and the comparison might be unsigned (size_t)
> and therefore be wrong if the second member is negative.

chase can't be set to point more than one character beyond the end of the
string without becoming an invalid pointer, after which the calculation
(chase - hc->Value) becomes undefined according to the C standard.  I
suspect we need an additional check earlier here to catch that case and
not let this occur.

Or just remove the code to add a magic separator and then more keywords.
I think it's entirely reasonable to not set the Keywords header if one
already exists.  I remember there being some discussion of this when the
code went in originally, and the original submitter wasn't sure that this
code was a good idea.

Russ Allbery (rra at             <>

    Please send questions to the list rather than mailing me directly.
     <> explains why.

More information about the inn-workers mailing list