Nice work.
I think requiring 1.2.3 is fine, those
such as myself with older versions are very few and can live with suboptimal
stability/broken g_snprintf()
If you run
grep sprintf | sed -e "s/:.*$//" | sort | uniq
in epan and epan/dissectors
you get a lot of hits.
Can you update the wiki and add a section that all these files need to
be audited and fixed up?
On 8/18/05, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> Hi List!
>
> I've almost finished the changing from snprintf to g_snprintf.
>
> This way, we can remove the somewhat bogus snprintf.c/.h files hopefully
> soon.
>
>
> While I'm looking at the handling of the snprintf return values, I've
> noticed some possible bugs.
>
> The return value of some snprintf implementations (and g_snprintf too)
> can return different values if the buffer given was too short, depending
> on the implementation, see:
> http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Functions.html#g-snprintf.
>
> I've checked all appearances of snprintf (and replaced almost any of
> them with g_snprintf) and found two files which seem to not properly
> taking care of this return value (and I don't see a simple solution
> myself):
>
> - epan\dissectors\packet-ieee80211.c (8 times)
> - plugins\asn1\packet-asn1.c (only 1 time)
>
> a correct sequence could look like:
>
> retval = snprintf(buffer, bufferlen, format, value);
> if (retval == -1 || retval >= bufferlen) {
> /* appropriate error handling */
> }
> /* use retval */
>
> The appearance of -1 will only happen with GLib versions prior to 1.2.3,
> which will make deep trouble at other places as well, as it won't zero
> terminate the string.
>
> We might add a note that we require at least GLib 1.2.3 somewhere.
>
>
> Could someone with more knowledge of these dissectors fix this, as it is
> very certain in my eyes that this could lead to a crash.
>
> Regards, ULFL
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>