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

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

The assignment for today's lesson

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

  The assignment for today's lesson "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-12 19:10 +0800
    Re: The assignment for today's lesson Robert Spanjaard <spamtrap@arumes.com> - 2016-11-12 16:38 +0100
      Re: The assignment for today's lesson "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-12 23:43 +0800
        Re: The assignment for today's lesson Robert Spanjaard <spamtrap@arumes.com> - 2016-11-12 21:36 +0100
          Re: The assignment for today's lesson "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-13 14:30 +0800
            Re: The assignment for today's lesson Your Name <YourName@YourISP.com> - 2016-11-13 19:37 +1300
              [OT] chat "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-13 14:40 +0800
                Re: [OT] chat Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2016-11-13 08:58 +0100
                  Re: [OT] chat "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-13 18:46 +0800
            Re: The assignment for today's lesson Robert Spanjaard <spamtrap@arumes.com> - 2016-11-13 11:25 +0100
              Re: The assignment for today's lesson "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-13 18:47 +0800
          Re: New assignment/homework "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-13 14:32 +0800
            Re: New assignment/homework Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-13 10:05 +0000
              [OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-13 18:47 +0800
          Re: The assignment for today's lesson Ike Naar <ike@iceland.freeshell.org> - 2016-11-13 20:48 +0000
            Re: The assignment for today's lesson Robert Spanjaard <spamtrap@arumes.com> - 2016-11-13 22:29 +0100
              Re: The assignment for today's lesson "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-13 16:38 -0500
                Re: The assignment for today's lesson Gareth Owen <gwowen@gmail.com> - 2016-11-13 22:24 +0000
            Re: The assignment for today's lesson "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-13 16:37 -0500
              Re: The assignment for today's lesson Ike Naar <ike@iceland.freeshell.org> - 2016-11-14 09:39 +0000
          Re: The assignment for today's lesson Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-13 19:07 -0500
            Re: The assignment for today's lesson Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-11-13 19:42 -0500
              Re: The assignment for today's lesson Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-13 21:47 -0500
                Re: The assignment for today's lesson Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-11-14 10:39 -0500
                  Re: The assignment for today's lesson Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-14 11:38 -0500
                  Re: The assignment for today's lesson "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-14 12:15 -0500
                    Re: The assignment for today's lesson Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-14 16:01 -0500
              Re: The assignment for today's lesson Richard Damon <Richard@Damon-Family.org> - 2016-11-13 22:25 -0500
                Re: The assignment for today's lesson Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 12:05 +0000
              Re: The assignment for today's lesson "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-14 12:14 -0500
                Re: The assignment for today's lesson Keith Thompson <kst-u@mib.org> - 2016-11-14 09:50 -0800
            Re: The assignment for today's lesson Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 00:42 +0000
              Re: The assignment for today's lesson Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-13 21:48 -0500

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

#96517

On 11/12/2016 3:36 PM, Robert Spanjaard wrote:
> On 12-11-16 16:43, Mr. Man-wai Chang wrote:
>> On 12/11/2016 11:38 PM, Robert Spanjaard wrote:
>>>
>>> I can't. System reports a Clown Overflow everytime it encounters
>>> "trump".
>>>
>>
>> You are NOT doing the homework. :)
> 
> Ok, ok...
> 
> #include <stdio.h>
> 
> int main()
> {   
>    char    chewb;    /* current character being processed */
>    int    r2d2,    /* number of numbers */
>        c3po;    /* number of letters */
> 
>    while ((chewb = getchar()) != EOF)
>       if ((chewb >= 'a' && chewb <= 'z') || (chewb >= 'A' && chewb <= 'Z'))

Fails for non-ASCII character sets.

>          ++c3po;
>       else if (chewb >= '0' && chewb <= '9')

Fails for non-ASCII character sets.

>          ++r2d2;
> 
>    printf("Number of letters: %i\nNumber of numbers: %i\n", c3po, r2d2);
>    return 0;
> }
> 
> Be careful to only run this once. Chewbacca doesn't like doing all the hard
> work, and letting the droids get away with the results.
> 



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#96518

On Sunday November 13 2016 19:07, in comp.lang.c, "Jerry Stuckle"
<jstucklex@attglobal.net> wrote:

> On 11/12/2016 3:36 PM, Robert Spanjaard wrote:
>> On 12-11-16 16:43, Mr. Man-wai Chang wrote:
>>> On 12/11/2016 11:38 PM, Robert Spanjaard wrote:
>>>>
>>>> I can't. System reports a Clown Overflow everytime it encounters
>>>> "trump".
>>>>
>>>
>>> You are NOT doing the homework. :)
>> 
>> Ok, ok...
>> 
>> #include <stdio.h>
>> 
>> int main()
>> {   
>>    char    chewb;    /* current character being processed */
>>    int    r2d2,    /* number of numbers */
>>        c3po;    /* number of letters */
>> 
>>    while ((chewb = getchar()) != EOF)
>>       if ((chewb >= 'a' && chewb <= 'z') || (chewb >= 'A' && chewb <= 'Z'))
> 
> Fails for non-ASCII character sets.
> 
>>          ++c3po;
>>       else if (chewb >= '0' && chewb <= '9')
> 
> Fails for non-ASCII character sets.

Not really.

5.2.1 Character Sets
  3  Both the basic source and basic execution character sets shall have the
     following members: the 26 uppercase letters of the Latin alphabet
       A B C D E F G H I J K L M
       N O P Q R S T U V W X Y Z
     the 26 lowercase letters of the Latin alphabet
       a b c d e f g h i j k l m
       n o p q r s t u v w x y z
     the 10 decimal digits
       0 1 2 3 4 5 6 7 8 9 
     ...
     In both the source and execution basic character sets, the value of each
     character after 0 in the above list of decimal digits shall be one
     greater than the value of the previous.

Thus, the test is valid.

If the environment uses an execution character set that does not guarantee
that numerics follow in the C execution characterset standard, I would guess
that the whole platform would induce "undefined behaviour".

>>          ++r2d2;
>> 
>>    printf("Number of letters: %i\nNumber of numbers: %i\n", c3po, r2d2);
>>    return 0;
>> }
>> 
>> Be careful to only run this once. Chewbacca doesn't like doing all the hard
>> work, and letting the droids get away with the results.
>> 
> 
> 
> 


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#96523

On 11/13/2016 7:42 PM, Lew Pitcher wrote:
> On Sunday November 13 2016 19:07, in comp.lang.c, "Jerry Stuckle"
> <jstucklex@attglobal.net> wrote:
> 
>> On 11/12/2016 3:36 PM, Robert Spanjaard wrote:
>>> On 12-11-16 16:43, Mr. Man-wai Chang wrote:
>>>> On 12/11/2016 11:38 PM, Robert Spanjaard wrote:
>>>>>
>>>>> I can't. System reports a Clown Overflow everytime it encounters
>>>>> "trump".
>>>>>
>>>>
>>>> You are NOT doing the homework. :)
>>>
>>> Ok, ok...
>>>
>>> #include <stdio.h>
>>>
>>> int main()
>>> {   
>>>    char    chewb;    /* current character being processed */
>>>    int    r2d2,    /* number of numbers */
>>>        c3po;    /* number of letters */
>>>
>>>    while ((chewb = getchar()) != EOF)
>>>       if ((chewb >= 'a' && chewb <= 'z') || (chewb >= 'A' && chewb <= 'Z'))
>>
>> Fails for non-ASCII character sets.
>>
>>>          ++c3po;
>>>       else if (chewb >= '0' && chewb <= '9')
>>
>> Fails for non-ASCII character sets.
> 
> Not really.
> 
> 5.2.1 Character Sets
>   3  Both the basic source and basic execution character sets shall have the
>      following members: the 26 uppercase letters of the Latin alphabet
>        A B C D E F G H I J K L M
>        N O P Q R S T U V W X Y Z
>      the 26 lowercase letters of the Latin alphabet
>        a b c d e f g h i j k l m
>        n o p q r s t u v w x y z
>      the 10 decimal digits
>        0 1 2 3 4 5 6 7 8 9 
>      ...
>      In both the source and execution basic character sets, the value of each
>      character after 0 in the above list of decimal digits shall be one
>      greater than the value of the previous.
> 
> Thus, the test is valid.
> 

That defines the characters in the set.  But it does not define the
numeric values of the characters.  And it is the numeric values which
are being compared.

EBCDIC, for instance, uses entirely different numeric values for the
characters.  The numeric values follow in sequential order, but the
character values do not.  And the paragraph only refers to 0-9.

> If the environment uses an execution character set that does not guarantee
> that numerics follow in the C execution characterset standard, I would guess
> that the whole platform would induce "undefined behaviour".
> 

Numerics do.  But alphabetics do not.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#96537

On Sunday November 13 2016 21:47, in comp.lang.c, "Jerry Stuckle"
<jstucklex@attglobal.net> wrote:

> On 11/13/2016 7:42 PM, Lew Pitcher wrote:
>> On Sunday November 13 2016 19:07, in comp.lang.c, "Jerry Stuckle"
>> <jstucklex@attglobal.net> wrote:
>> 
>>> On 11/12/2016 3:36 PM, Robert Spanjaard wrote:
>>>> On 12-11-16 16:43, Mr. Man-wai Chang wrote:
>>>>> On 12/11/2016 11:38 PM, Robert Spanjaard wrote:
>>>>>>
>>>>>> I can't. System reports a Clown Overflow everytime it encounters
>>>>>> "trump".
>>>>>>
>>>>>
>>>>> You are NOT doing the homework. :)
>>>>
>>>> Ok, ok...
>>>>
>>>> #include <stdio.h>
>>>>
>>>> int main()
>>>> {   
>>>>    char    chewb;    /* current character being processed */
>>>>    int    r2d2,    /* number of numbers */
>>>>        c3po;    /* number of letters */
>>>>
>>>>    while ((chewb = getchar()) != EOF)
>>>>       if ((chewb >= 'a' && chewb <= 'z') || (chewb >= 'A' && chewb <=
>>>>       'Z'))
>>>
>>> Fails for non-ASCII character sets.
>>>
>>>>          ++c3po;
>>>>       else if (chewb >= '0' && chewb <= '9')
>>>
>>> Fails for non-ASCII character sets.
>> 
>> Not really.
>> 
>> 5.2.1 Character Sets
>>   3  Both the basic source and basic execution character sets shall have
>>   the
>>      following members: the 26 uppercase letters of the Latin alphabet
>>        A B C D E F G H I J K L M
>>        N O P Q R S T U V W X Y Z
>>      the 26 lowercase letters of the Latin alphabet
>>        a b c d e f g h i j k l m
>>        n o p q r s t u v w x y z
>>      the 10 decimal digits
>>        0 1 2 3 4 5 6 7 8 9
>>      ...
>>      In both the source and execution basic character sets, the value of
>>      each character after 0 in the above list of decimal digits shall be
>>      one greater than the value of the previous.
>> 
>> Thus, the test is valid.
>> 
> 
> That defines the characters in the set.

It defines the basic characters in both the source character set (the
characterset used in the source code) and the execution character set (the
characterset used in the execution of the program).

> But it does not define the numeric values of the characters.

It defines the /relationship/ between those numeric values; it has no need to
define the values themselves. The /relationship/ between the numeric values
of the "decimal digit" characters is /defined/ as being monotonic sequential,
with the numeric value of the digit '1' being one greater than the numeric
value of the digit '0', and so on. That's what
>>      In both the source and execution basic character sets, the value of
>>      each character after 0 in the above list of decimal digits shall be
>>      one greater than the value of the previous.
means


> And it is the numeric values which are being compared.


> EBCDIC, for instance, uses entirely different numeric values for the
> characters.  The numeric values follow in sequential order, but the
> character values do not.

Nonsense.

In all EBCDIC variants, the "numeric digits" extend monotonically from 0xF0
through 0xF9, with 0xF0 representing the '0', 0xF1 representing the '1', and
so on.

You would be correct /if/ we were talking about alphabetics. But we are not.


> And the paragraph only refers to 0-9.

And that's what the test
>>>>       else if (chewb >= '0' && chewb <= '9')
is all about: the "numeric digits" '0' through '9', and their relationship to
each other.

Do you deny that, if chewb has a value greater than or equal to '0' AND less
than or equal to '9', then chewb represents a "numeric digit"? 

>> If the environment uses an execution character set that does not guarantee
>> that numerics follow in the C execution characterset standard, I would
>> guess that the whole platform would induce "undefined behaviour".
>> 
> 
> Numerics do.  But alphabetics do not.

And we (at least, from my original post onwards) are talking about numerics.

I accept that you have conceded the point.
-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#96540

On 11/14/2016 10:39 AM, Lew Pitcher wrote:
> On Sunday November 13 2016 21:47, in comp.lang.c, "Jerry Stuckle"
> <jstucklex@attglobal.net> wrote:
> 
>> On 11/13/2016 7:42 PM, Lew Pitcher wrote:
>>> On Sunday November 13 2016 19:07, in comp.lang.c, "Jerry Stuckle"
>>> <jstucklex@attglobal.net> wrote:
>>>
>>>> On 11/12/2016 3:36 PM, Robert Spanjaard wrote:
>>>>> On 12-11-16 16:43, Mr. Man-wai Chang wrote:
>>>>>> On 12/11/2016 11:38 PM, Robert Spanjaard wrote:
>>>>>>>
>>>>>>> I can't. System reports a Clown Overflow everytime it encounters
>>>>>>> "trump".
>>>>>>>
>>>>>>
>>>>>> You are NOT doing the homework. :)
>>>>>
>>>>> Ok, ok...
>>>>>
>>>>> #include <stdio.h>
>>>>>
>>>>> int main()
>>>>> {   
>>>>>    char    chewb;    /* current character being processed */
>>>>>    int    r2d2,    /* number of numbers */
>>>>>        c3po;    /* number of letters */
>>>>>
>>>>>    while ((chewb = getchar()) != EOF)
>>>>>       if ((chewb >= 'a' && chewb <= 'z') || (chewb >= 'A' && chewb <=
>>>>>       'Z'))
>>>>
>>>> Fails for non-ASCII character sets.
>>>>
>>>>>          ++c3po;
>>>>>       else if (chewb >= '0' && chewb <= '9')
>>>>
>>>> Fails for non-ASCII character sets.
>>>
>>> Not really.
>>>
>>> 5.2.1 Character Sets
>>>   3  Both the basic source and basic execution character sets shall have
>>>   the
>>>      following members: the 26 uppercase letters of the Latin alphabet
>>>        A B C D E F G H I J K L M
>>>        N O P Q R S T U V W X Y Z
>>>      the 26 lowercase letters of the Latin alphabet
>>>        a b c d e f g h i j k l m
>>>        n o p q r s t u v w x y z
>>>      the 10 decimal digits
>>>        0 1 2 3 4 5 6 7 8 9
>>>      ...
>>>      In both the source and execution basic character sets, the value of
>>>      each character after 0 in the above list of decimal digits shall be
>>>      one greater than the value of the previous.
>>>
>>> Thus, the test is valid.
>>>
>>
>> That defines the characters in the set.
> 
> It defines the basic characters in both the source character set (the
> characterset used in the source code) and the execution character set (the
> characterset used in the execution of the program).
> 
>> But it does not define the numeric values of the characters.
> 
> It defines the /relationship/ between those numeric values; it has no need to
> define the values themselves. The /relationship/ between the numeric values
> of the "decimal digit" characters is /defined/ as being monotonic sequential,
> with the numeric value of the digit '1' being one greater than the numeric
> value of the digit '0', and so on. That's what
>>>      In both the source and execution basic character sets, the value of
>>>      each character after 0 in the above list of decimal digits shall be
>>>      one greater than the value of the previous.
> means
> 
> 
>> And it is the numeric values which are being compared.
> 
> 
>> EBCDIC, for instance, uses entirely different numeric values for the
>> characters.  The numeric values follow in sequential order, but the
>> character values do not.
> 
> Nonsense.
> 
> In all EBCDIC variants, the "numeric digits" extend monotonically from 0xF0
> through 0xF9, with 0xF0 representing the '0', 0xF1 representing the '1', and
> so on.
> 
> You would be correct /if/ we were talking about alphabetics. But we are not.
> 
> 
>> And the paragraph only refers to 0-9.
> 
> And that's what the test
>>>>>       else if (chewb >= '0' && chewb <= '9')
> is all about: the "numeric digits" '0' through '9', and their relationship to
> each other.
> 
> Do you deny that, if chewb has a value greater than or equal to '0' AND less
> than or equal to '9', then chewb represents a "numeric digit"? 
> 
>>> If the environment uses an execution character set that does not guarantee
>>> that numerics follow in the C execution characterset standard, I would
>>> guess that the whole platform would induce "undefined behaviour".
>>>
>>
>> Numerics do.  But alphabetics do not.
> 
> And we (at least, from my original post onwards) are talking about numerics.
> 
> I accept that you have conceded the point.
> 

We were talking about both alphabetics and numerics.  I already admitted
I missed the point about numerics.

I accept that you concede the point about alphabetics.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#96543

On 11/14/2016 10:39 AM, Lew Pitcher wrote:
> On Sunday November 13 2016 21:47, in comp.lang.c, "Jerry Stuckle"
> <jstucklex@attglobal.net> wrote:
>
>> On 11/13/2016 7:42 PM, Lew Pitcher wrote:
>>> On Sunday November 13 2016 19:07, in comp.lang.c, "Jerry Stuckle"
>>> <jstucklex@attglobal.net> wrote:
...
>>>>>    while ((chewb = getchar()) != EOF)
>>>>>       if ((chewb >= 'a' && chewb <= 'z') || (chewb >= 'A' && chewb <=
>>>>>       'Z'))
>>>>
>>>> Fails for non-ASCII character sets.

And also for many locales other than the "C" locale.
...
>>> Not really.

Apparently you intended "Not really." to apply only to the immediately 
preceding objection by Jerry, rather than applying to both objections. 
But you quoted both objections, which doesn't make sense if you were 
only responding to one of them.

>>> 5.2.1 Character Sets
>>>   3  Both the basic source and basic execution character sets shall have
>>>   the
>>>      following members: the 26 uppercase letters of the Latin alphabet
>>>        A B C D E F G H I J K L M
>>>        N O P Q R S T U V W X Y Z
>>>      the 26 lowercase letters of the Latin alphabet
>>>        a b c d e f g h i j k l m
>>>        n o p q r s t u v w x y z
...
>>> Thus, the test is valid.

You quoted two tests, and two corresponding objections by Jerry. You 
didn't make it clear which of the two quoted tests was the one you were 
claiming is valid.

>> That defines the characters in the set.
...
>> EBCDIC, for instance, uses entirely different numeric values for the
>> characters.  The numeric values follow in sequential order, but the
>> character values do not.
>
> Nonsense.
>
> In all EBCDIC variants, the "numeric digits" extend monotonically from 0xF0
> through 0xF9, with 0xF0 representing the '0', 0xF1 representing the '1', and
> so on.
>
> You would be correct /if/ we were talking about alphabetics. But we are not.

I removed all of the quoted material above that talks about the decimal 
digits. There still seems to be a lot of material talking about 
alphabetic characters. If you were responding only to his comment about 
the decimal digits, why did you include all of the above quoted material 
in each of your subsequent responses?

...
>> ...  But alphabetics do not.
>
> And we (at least, from my original post onwards) are talking about numerics.

Not as far as I can tell - Jerry is clearly talking about both, and your 
original post failed to make any such distinction.

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

#96576

On 11/14/2016 12:15 PM, James R. Kuyper wrote:
> On 11/14/2016 10:39 AM, Lew Pitcher wrote:
>>
>> And we (at least, from my original post onwards) are talking about
>> numerics.
> 
> Not as far as I can tell - Jerry is clearly talking about both, and your
> original post failed to make any such distinction.
> 

Yes, and I already admitted I was wrong about the numerics.  I missed
the section in the standard quoted by Ben.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#96525

On 11/13/16 7:42 PM, Lew Pitcher wrote:
> On Sunday November 13 2016 19:07, in comp.lang.c, "Jerry Stuckle"
> <jstucklex@attglobal.net> wrote:
>
>> On 11/12/2016 3:36 PM, Robert Spanjaard wrote:
>>> On 12-11-16 16:43, Mr. Man-wai Chang wrote:
>>>> On 12/11/2016 11:38 PM, Robert Spanjaard wrote:
>>>>>
>>>>> I can't. System reports a Clown Overflow everytime it encounters
>>>>> "trump".
>>>>>
>>>>
>>>> You are NOT doing the homework. :)
>>>
>>> Ok, ok...
>>>
>>> #include <stdio.h>
>>>
>>> int main()
>>> {
>>>    char    chewb;    /* current character being processed */
>>>    int    r2d2,    /* number of numbers */
>>>        c3po;    /* number of letters */
>>>
>>>    while ((chewb = getchar()) != EOF)
>>>       if ((chewb >= 'a' && chewb <= 'z') || (chewb >= 'A' && chewb <= 'Z'))
>>
>> Fails for non-ASCII character sets.
>>
>>>          ++c3po;
>>>       else if (chewb >= '0' && chewb <= '9')
>>
>> Fails for non-ASCII character sets.
>
> Not really.
>
> 5.2.1 Character Sets
>   3  Both the basic source and basic execution character sets shall have the
>      following members: the 26 uppercase letters of the Latin alphabet
>        A B C D E F G H I J K L M
>        N O P Q R S T U V W X Y Z
>      the 26 lowercase letters of the Latin alphabet
>        a b c d e f g h i j k l m
>        n o p q r s t u v w x y z
>      the 10 decimal digits
>        0 1 2 3 4 5 6 7 8 9
>      ...
>      In both the source and execution basic character sets, the value of each
>      character after 0 in the above list of decimal digits shall be one
>      greater than the value of the previous.
>
> Thus, the test is valid.
>
> If the environment uses an execution character set that does not guarantee
> that numerics follow in the C execution characterset standard, I would guess
> that the whole platform would induce "undefined behaviour".
>
>

One question becomes does the problem statement of 'numbers' and 
'letters' include just the standard 'Latin' characters, or since the 
message was sent as UTF-8, there is a possibility that we may need to 
detect other characters beyond those as numbers and letters, and thus 
need to use isalpha() and isdigit() after setting the appropriate locale.

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

#96533

Richard Damon <Richard@Damon-Family.org> writes:
<snip>

> One question becomes does the problem statement of 'numbers' and
> 'letters' include just the standard 'Latin' characters, or since the
> message was sent as UTF-8, there is a possibility that we may need to
> detect other characters beyond those as numbers and letters, and thus
> need to use isalpha() and isdigit() after setting the appropriate
> locale.

A slightly more interesting question since I've not actually written
that program before.  I don't think you can easily handle UTF-8 using
the non-wide versions of isxxxx, but this should do it:

  #include <stdio.h>
  #include <stdlib.h>
  #include <stdbool.h>
  #include <locale.h>
  #include <wchar.h>
  #include <wctype.h>

  int main(void)
  {
       setlocale(LC_ALL, "");

       wint_t wc;
       unsigned nl = 0, nd = 0;

       while ((wc = getwchar()) != WEOF) {
            nl += (bool)iswalpha(wc);
            nd += (bool)iswdigit(wc);
       }

       printf("%u %u\n", nl, nd);
       return ferror(stdin) ? EXIT_FAILURE : EXIT_SUCCESS;
  }

-- 
Ben.

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

#96542

On 11/13/2016 07:42 PM, Lew Pitcher wrote:
...
> 5.2.1 Character Sets
>   3  Both the basic source and basic execution character sets shall have the
>      following members: ...
...
>      the 10 decimal digits
>        0 1 2 3 4 5 6 7 8 9
>      ...
>      In both the source and execution basic character sets, the value of each
>      character after 0 in the above list of decimal digits shall be one
>      greater than the value of the previous.
...
> If the environment uses an execution character set that does not guarantee
> that numerics follow in the C execution characterset standard, I would guess
> that the whole platform would induce "undefined behaviour".

Not quite - "undefined behavior" is a characteristic of a program; a 
characteristic that's relevant only when using a conforming 
implementation to translate and execute the program. What you're 
describing would be a non-conforming implementation. Non-conformance 
doesn't make behavior undefined, it just means that the implementation 
fails to implement the behavior defined by the standard for such code.

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

#96550

"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 11/13/2016 07:42 PM, Lew Pitcher wrote:
[...]
>> If the environment uses an execution character set that does not guarantee
>> that numerics follow in the C execution characterset standard, I would guess
>> that the whole platform would induce "undefined behaviour".
>
> Not quite - "undefined behavior" is a characteristic of a program; a 
> characteristic that's relevant only when using a conforming 
> implementation to translate and execute the program. What you're 
> describing would be a non-conforming implementation. Non-conformance 
> doesn't make behavior undefined, it just means that the implementation 
> fails to implement the behavior defined by the standard for such code.

To be annoyingly pedantic, "undefined behavior" is

    behavior, upon use of a nonportable or erroneous program construct
    or of erroneous data, for which this International Standard imposes
    no requirements

The standard certainly imposes no requirements on the behavior of
non-conforming implementations, or of programs that depend on them.

On the other hand, it's a little silly to apply terms defined by the
standard to non-conforming implementations.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#96519

Jerry Stuckle <jstucklex@attglobal.net> writes:
<snip>
>>       else if (chewb >= '0' && chewb <= '9')
>
> Fails for non-ASCII character sets.

If the decimal digits are not contiguous and in the normal order, the
implementation is not conforming.  So while there may be some character
sets without this property (which one are you thinking of?) there can be
no confirming C implementation that uses one.

In short, a C programmer can rely on the fact that '1' == '0'+1, '2' ==
'1'+1 and so on up to '9' == '8'+1.  If you can't, you are programming
in a similar language that is not entirely unlike C.

<snip>
-- 
Ben.

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

#96524

On 11/13/2016 7:42 PM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> <snip>
>>>       else if (chewb >= '0' && chewb <= '9')
>>
>> Fails for non-ASCII character sets.
> 
> If the decimal digits are not contiguous and in the normal order, the
> implementation is not conforming.  So while there may be some character
> sets without this property (which one are you thinking of?) there can be
> no confirming C implementation that uses one.
> 
> In short, a C programmer can rely on the fact that '1' == '0'+1, '2' ==
> '1'+1 and so on up to '9' == '8'+1.  If you can't, you are programming
> in a similar language that is not entirely unlike C.
> 
> <snip>
> 

True for the numerics.  But not for the alphabetics.  I had forgotten
about the exception for numerics.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [standalone]

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

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

csiph-web