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

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

strtoll discussion

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

Contents

  strtoll discussion jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-03 14:28 +0200
    Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-03 14:46 +0100
    Re: strtoll discussion Keith Thompson <kst-u@mib.org> - 2015-04-03 11:08 -0700
    Re: strtoll discussion James Kuyper <jameskuyper@verizon.net> - 2015-04-03 15:23 -0400
      Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-03 20:55 +0100
        Re: strtoll discussion glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-03 20:41 +0000
          Re: strtoll discussion Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-03 13:52 -0700
            Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-03 22:25 +0100
              Re: strtoll discussion Bartc <bc@freeuk.com> - 2015-04-04 00:17 +0100
                Re: strtoll discussion Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-03 16:27 -0700
              Re: strtoll discussion Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-04 02:07 +0100
                Re: strtoll discussion Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-04 03:44 -0700
                  Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-04 12:13 +0100
      Re: strtoll discussion James Kuyper <jameskuyper@verizon.net> - 2015-04-03 16:11 -0400
      Re: strtoll discussion Keith Thompson <kst-u@mib.org> - 2015-04-03 14:12 -0700
      Re: strtoll discussion jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-03 23:56 +0200
    Re: strtoll discussion Ian Collins <ian-news@hotmail.com> - 2015-04-04 08:41 +1300
      Re: strtoll discussion jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-03 23:33 +0200
    Re: strtoll discussion James Lothian <james@firstnamelastname.freeserve.co.uk> - 2015-04-03 20:51 +0100
      Re: strtoll discussion asetofsymbols@gmail.com - 2015-04-03 13:09 -0700
        Re: strtoll discussion asetofsymbols@gmail.com - 2015-04-03 13:16 -0700
        Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-03 21:19 +0100
          Re: strtoll discussion asetofsymbols@gmail.com - 2015-04-03 13:28 -0700
            Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-03 22:29 +0100
            Re: strtoll discussion jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-03 23:33 +0200
        Re: strtoll discussion jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-03 23:34 +0200
          Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-03 22:42 +0100
            Re: strtoll discussion Keith Thompson <kst-u@mib.org> - 2015-04-03 15:08 -0700
            Re: strtoll discussion jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-04 00:13 +0200
              Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-03 23:44 +0100
                Re: strtoll discussion jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-04 00:48 +0200
                  Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-04 00:03 +0100
                  Re: strtoll discussion Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-04-03 19:31 -0400
                    Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-04 00:37 +0100
                      Re: strtoll discussion Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-04-04 10:29 -0400
                        Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-04 15:54 +0100
                        Re: strtoll discussion Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-04 08:07 -0700
                          Re: strtoll discussion Bartc <bc@freeuk.com> - 2015-04-04 16:28 +0100
                            Re: strtoll discussion Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-04 08:57 -0700
                              Re: strtoll discussion Bartc <bc@freeuk.com> - 2015-04-04 17:03 +0100
                                Re: strtoll discussion Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-04 09:44 -0700
                                  Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-04 18:05 +0100
                                    Re: strtoll discussion Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-04 23:32 -0700
                                      Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-05 11:00 +0100
                                        Re: strtoll discussion Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-05 13:18 -0700
                                          Re: strtoll discussion Richard Damon <Richard@Damon-Family.org> - 2015-04-05 17:37 -0400
                                            Re: strtoll discussion Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-05 15:00 -0700
                                              Re: strtoll discussion Robert Wessel <robertwessel2@yahoo.com> - 2015-04-05 22:17 -0500
                            Re: strtoll discussion Richard Damon <Richard@Damon-Family.org> - 2015-04-04 18:54 -0400
                              Re: strtoll discussion Bartc <bc@freeuk.com> - 2015-04-05 12:14 +0100
                    Re: strtoll discussion glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-04 00:19 +0000
                  Re: strtoll discussion Keith Thompson <kst-u@mib.org> - 2015-04-03 17:48 -0700
                  Re: strtoll discussion James Kuyper <jameskuyper@verizon.net> - 2015-04-08 11:23 -0400
                    Re: strtoll discussion jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-08 19:35 +0200
                    Re: strtoll discussion Keith Thompson <kst-u@mib.org> - 2015-04-08 10:47 -0700
                      Re: strtoll discussion James Kuyper <jameskuyper@verizon.net> - 2015-04-08 14:22 -0400
    lltostr/ulltostr jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-04 13:56 +0200
      Re: lltostr/ulltostr Richard Heathfield <rjh@cpax.org.uk> - 2015-04-04 13:36 +0100
      Re: lltostr/ulltostr Barry Schwarz <schwarzb@dqel.com> - 2015-04-04 18:54 -0700
        Re: lltostr/ulltostr Ian Collins <ian-news@hotmail.com> - 2015-04-05 14:29 +1200
      Re: lltostr/ulltostr Ralf Damaschke <rwspam@gmx.de> - 2015-04-05 16:58 +0000
        Re: lltostr/ulltostr jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-05 20:39 +0200
          Re: lltostr/ulltostr glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-05 20:19 +0000
        Re: lltostr/ulltostr Keith Thompson <kst-u@mib.org> - 2015-04-05 13:18 -0700
          Re: lltostr/ulltostr Ralf Damaschke <rwspam@gmx.de> - 2015-04-06 14:28 +0000
            Re: lltostr/ulltostr Keith Thompson <kst-u@mib.org> - 2015-04-06 08:40 -0700
    Re: strtoll discussion Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-04 13:04 -0700
      Re: strtoll discussion jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-04 22:52 +0200
        Re: strtoll discussion Richard Heathfield <rjh@cpax.org.uk> - 2015-04-04 22:14 +0100
        Re: strtoll discussion Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-05 00:24 +0100
        Re: strtoll discussion Geoff <geoff@invalid.invalid> - 2015-04-04 16:51 -0700
        Re: strtoll discussion jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-05 23:32 +0200
          Re: strtoll discussion Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-16 09:21 -0700
        Re: strtoll discussion Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 02:21 -0700
      Re: strtoll discussion Keith Thompson <kst-u@mib.org> - 2015-04-04 15:36 -0700
        Re: strtoll discussion Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-16 09:19 -0700
          Re: strtoll discussion Keith Thompson <kst-u@mib.org> - 2015-04-16 10:43 -0700
            Re: strtoll discussion Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 07:59 -0700
    Re: strtoll discussion Philipp Klaus Krause <pkk@spth.de> - 2015-04-07 11:46 +0200

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#59547

I wrote something as:
> the char ' in '0' is wrong for me

Possibly this web news reader
change some char in the post
where there is the numbered
C code 

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

#59548

On 03/04/15 21:09, asetofsymbols@gmail.com wrote:
> James wrote: <<
> 4 int Atoi(char *str)
> 5 {
> 6 int result=0;
> 7 int sign = 0;
> 8
> 9 while (isspace(*str)) str++;
> 10 if (*str == '-') {
> 11 sign = 1;
> 12 str++;
> 13 }
> 14 else if (sign == '+') sign++;
> 15 while (*str) {
> 16 result = result*10 + *str - '0';
> 17 str++;
> 18 }
> 19 if (sign) result = -result;
> 20 return result;
> 21 }
>
> Erm, at the risk of being picky, shouldn't line 14 be
> else if (*str == '+') str ++;
> ?
>
> James>>
>
> Yes...possibly
> The char ' in '0' is wrong for me

'0' isn't a char; it's an int. What do you think is wrong with it?

>
> I would modify
>
> while(*str)
>   {int k;
>   k= *str -'0';
>   if(k>9||k<0) break;
>   result = result*10 + k;
>   str++;
>   }

It's an unnecessary modification. The atoi function is not required to 
spot invalid input, and Jacob's Atoi is an implementation of atoi (the 
only reason for the capital A is to allow people to test it without 
giving their compiler a coughing fit).

There can be value in /not/ spotting problems. Looking for problems 
takes time (albeit not very much time in this case!); if the programmer 
is absolutely sure that there are no problems to find, why waste time 
looking for them? (Of course, if he's wrong, on his own head be it.)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#59549

Richard wrote:
<<
'0' isn't a char; it's an int. What do you think is wrong with it? 


> 
> I would modify 
> 
> while(*str) 
>   {int k; 
>   k= *str -'0'; 
>   if(k>9||k<0) break; 
>   result = result*10 + k; 
>   str++; 
>   } 


It's an unnecessary modification. The atoi function is not required to 
spot invalid input, and Jacob's Atoi is an implementation of atoi (the 
only reason for the capital A is to allow people to test it without 
giving their compiler a coughing fit).>>

That function it is wrong because
end only
 when it meets the end of string 0
and add value for not numbers

For '0'...
I am sure that I had seen `0` 
and not '0' 
Or something as that...

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

#59555

On 03/04/15 21:28, asetofsymbols@gmail.com wrote:
>
> For '0'...
> I am sure that I had seen `0`
> and not '0'
> Or something as that...

That's just the font he's using. No big deal.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#59556

Le 03/04/2015 22:28, asetofsymbols@gmail.com a écrit :
> Richard wrote:
> <<
> '0' isn't a char; it's an int. What do you think is wrong with it?
>
>
>>
>> I would modify
>>
>> while(*str)
>>    {int k;
>>    k= *str -'0';
>>    if(k>9||k<0) break;
>>    result = result*10 + k;
>>    str++;
>>    }
>
>
> It's an unnecessary modification. The atoi function is not required to
> spot invalid input, and Jacob's Atoi is an implementation of atoi (the
> only reason for the capital A is to allow people to test it without
> giving their compiler a coughing fit).>>
>
> That function it is wrong because
> end only
>   when it meets the end of string 0
> and add value for not numbers
>
> For '0'...
> I am sure that I had seen `0`
> and not '0'
> Or something as that...
>

If you continue reading I do an analysis of that "quick and dirty" atoi 
implementation and spot all the problems. That function is an 
introduction to strtoXXX later, to make the essential part of the 
algorithm clear.

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

#59558

Le 03/04/2015 22:09, asetofsymbols@gmail.com a écrit :
> Erm, at the risk of being picky, shouldn't line 14 be
> else if (*str == '+') str ++;

Yes!

Thanks I will correct that ASAP.

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

#59559

On 03/04/15 22:34, jacobnavia wrote:
> Le 03/04/2015 22:09, asetofsymbols@gmail.com a écrit :
>> Erm, at the risk of being picky, shouldn't line 14 be
>> else if (*str == '+') str ++;
>
> Yes!
>
> Thanks I will correct that ASAP.



Also it would do no real harm to adopt the suggestion by 
asetofsymbols@gmail.com to terminate Atoi's conversion when you run out 
of digits, rather than when you run out of string:

while(isdigit(*str)) instead of while(*str) would do it.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#59562

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 03/04/15 22:34, jacobnavia wrote:
>> Le 03/04/2015 22:09, asetofsymbols@gmail.com a écrit :
>>> Erm, at the risk of being picky, shouldn't line 14 be
>>> else if (*str == '+') str ++;
>>
>> Yes!
>>
>> Thanks I will correct that ASAP.
>
> Also it would do no real harm to adopt the suggestion by
> asetofsymbols@gmail.com to terminate Atoi's conversion when you run
> out of digits, rather than when you run out of string:
>
> while(isdigit(*str)) instead of while(*str) would do it.

I could go either way on that.  The presented Atoi() function is
deliberately quick and dirty, with no error checking.  The document
acknowledges this, saying that Atoi("ggg") returns 6105.  It's just a
starting point, showing how to add error checking in later revisions.

It does jump directly from the quick-and-dirty Atoi() to the standard
strto*() functions.  Showing incremental improvements to Atoi() might be
instructive, but it's not clear that it's worth the space.  I suppose it
depends on the intended audience.

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

#59563

Le 03/04/2015 23:42, Richard Heathfield a écrit :
> while(isdigit(*str)) instead of while(*str) would do it.

Yes, that is reasonable, but if you read on, later in the error analysis 
of Atoi I say:

<quote> (end of page 2)
Nowhere we test if the characters we receive represent a number at all. 
For instance, if we call the above function with:

int m = Atoi("ggg");

The value of the m variable will be 6105.
<end quote>

The purpose of Atoi was to make the bare algorithm clear, and to show 
its problems, to pave the way to strtoXXX later.

I will add your suggestion in a footnote:

\footnote{
This problem can be easily fixed with substituting

while (isdigit(*str)) instead of while (*str)
}

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

#59564

On 03/04/15 23:13, jacobnavia wrote:
> Le 03/04/2015 23:42, Richard Heathfield a écrit :
>> while(isdigit(*str)) instead of while(*str) would do it.
>
> Yes, that is reasonable, but if you read on, later in the error analysis
> of Atoi I say:

Yes, I know, and I do see your point.

I actually changed my mind about this; I actually posted a contrary 
view, but later on I checked the Standard and decided that 
asetofsymbols@gmail.com was right.

If (and, to be fair, *only* if) Atoi() is supposed to be an 
implementation of atoi(), then it is actually required to behave as if 
it were called as (int)strtol(s, NULL, 10) - except for the behaviour on 
error.

Now, what the Standard means by "on error" in this context is perhaps 
open to discussion. But strtol, when passed 10 as its third parameter, 
will stop parsing as soon as it hits a non-digit.

So - IF Atoi() is supposed to be a faithful implementation of atoi() - 
it should do this too.

If, on the other hand, the coincidence in names is merely a coincidence 
of no consequence, then of course Atoi() can do what it likes. :-)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#59565

Le 04/04/2015 00:44, Richard Heathfield a écrit :
>
> So - IF Atoi() is supposed to be a faithful implementation of atoi() -
> it should do this too.
>
> If, on the other hand, the coincidence in names is merely a coincidence
> of no consequence, then of course Atoi() can do what it likes. :-)
>

I think it would be better if we would call that first quick and dirty 
implementation

AsciiToInteger

to avoid confusions...

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

#59566

On 03/04/15 23:48, jacobnavia wrote:

<snip>
>
> I think it would be better if we would call that first quick and dirty
> implementation
>
> AsciiToInteger
>
> to avoid confusions...
>

That works for me.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#59569

On Friday April 3 2015 18:48, in comp.lang.c, "jacobnavia"
<jacob@jacob.remcomp.fr> wrote:

> Le 04/04/2015 00:44, Richard Heathfield a écrit :
>>
>> So - IF Atoi() is supposed to be a faithful implementation of atoi() -
>> it should do this too.
>>
>> If, on the other hand, the coincidence in names is merely a coincidence
>> of no consequence, then of course Atoi() can do what it likes. :-)
>>
> 
> I think it would be better if we would call that first quick and dirty
> implementation
> 
> AsciiToInteger
> 
> to avoid confusions...

Would this function expect to accept Unicode text? If so, then perhaps
  UnicodeToInteger()
might be a better name.

The AsciiToInteger name implies that the function accepts ASCII, which is
not Unicode (think BOM handling, 16 and 32bit 'character' handling, etc.)




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

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

#59570

On 04/04/15 00:31, Lew Pitcher wrote:
> On Friday April 3 2015 18:48, in comp.lang.c, "jacobnavia"
> <jacob@jacob.remcomp.fr> wrote:
>
>> Le 04/04/2015 00:44, Richard Heathfield a écrit :
>>>
>>> So - IF Atoi() is supposed to be a faithful implementation of atoi() -
>>> it should do this too.
>>>
>>> If, on the other hand, the coincidence in names is merely a coincidence
>>> of no consequence, then of course Atoi() can do what it likes. :-)
>>>
>>
>> I think it would be better if we would call that first quick and dirty
>> implementation
>>
>> AsciiToInteger
>>
>> to avoid confusions...
>
> Would this function expect to accept Unicode text?

I doubt it very much. Otherwise, he would have called it 
UnicodeToInteger(). And it takes char * (which should probably be const 
char *), not wchar_t, so it's pretty clear that he did not intend for it 
to provide Unicode support.

It's meant to be an entree to the world of converting numeric 
representations into numbers, the simplest possible example, not an 
all-things-to-all-people bells and whistles job.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#59585

On Friday April 3 2015 19:37, in comp.lang.c, "Richard Heathfield"
<rjh@cpax.org.uk> wrote:

> On 04/04/15 00:31, Lew Pitcher wrote:
>> On Friday April 3 2015 18:48, in comp.lang.c, "jacobnavia"
>> <jacob@jacob.remcomp.fr> wrote:
>>
>>> Le 04/04/2015 00:44, Richard Heathfield a écrit :
>>>>
>>>> So - IF Atoi() is supposed to be a faithful implementation of atoi() -
>>>> it should do this too.
>>>>
>>>> If, on the other hand, the coincidence in names is merely a coincidence
>>>> of no consequence, then of course Atoi() can do what it likes. :-)
>>>>
>>>
>>> I think it would be better if we would call that first quick and dirty
>>> implementation
>>>
>>> AsciiToInteger
>>>
>>> to avoid confusions...
>>
>> Would this function expect to accept Unicode text?
> 
> I doubt it very much. Otherwise, he would have called it
> UnicodeToInteger(). 

I ask because, if I understand correctly, on the Microsoft Windows platform
that Jacob's compiler targets, Unicode is the norm. If Jacob intends to
restrict the AsciiToInteger() input to ASCII, then he may have further
editing requirements that would cause the function to return error values
(or incorrect values, if he intends no editing/error reporting). 


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

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

#59586

On 04/04/15 15:29, Lew Pitcher wrote:
> On Friday April 3 2015 19:37, in comp.lang.c, "Richard Heathfield"
> <rjh@cpax.org.uk> wrote:
>
>> On 04/04/15 00:31, Lew Pitcher wrote:
>>> On Friday April 3 2015 18:48, in comp.lang.c, "jacobnavia"
>>> <jacob@jacob.remcomp.fr> wrote:
<snip>
>>>>
>>>> I think it would be better if we would call that first quick and dirty
>>>> implementation
>>>>
>>>> AsciiToInteger
>>>>
>>>> to avoid confusions...
>>>
>>> Would this function expect to accept Unicode text?
>>
>> I doubt it very much. Otherwise, he would have called it
>> UnicodeToInteger().
>
> I ask because, if I understand correctly, on the Microsoft Windows platform
> that Jacob's compiler targets, Unicode is the norm.


Lew, I'm guessing that you haven't been following this discussion from 
the beginning. This function's purpose is purely exegetic - it's a paper 
function, if you like.

When one is writing a tutorial or an explanatory document, one strips 
away the fluff and concentrates on the essentials. In this case, Unicode 
would be fluff. Digits, on the other hand, are essential.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#59587

On Saturday, April 4, 2015 at 3:29:55 PM UTC+1, Lew Pitcher wrote:
> 
> I ask because, if I understand correctly, on the Microsoft Windows 
> platform that Jacob's compiler targets, Unicode is the norm. If 
> Jacob intends to restrict the AsciiToInteger() input to ASCII, then 
> he may have further editing requirements that would cause the function 
> to return error values (or incorrect values, if he intends no
> editing/error reporting)
>
Windows uses 16-bit character interfaces to OS calls, but retains 8-
bit characters for backwards compatibility. That was a design mistake,
though a forgiveable one, because the interface was specified very
early in the history of Unicode. It's become more and more obvious
that UTF-8 is the encoding to use. All my Windows programs use
UTF-8 internally, and just convert to 16 bit at the last moment, to
actually make system call or concert from it.

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

#59588

On 04/04/2015 16:07, Malcolm McLean wrote:
> On Saturday, April 4, 2015 at 3:29:55 PM UTC+1, Lew Pitcher wrote:
>>
>> I ask because, if I understand correctly, on the Microsoft Windows
>> platform that Jacob's compiler targets, Unicode is the norm. If
>> Jacob intends to restrict the AsciiToInteger() input to ASCII, then
>> he may have further editing requirements that would cause the function
>> to return error values (or incorrect values, if he intends no
>> editing/error reporting)
>>
> Windows uses 16-bit character interfaces to OS calls, but retains 8-
> bit characters for backwards compatibility. That was a design mistake,
> though a forgiveable one, because the interface was specified very
> early in the history of Unicode. It's become more and more obvious
> that UTF-8 is the encoding to use. All my Windows programs use
> UTF-8 internally, and just convert to 16 bit at the last moment, to
> actually make system call or concert from it.

IMO you've got that back to front. You ought to use 16-bit or 32-bit 
characters internally, and UTF-8 for storage and transmission.

That allows you to do random access on strings in memory, or just to 
make many things straightforward (liking working out the length of a 
string).

-- 
Bartc

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

#59589

On Saturday, April 4, 2015 at 4:28:36 PM UTC+1, Bart wrote:
> On 04/04/2015 16:07, Malcolm McLean wrote:
>
> IMO you've got that back to front. You ought to use 16-bit or 32-bit 
> characters internally, and UTF-8 for storage and transmission.
> 
> That allows you to do random access on strings in memory, or just to 
> make many things straightforward (liking working out the length of a 
> string).
> 
But mostly code which is UTF-8 naive will still work. Not if it's
actually breaking up the string into characters. But if we're
parsing a string in the format  Surname, Firstname, PE4567943, £2016.41
then we can move from ascii to unicode names to accommodate 
foreigners, and the parser should still work.

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

#59590

On 04/04/2015 16:57, Malcolm McLean wrote:
> On Saturday, April 4, 2015 at 4:28:36 PM UTC+1, Bart wrote:
>> On 04/04/2015 16:07, Malcolm McLean wrote:
>>
>> IMO you've got that back to front. You ought to use 16-bit or 32-bit
>> characters internally, and UTF-8 for storage and transmission.
>>
>> That allows you to do random access on strings in memory, or just to
>> make many things straightforward (liking working out the length of a
>> string).
>>
> But mostly code which is UTF-8 naive will still work. Not if it's
> actually breaking up the string into characters. But if we're
> parsing a string in the format  Surname, Firstname, PE4567943, £2016.41
> then we can move from ascii to unicode names to accommodate
> foreigners, and the parser should still work.

Yes, if you don't do any actual processing then you might get away with it.

But suppose you have a 20-byte zero-terminated field for Firstname. With 
ASCII or ANSI, you will know the longest Firstname that can be 
accommodated is 19 characters. What will it be in UTF-8?

-- 
Bartc

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web