Re: ICU4C proposal: Formalizing the ustdio format specifiers

va_arg can't help me to do type checking, promotion or demotion.  It can 
only help me to figure out how to cast the data type.  Type checking can't 
be done with va_arg, especially on HP-UX.

As a reminder, ICU doesn't use int, long or size_t types anywhere else. It 
is undesirable for ICU to do that.  For instance, you can look at 
ustring.h.  You will notice that we don't use size_t, but we use int32_t 
instead.  The size_t varies quite wildly.

Our ustring.h implementation is C99-like, but it has different function 
names.  It also uses different types for arguments.  Our ustdio 
implementation will also be C99-like, but we are trying to avoid compiler 
defined types with varying sizes.

This discussion can go on for a while, and that is why I'm postponing work 
on int64_t.  If this is a big issue for you, I encourage you to bring it 
up at the next icu phone meeting on the 23rd.


It's much simpler than Bob's original formatting/parsing process.  No 
chains are used or needed.

1) ustdio first searches for a % format.
2) check what type was specified
3) ask for that type from va_arg and cast it to the proper type
4) execute callback to handle that argument
5) go back to format parsing


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




"Mark Davis" <[email protected]>
07/10/2003 11:48 AM

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



I agree that we could promote (or for that matter demote) types in
printf.

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
__________________________________
http://www.macchiato.com
►  “Eppur si muove” ◄

----- Original Message -----
From: "Robert Buck" <[email protected]>
To: "Mark Davis" <[email protected]>; "George Rhoten"
<[email protected]>
Cc: <[email protected]>
Sent: Thursday, July 10, 2003 11:33
Subject: RE: ICU4C proposal: Formalizing the ustdio format specifiers




> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Mark
Davis
> Sent: Thursday, July 10, 2003 2:08 PM
> To: Robert Buck; George Rhoten
> Cc: [email protected]
> Subject: Re: ICU4C proposal: Formalizing the ustdio format
specifiers
>
>
> > - if the user specifies 'l' with d, i, or u, then do integral
> promotion to
> >   an int32_t, int32_t, or uint32_t.
> > - if the user specifies 'll' with d, i, or u, then do integrat
> promotion to
> >   an int64_t, int64_t, or uint64_t.
>
> We can't do this in scanf. It's got to be exactly the right type.

To say that means we aren't quite communicating clearly. Let me say it
another way.

If for instance I pass in a 'short' value as the subsequent argument
to format specifier of '%d', or '%ld', the internal code to your
implementation of scanf assigns the value to a int32_t. For each
format specifier there must be exactly one argument. The format
specifier maps to a particular type, chosen by platform convention.
The format-type and format-value are stored in a slot. The
format-value
I am presuming is stored in an opaque data type structure. The
format-type
indicates which method to use to retrieve the value later when
printing
it out. The retrieval of the value from the opaque data type structure
_may_ involve truncation or loss or misrepresentation of data [again,
mentioned elsewhere in the standard]. Hence what the standard says,
with my
interjections:

"... unsigned char argument (the argument will have been promoted
according to the integer promotions [to an internal type
whose size is sizeof(int)], but its value shall be converted to
signed char or unsigned char before printing); or that ..."

I am presuming your code first parses the format specifier to identify
the types involved, associates them to subsequent arguments in
'slots',
you then chain them in order of occurance, that the chain defines an
execution context of some sort, and for each slot in the context you
execute the appropriate functions, passing by reference the buffer to
which the functions are to write to.

Given this, what do you mean by "it's got to be exactly the right
type".

Bob