connolly@convex.com (Dan Connolly) (06/07/91)
I posted to complain about error checking in the doc app, with hopes that
the library code would be better, but I just found this:
char metrics_path[100];
sprintf(metrics_path, "%s/%s.afm", ps_metrics_dir, psname);
If you ask me, this is just a bug waiting to happen. There are these arbitrary
constants for the length of strings all over the place! There's no excuse
when C++ makes it so easy to:
char metrics_path = new char[srtlen(ps_metrics_dir) + 1 +
strlen(psname) + sizeof(".afm") + 1];
sprintf(metrics_path, "%s/%s.afm", ps_metrics_dir, psname);
And all the parsing with sscanf is driving me nuts! First of all, there
are differences between sun's sscanf and our (ANSI, POSIX) sscanf, especially
in what they return. (Matcheditor::HandleChar is a prime example).
I can't imagine nobody's been bitten by these undocumented assumptions
all over the code.
Danlinton@marktwain.rad.sgi.com (Mark Linton) (06/13/91)
In article <1991Jun07.011552.16316@convex.com>, connolly@convex.com (Dan Connolly) writes: |> I posted to complain about error checking in the doc app, with hopes that |> the library code would be better, but I just found this: |> |> char metrics_path[100]; |> sprintf(metrics_path, "%s/%s.afm", ps_metrics_dir, psname); |> |> If you ask me, this is just a bug waiting to happen. There are these arbitrary |> constants for the length of strings all over the place! There's no excuse |> when C++ makes it so easy to: |> |> char metrics_path = new char[srtlen(ps_metrics_dir) + 1 + |> strlen(psname) + sizeof(".afm") + 1]; |> sprintf(metrics_path, "%s/%s.afm", ps_metrics_dir, psname); Agreed, though your use of "sizeof" appears wrong to me. I think you want strlen there as well. |> And all the parsing with sscanf is driving me nuts! First of all, there |> are differences between sun's sscanf and our (ANSI, POSIX) sscanf, especially |> in what they return. (Matcheditor::HandleChar is a prime example). I don't understand this (other than you are frustrated). Please try to submit a more substantive bug report (and please send it to interviews-bugs). |> I can't imagine nobody's been bitten by these undocumented assumptions |> all over the code. We don't get bitten by ones as obvious as this one, as the choice of constants like 100 reduces the probability to zero. We do get bitten by much more subtle assumptions. I collectively refer to such problems as "bugs" and welcome all reports. Please send bug reports to interviews-bugs@interviews.stanford.edu.