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

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

Simple(?) Unicode questions

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

Contents

  Simple(?) Unicode questions Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-09 08:04 +0100
    Re: Simple(?) Unicode questions Richard Damon <richard@damon-family.org> - 2023-12-09 08:01 -0500
    Re: Simple(?) Unicode questions jak <nospam@please.ty> - 2023-12-09 15:59 +0100
      Re: Simple(?) Unicode questions Spiros Bousbouras <spibou@gmail.com> - 2023-12-09 15:32 +0000
        Re: Simple(?) Unicode questions jak <nospam@please.ty> - 2023-12-09 18:57 +0100
    Re: Simple(?) Unicode questions Spiros Bousbouras <spibou@gmail.com> - 2023-12-09 15:12 +0000
      Re: Simple(?) Unicode questions Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-09 17:59 +0100
        Re: Simple(?) Unicode questions Spiros Bousbouras <spibou@gmail.com> - 2023-12-09 17:19 +0000
          Re: Simple(?) Unicode questions Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-09 18:43 +0100
      Re: Simple(?) Unicode questions Spiros Bousbouras <spibou@gmail.com> - 2023-12-09 17:40 +0000
      Re: Simple(?) Unicode questions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-09 13:46 -0800
    Re: Simple(?) Unicode questions spender <spender@yeah.net> - 2023-12-13 11:05 +0800
      Re: Simple(?) Unicode questions Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-13 04:24 +0100
      Re: Simple(?) Unicode questions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-12 19:28 -0800
      Re: Simple(?) Unicode questions James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-12-13 00:40 -0500
        Re: Simple(?) Unicode questions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-19 07:43 -0800
      Re: Simple(?) Unicode questions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-12-13 14:56 +0000
        Re: Simple(?) Unicode questions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-25 02:03 -0800
          Re: Simple(?) Unicode questions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-25 14:43 -0800
            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

Page 2 of 2 — ← Prev page 1 [2]

#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]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web