From: Marc_Verwerft/BE/Cimad%IBMBE <Marc_Verwerft/BE/<Ci...@be...> - 2001-11-22 16:18:32
|
Bjorn Reese wrote : >So, returning to option 2, the error flag in the trio_class_t >(formerly known as trio_T) structure may server two purposes. >First, it must be checked before returning from the printf >functions (TrioFormat, TrioFormatRef, or TrioFormatProcess >depending on what is more appropriate). - The error flag is checked on return of TrioFormatProcess. > Second, it could be >checked in TrioOutStreamStringDynamic() to avoid trying to >allocate more memory, as we know it will only fail. OK, will do. But I need clarification on the 'processed' count in the trio_class_t structure. If I understand it right then for each call to TrioOutStreamStringDynamic it should be incremented regardless of whether or not the call succeeded. Right ? > We could >also consider checking the error flag at other strategic >positions in the code to terminate earlier, but this is not >strictly necessary. Not done. >I like the idea about being able to specify the default size. >Implementing a dynamic string API seems a little over the top >though; we do not really need most of the functions in trio, >and it is unlikely that other will use them. How about adding >a single function to set parameters? For example Good idea. Only, the parameters you set this way are used as 'globals' for the ...printf calls. What if two threads need different sizes ? Therefore I prefer the ..._sized function. Anyhow, the trio_set_parameter call fits very well in the general architecture of the trio library and will be a 'nice-to-have-feature'. For the time being, I didn't implement it yet. >> 3. I agree on the naming, how about 'trio_dynstr_...' or 'trio_ds_...' ? > >'ds' as in Daniel Stenberg? :) Couldn't agree more. I've added the modifications I've done so far. Have fun. (See attached file: trio.c.diff) (See attached file: trio.h.diff) (See attached file: dynstring_example.c) Regards, Marc Verwerft internet address : marc_verwerft-at-be-dot-ibm-dot-com. |