FreeTDS Development Group

[Brian Bruns <brian AT bruns.com>]

Iteration is relatively easy with the addition of a couple more fields
to the structure (function type which lets you know what kind of thing
we are dealing with scalar or array, the element size and type, and so
forth), one challenge is you need some sort of proper memory pool to
handle malloc/free.  So, one would make the function tds_get_array and
pass a count and reader for that sub-element instead of tds_get_uint16
or whatever.

The NGiNX web server does this sort of arrangement for reading config
files and it works fairly well.

Wish I had more time to do some of this, it's an interesting problem.
If I get really motivated this week, I'll submit some sample patches
(the other *very* nice piece is you can tackle one token stream at a
time, it's not all or nothing).

Speaking of which, this big work would go much easier if we were all
on git.  Anybody ready to make that a reality?

Brian

On Mon, Aug 22, 2011 at 11:43 AM, James K. Lowden <jklowden AT freetds.org> 
wrote:
> On Mon, 22 Aug 2011 10:53:02 -0400
> Brian Bruns <brian AT bruns.com> wrote:
>
>> If I'm understanding you correctly, you want a structure with an enum
>> and essentially an array of void * to all the elements and then to use
>> it you need to cast the void * back depending on the value of the
>> attached datatype?
>
> Yes, it's an array of aliases to the members of the struct.  And,
> because void*, they'd have to be cast.
>
>> struct {
>>    uint16 flags;
>>    uint16 unknown;
>>    uint32 rowcount;
>> } tds_done_inproc;
>>
>> tds_member_t done_in_proc_reader[] = {
>> {
>> offsetof(tds_done_inproc, flags),
>> tds_read_uint16
>> },
>> {
>> offsetof(tds_done_inproc, unknown),
>> tds_read_uint16
>> },
>> {
>> offsetof(tds_done_inproc, rowcount),
>> tds_read_uint32
>> },
>> };
>>
>> The nice part is this is easily generated from a table of grammars,
>> and you get a nice usable structure on the other end (as opposed to a
>> nameless array of elements if I'm understanding you correctly), no
>> casting from void * necessary.  Do the same in reverse for
>> writing..things like XOR key password could be a function and you just
>> pass the plain text and the function pointer handles the ugly bits.
>
> Thank you.  Yes, that's the kind of thing I hope to get from the
> formal grammar.  Not having ever actually used a parser-generator, I
> had in mind a more brute-force method.  I agree the above is more
> attractive.
>
> The key is to be able to iterate over the struct elements, for both
> input and output.
>
> Regards,
>
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>