RE: ICU4C proposal: Formalizing the ustdio format specifiers

I think we have a naming conflict with node, chain, cstring, promotion and 
conversion, especially since ustdio doesn't use nodes, chains or a cstring 
type.  I currently don't have any plans to use linked lists, and va_arg 
doesn't have a reliable way to do type checking based on just the 
arguments.  The format string is the only source of type information that 
I have.

The ustdio library will be written similar to how ustdio currently works. 
If you read the current state of the code, you may get a better 
understanding of how things will be done.  The general algorithm won't 
drastically change from what it is now, unless you're offering your 
development time :-)

The ustdio.h header also contains many other things that I plan to fix or 
implement.  Hopefully the information in that header will give you a 
better idea of the scope and size of the problem before we go off too far 
into the weeds.

George Rhoten
IBM Globalization Center of Competency/ICU  San Jose, CA, USA




"Robert Buck" <[email protected]>
07/10/2003 12:26 PM

 
        To:     "Mark Davis" <[email protected]>, George Rhoten/San Jose/IBM@IBMUS
        cc:     <[email protected]>
        Subject:        RE: ICU4C proposal: Formalizing the ustdio format specifiers




> However, one uses the same format string for printf and for scanf. In
> scanf, the results are dumped into variables of the specified type,
> with no error checking. If they are not the right type, bad things
> happen.
>
> Mark

Again, isn't this just the same picture, just backwards?

Here, I assume, from the format string we identify all patterns that are 
format specifiers, and those that are not. Those that are not identify the 
delimiters. Using the list of delimiters, get the set of substrings that 
represent the values to be converted from strings to 'whatever' from the 
source buffer. The set of format specifiers prescribe the format-types. 
The format-values here are strings, so set the type-id for the opaque data 
types of the slots to 'cstring', chain them in appropriate order, execute 
the context. The destination value type for each is that prescribed by 
format-type. After you have performed the conversion you check to see if 
the output type matches the temporary, or has a conversion between the 
two. If there is a conversion, perform it. Otherwise error. The opaque 
data type would look something like the following quick hack:

struct context
{
// list of conversions to do...
struct node
{
// used for dest in printf, source in scanf
char sb[64]; // off stack
char* hb;    // off heap if necessary
char* ptr_to_which; // ptr to above

// used as source in printf, as dest in scanf
typedef union
{
char* sval;
int8_t i8;
int16_t i16;
int32_t i32;
int64_t i64;
double  d;
float   s;
// others...
} glob_t;
glob_t gt;

// descriptor
typedef enum
{
one for each above;
} desc_t;
desc_t ty;

} * exec_list;
size_t list_len; // how many conversions
}

For each of the nodes and destination values in a scanf, a dynamic data 
conversion is performed. If no reasonable conversion exists, then it 
throws an exception, which you trap, and do the normal C thing.

I would think it would work something like that. Yes, no? I have not 
written such a beast, so that would be my best guess.

Bob Buck