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" <rbuck@...>
07/10/2003 12:26 PM
To: "Mark Davis" <mark.davis@...>, George Rhoten/San Jose/IBM@...
cc: <icu@...>
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
|