Hi,
How would you get inconsistency in GP_Context? Context and its attributes are once set-up on context creation and then never modified again (only clipping may be modified afterwards).
That is not true, context orientation flags (axes_swap, mirror_x and mirro_y) could be modified any time. So the actually inconsistency may arise from changing axes_swap.
Maybe I did not point that out enough:
-- Tomas wrote: -- Inconsistency can either be introduced upon creation - either in core lib (we can have a debug check tests there) or manual initialization (should be forbidden); or by modification afterwards - either manually (if anybody modifies these, no CHECKs can save her from doom) or by memory corruption (then the CHECK is useless anyway and not much more informative that SEGV).
While the values CAN be modified by the user (not being const), they MUST NOT. If anybody does that, let them eat steaming *(NULL).
-- Cyril wrote: -- Furthermore as it is now, the orientation flags are inicialized to 0 at the time of the context creation and may only be changed later.
This may be a *temporary* solution, but this must be done by some setup function sooner rather than later. We need to know swap_axes for bytes_per_row in allocation anyway. Requiring user to do this manually and then force her to use GP_ContextWidth is insanity.
Either we declare GP_Context entirely public (declare it read-only xcept for clipping, then drop most wrappers, do sanity checks and keep our fingers crossed) or go with wrappers for everything ESPECIALLY such dangerous internal stuff (such as bytes_per_line and h) and consistently use these wrappers ourselves (if we want to have any chance to be able to modify GP_Context).
We can do either but definitely not both.
Tomas