> Is there a reason that T_STRING types of memberlist elements
> cause a "TypeError" to be raised?
>
> I have an element that I NEED to be as T_STRING type, but setmember()
> will not allow that. You can READ T_STRING types, but now WRITE to it..
> I know there is a problem with the possibility of overwriting the end
> of the buffer passed in, but this can be tested for..
>
> Since there will ALWAYS going to be an element AFTER a T_STRING element,
> we could have it look at the offset on the element AFTER the T_STRING
> element and the subtract 1 and then that will give the length allowed.
> If the string is longer than that length, then an exception could be
> raised OR just truncate..
The T_STRING member type is intended for struct members of type "char
*", not for struct members of type "char[]" as you seem to be implying
(the patch you sent me privately changes the meaning to "char[]"!)
My preferred solution would be to add a new type T_BUFFER which means
a member of type char[], with a way to specify the length explicitly.
(I don't like the idea of looking at the next element because theg
elements may not be listed in ascending order, and sometimes some
elements are not listed at all, e.g. when their type in inexpressible.)
For binary compatibility (important in the light of dynamically loaded
modules!), I would propose the following hack to store the length:
the type proper is only the lower 4 bits (this is just sufficient for
the current set of types), the length is in the upper 12 or 28 bits
(12 bits on machines where ints are 2 bytes, like some Mac or PC
compilers). This lets you specify buffers of up to 4095 bytes if you
are careful. (Alternatively, you could overload the readonly field --
if it is <= 0, the value is writable, if it is > 0, it is readonly.
This gives you 15 bits for the size.)
Note that Donald Beaudry has proposed (in private email) a much more
general mechanism which should take care of this and other
restrictions of the structmember.[ch] files. However this would
require rewriting all code that currently uses structmember, and also
I believe Donald was still pondering ways to make his solution even
more general, so I'm not sure whether it will appear in the next
release...
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>