I agree the plexit call is bad, I put it in primarily for debugging and I've been thinking of alternatives.
I'm going to implement your idea. I'm going to add a data type suffix to each command. Arrays will also have a size passed (which is what plbuf currently does). The data type prefix will also help maintain compatibility with older plot metafiles if data types change (like the coordinates). With the change to maintain two-byte alignment, there is an unused byte with each command. My plan is to use the unused byte to store the data type. > On Jan 29, 2015, at 5:17 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > > Hi Jim > In general plexit calls are bad. In fact it is on my to do list to go > through and eradicate them. > > However, I'm not sure what alternative there is as the rendering > cannot continue, because once an unknown command is found there is no > way to know how many bytes to skipto find the next command. So perhaps > in the near term this is the only option. Other options which may be > better, but may need more time than available this release cycle would > be: > 1) Simply halt rendering. Once we find a bad command we just don't > render any more buffer, but we allow the rendering up to that point to > persist and we return cleanly to the calling function. A call to > plabort would indicate that the attempted action was aborted. > 2) As I mentioned before we change the buffer code so that we include > the size of the data for every command, even when the data size is > fixed or zero. This means that we will always be able to skip an > unknown command. This would then just require a plwarn call to > indicate an unknown command. > > Phil > >> On 29 January 2015 at 03:33, Jim Dishaw <j...@dishaw.org> wrote: >> I guess it would help if I would attach the patch! >> >> >> >>> On Jan 28, 2015, at 9:59 PM, Jim Dishaw <j...@dishaw.org> wrote: >>> >>> While working on the plot metafile, I fixed a segfault issue that Phil was >>> having with his wxWidgets work. I made a patch that fixes this issue. I >>> don't know about the need to push this to patch to master. The only >>> jarring behavior is a plexit() call that I put in plbuf_control() to catch >>> unrecognized commands. It is way to catch problems in the plot buffer when >>> working on the code. >>> >>> The patch also has some other changes, but there was no easy way to make a >>> patch without those changes. A quick summary of the changes: >>> >>> Removed unneeded malloc() and memcpy for LINE, POLYINE, and FILL when >>> remaking the plot. Temporary storage was used because of the old >>> file-based buffer approach. With the removal of file-based buffer >>> code, a different apporach that uses pointers into the plot buffer could >>> be used. >>> >>> Fixed the bug that caused random segfaults. This could be manifested >>> in several ways, one of them being a POLYLINE with over a billion nodes. >>> The root cause was a mismatch in the data sizes between the buffer writer >>> and the buffer reader (a wrong sizeof() was used). Changed the code >>> to use sizeof(variable) instead of sizeof(data type). >>> >>> Changed the buffer writer to maintain two-byte alignment. This should >>> avoid the performance penalty associated with misaligned arrays. >>> ------------------------------------------------------------------------------ >>> Dive into the World of Parallel Programming. The Go Parallel Website, >>> sponsored by Intel and developed in partnership with Slashdot Media, is your >>> hub for all things parallel software development, from weekly thought >>> leadership blogs to news, videos, case studies, tutorials and more. Take a >>> look and join the conversation now. http://goparallel.sourceforge.net/ >>> _______________________________________________ >>> Plplot-devel mailing list >>> Plplot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming. The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net/ >> _______________________________________________ >> Plplot-devel mailing list >> Plplot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
