On Jan 23, 2012, at 3:06 PM, Tom Browder wrote:
> Keith, I made some string handling changes, but I'm not sure from your
> code what you expect the "%*s" format specifier to do. Original code:
>
> bu_vls_printf(&top_vls, "%*s", cp - bu_vls_addr(&dmp->dm_pathName),
> bu_vls_addr(&dmp->dm_pathName));
>
> Changed code:
>
> bu_vls_strncpy(&top_vls, (const char
> *)bu_vls_addr(&dmp->dm_pathName),
> cp - bu_vls_addr(&dmp->dm_pathName));
>
> The '*' (by my reading of 'man fprintf') says that the first argument
> should be an int that assigns the minimum field width for the incoming
> string. If the string is longer, the field will be expanded to fit
> the string. If the string is longer, the field will be padded on the
> right with sufficient spaces to fill the field.
Looking at that libdm code, it looks like copying the base portion of the
pathName up to a leading "." was what was being intended with the "%*s" format
specifier, but it was wrong.
As you note, the asterisk implies a string minimum (at least for c89+). If
pathName were "X11.123", it'd be trying to extract the "X11" portion.
bu_vls_printf("%*s") probably had implementation that assumed the length was a
maximum (like scanf), not a minimum.
So basically, two issues:
1) The bu_vls_printf() -> bu_vls_strncpy() was a bug fix regardless.
2) There may be some new issue lurking in vls.c after r48962 handling "%*s"
Cheers!
Sean
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
