Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #380541 > unrolled thread

Re: Simple(?) Unicode questions

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Simple(?) Unicode questions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-20 09:33 -0800
    Re: Simple(?) Unicode questions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-20 14:19 -0800
      Re: Simple(?) Unicode questions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-24 20:38 -0800

#380541 — Re: Simple(?) Unicode questions

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>
>>> On Wed, 13 Dec 2023 11:05:45 +0800, spender wrote:
>>>
>>>> printf("%c",ch), the ch must <0xFF, <255
>>>
>>> Not quite.
>>> 1) ch /must/ represent an integer value.
>>
>> More specifically, it must have a type that is or promotes
>> to int, or a type that is or promotes to unsigned int, with
>> a value that is in the common range of int and unsigned int.
>
> Not quite.  "If no l length modifier is present, the int argument
> is converted to an unsigned char, and the resulting character is
> written."  For example printf("%c", -193) is equivalent to
> printf("%c", 63), which assuming an ASCII-based character set will
> print '?'.

The rule for arguments to printf() is the same as the rule for
accessing variadic arguments using va_arg().  That has always
been true, although not expressed clearly in early versions of
the C standard.  Fortunately that shortcoming is addressed in
the upcoming C23 (is it still not yet ratified?):  in N3096,
paragraph 9 in section 7.23.6.1 says in part

    fprintf shall behave as if it uses va_arg with a type
    argument naming the type resulting from applying the
    default argument promotions to the type corresponding
    to the conversion specification [...]

and the rule for va_arg (in 7.16.1.1 p2) says in part 

    one type is a signed integer type, the other type is
    the corresponding unsigned integer type, and the value
    is representable in both types

So supplying an unsigned int argument is okay, provided of
course the value is in the range of values of signed int.

[toc] | [next] | [standalone]

#380544

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>>> On Wed, 13 Dec 2023 11:05:45 +0800, spender wrote:
>>>>> printf("%c",ch), the ch must <0xFF, <255
>>>>
>>>> Not quite.
>>>> 1) ch /must/ represent an integer value.
>>>
>>> More specifically, it must have a type that is or promotes
>>> to int, or a type that is or promotes to unsigned int, with
>>> a value that is in the common range of int and unsigned int.
>>
>> Not quite.  "If no l length modifier is present, the int argument
>> is converted to an unsigned char, and the resulting character is
>> written."  For example printf("%c", -193) is equivalent to
>> printf("%c", 63), which assuming an ASCII-based character set will
>> print '?'.
>
> The rule for arguments to printf() is the same as the rule for
> accessing variadic arguments using va_arg().  That has always
> been true, although not expressed clearly in early versions of
> the C standard.  Fortunately that shortcoming is addressed in
> the upcoming C23 (is it still not yet ratified?):  in N3096,
> paragraph 9 in section 7.23.6.1 says in part
>
>     fprintf shall behave as if it uses va_arg with a type
>     argument naming the type resulting from applying the
>     default argument promotions to the type corresponding
>     to the conversion specification [...]
>
> and the rule for va_arg (in 7.16.1.1 p2) says in part 
>
>     one type is a signed integer type, the other type is
>     the corresponding unsigned integer type, and the value
>     is representable in both types
>
> So supplying an unsigned int argument is okay, provided of
> course the value is in the range of values of signed int.

Re-reading what you wrote, I think I misunderstood your intent (and I
think what you wrote was ambiguous).

"%c" specifies an int argument.

You wrote:

    More specifically, it must have a type that is or promotes to int,
    or a type that is or promotes to unsigned int, with a value that is
    in the common range of int and unsigned int.

I read that as:

    More specifically,
    (it must have a type that is or promotes to int, or a type that is
    or promotes to unsigned int),
    with a value that is in the common range of int and unsigned int.

which would incorrectly imply that a negative int value is not allowed.

It's now clear to me that you meant was:

    More specifically,
    (it must have a type that is or promotes to int),
    or
    (a type that is or promotes to unsigned int, with a value that is in
    the common range of int and unsigned int).

I agree with that.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#380883

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>>>
>>>>> On Wed, 13 Dec 2023 11:05:45 +0800, spender wrote:
>>>>>
>>>>>> printf("%c",ch), the ch must <0xFF, <255
>>>>>
>>>>> Not quite.
>>>>> 1) ch /must/ represent an integer value.
>>>>
>>>> More specifically, it must have a type that is or promotes
>>>> to int, or a type that is or promotes to unsigned int, with
>>>> a value that is in the common range of int and unsigned int.
>>>
>>> Not quite.  "If no l length modifier is present, the int argument
>>> is converted to an unsigned char, and the resulting character is
>>> written."  For example printf("%c", -193) is equivalent to
>>> printf("%c", 63), which assuming an ASCII-based character set will
>>> print '?'.
>>
>> The rule for arguments to printf() is the same as the rule for
>> accessing variadic arguments using va_arg().  That has always
>> been true, although not expressed clearly in early versions of
>> the C standard.  Fortunately that shortcoming is addressed in
>> the upcoming C23 (is it still not yet ratified?):  in N3096,
>> paragraph 9 in section 7.23.6.1 says in part
>>
>>     fprintf shall behave as if it uses va_arg with a type
>>     argument naming the type resulting from applying the
>>     default argument promotions to the type corresponding
>>     to the conversion specification [...]
>>
>> and the rule for va_arg (in 7.16.1.1 p2) says in part
>>
>>     one type is a signed integer type, the other type is
>>     the corresponding unsigned integer type, and the value
>>     is representable in both types
>>
>> So supplying an unsigned int argument is okay, provided of
>> course the value is in the range of values of signed int.
>
> Re-reading what you wrote, I think I misunderstood your intent (and I
> think what you wrote was ambiguous).
>
> "%c" specifies an int argument.
>
> You wrote:
>
>     More specifically, it must have a type that is or promotes to int,
>     or a type that is or promotes to unsigned int, with a value that is
>     in the common range of int and unsigned int.
>
> I read that as:
>
>     More specifically,
>     (it must have a type that is or promotes to int, or a type that is
>     or promotes to unsigned int),
>     with a value that is in the common range of int and unsigned int.
>
> which would incorrectly imply that a negative int value is not allowed.
>
> It's now clear to me that you meant was:
>
>     More specifically,
>     (it must have a type that is or promotes to int),
>     or
>     (a type that is or promotes to unsigned int, with a value that is in
>     the common range of int and unsigned int).
>
> I agree with that.

Right.  Sorry for the confusion.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web