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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#59591

On Saturday, April 4, 2015 at 5:04:09 PM UTC+1, Bart wrote:
>
> 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?
> 
We can still detect when the name becomes too long.
What we can't do is provide little blank squares for the user to
overwrite, so he can see how many characters he's allowed. 

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

#59593

On 04/04/15 17:44, Malcolm McLean wrote:
> On Saturday, April 4, 2015 at 5:04:09 PM UTC+1, Bart wrote:
>>
>> 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?
>>
> We can still detect when the name becomes too long.
> What we can't do is provide little blank squares for the user to
> overwrite, so he can see how many characters he's allowed.


Allowed? Are you saying parents have to check with you before naming 
their children? I had no idea.

First names are as long as they are. Computers are supposed to be able 
to cope.

https://xkcd.com/327/  :-)

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

#59609

On Saturday, April 4, 2015 at 6:05:56 PM UTC+1, Richard Heathfield wrote:
> On 04/04/15 17:44, Malcolm McLean wrote:
> > On Saturday, April 4, 2015 at 5:04:09 PM UTC+1, Bart wrote:
> >>
> >> 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?
> >>
> > We can still detect when the name becomes too long.
> > What we can't do is provide little blank squares for the user to
> > overwrite, so he can see how many characters he's allowed.
> 
> 
> Allowed? Are you saying parents have to check with you before naming 
> their children? I had no idea.
> 
> First names are as long as they are. Computers are supposed to be able 
> to cope.
> 
> https://xkcd.com/327/  :-)
> 
Fixed length fields are a hangover from the days when a computer 
couldn't fit a database of, say, a million customers in memory
and keep a running backup of every update.
The popular database packages demand fixed-length string fields so 
that the records can be accessed by index. However you've got to
sanity test name length to prevent denial of service attacks and
other malicious exploits, and you do have issues if a name is too
long to fit on a line of an envelope, for example.
But whilst 19 characters is fine for English names, Hebrew names 
often need vowel marks (especially if they're non-Hebrew names
which have been transliterated into Hebrew). So that means you've
effectively only five letters, which isn't enough.
 

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

#59610

On 05/04/15 07:32, Malcolm McLean wrote:

<snip>

> Fixed length fields are a hangover from the days when a computer
> couldn't fit a database of, say, a million customers in memory
> and keep a running backup of every update.

Hangovers can be cured. :-)

> The popular database packages demand fixed-length string fields so
> that the records can be accessed by index.

If you're indexing on first name, you've already lost the war.

> However you've got to
> sanity test name length to prevent denial of service attacks and
> other malicious exploits,

It isn't difficult to farm out unusually long names to an exception 
report, so that a human decision can be made.

 > and you do have issues if a name is too
> long to fit on a line of an envelope, for example.

Use a smaller font size?

> But whilst 19 characters is fine for English names, Hebrew names
> often need vowel marks (especially if they're non-Hebrew names
> which have been transliterated into Hebrew). So that means you've
> effectively only five letters, which isn't enough.


A search for "longest name" yields rather discouraging results for those 
trying to decide on a sensible upper limit for a fixed length field.

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

#59653

On Sunday, April 5, 2015 at 11:00:53 AM UTC+1, Richard Heathfield wrote:
> On 05/04/15 07:32, Malcolm McLean wrote:
>
> > Fixed length fields are a hangover from the days when a computer
> > couldn't fit a database of, say, a million customers in memory
> > and keep a running backup of every update.
> 
> Hangovers can be cured. :-)
> 
> > The popular database packages demand fixed-length string fields so
> > that the records can be accessed by index.
> 
> If you're indexing on first name, you've already lost the war.
> 
You don't index on first name.
The way it works is that we have a "key", which will probably be the
payroll id. Then you have an index, which means that we can quickly
retrieve a record from a payroll id. The way that works is that
we have a sorted list of payroll ids (or hash table, the details
don't matter). That then gives and index into our record table, on
disk. So we look up the index, move the read head to the right 
position, and read in the record.
But it only works with fixed-width records, at least easily. If we
need a variable-width field then we need a separate file for
each record.

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

#59661

On 4/5/15 4:18 PM, Malcolm McLean wrote:
> On Sunday, April 5, 2015 at 11:00:53 AM UTC+1, Richard Heathfield wrote:
>> On 05/04/15 07:32, Malcolm McLean wrote:
>>
>>> Fixed length fields are a hangover from the days when a computer
>>> couldn't fit a database of, say, a million customers in memory
>>> and keep a running backup of every update.
>>
>> Hangovers can be cured. :-)
>>
>>> The popular database packages demand fixed-length string fields so
>>> that the records can be accessed by index.
>>
>> If you're indexing on first name, you've already lost the war.
>>
> You don't index on first name.
> The way it works is that we have a "key", which will probably be the
> payroll id. Then you have an index, which means that we can quickly
> retrieve a record from a payroll id. The way that works is that
> we have a sorted list of payroll ids (or hash table, the details
> don't matter). That then gives and index into our record table, on
> disk. So we look up the index, move the read head to the right
> position, and read in the record.
> But it only works with fixed-width records, at least easily. If we
> need a variable-width field then we need a separate file for
> each record.
>

You don't need a separate file for each record to handle variable-width 
field data. You can make the "main" record fixed length (for easy 
indexing into) and have it contain a pointer (or pointers) into another 
file that handles variable length information (sort of like a heap). You 
need to be able to handle the eventual fragmentation and reclaiming free 
space. This is easier to do than for the C heap, as every item only has 
a single pointer to it (and you can even include a back pointer to it in 
the data).

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

#59665

On Sunday, April 5, 2015 at 10:37:27 PM UTC+1, Richard Damon wrote:
> On 4/5/15 4:18 PM, Malcolm McLean wrote:
> 
> You don't need a separate file for each record to handle variable-width 
> field data. You can make the "main" record fixed length (for easy 
> indexing into) and have it contain a pointer (or pointers) into another 
> file that handles variable length information (sort of like a heap). You 
> need to be able to handle the eventual fragmentation and reclaiming free 
> space. This is easier to do than for the C heap, as every item only has 
> a single pointer to it (and you can even include a back pointer to it in 
> the data).
>
Fair enough. That's probably how the popular databases packages do it.
But they discourage variable-width fields. I do very little database
programming so I don't know much about it, but I have of course had
to knock up a few SQL queries in my time.

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

#59672

On Sun, 5 Apr 2015 15:00:50 -0700 (PDT), Malcolm McLean
<malcolm.mclean5@btinternet.com> wrote:

>On Sunday, April 5, 2015 at 10:37:27 PM UTC+1, Richard Damon wrote:
>> On 4/5/15 4:18 PM, Malcolm McLean wrote:
>> 
>> You don't need a separate file for each record to handle variable-width 
>> field data. You can make the "main" record fixed length (for easy 
>> indexing into) and have it contain a pointer (or pointers) into another 
>> file that handles variable length information (sort of like a heap). You 
>> need to be able to handle the eventual fragmentation and reclaiming free 
>> space. This is easier to do than for the C heap, as every item only has 
>> a single pointer to it (and you can even include a back pointer to it in 
>> the data).
>>
>Fair enough. That's probably how the popular databases packages do it.
>But they discourage variable-width fields. I do very little database
>programming so I don't know much about it, but I have of course had
>to knock up a few SQL queries in my time.


They really don't.  Just define a column as a varchar (or one of the
other variable types) if that's what meets your requirements.

And if you do specify a fixed width string field, many databases will
compress the entry automatically before storing it.

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

#59601

On 4/4/15 11:28 AM, Bartc wrote:
> 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).
>

A things are now, I would not suggest 16 bit characters except in code 
that is stuck due to too early of an adoption of Unicode (which is the 
case of the Windows API). UTF-16 has all the problems of UTF-8 in being 
variable length (just that the conditions where it breaks are rare 
enough they may well pass through testing and only break in the field), 
and generally takes more space than UTF-8 (the possible exception is 
text which is predominately "Far-East" [pictographic] where the codes 
are high enough to become 3 bytes in UTF-8).

Which of UTF-8 or UCS-4 to use depends a lot on what the program is 
doing. It turns out that a lot of processing will "just work" with UTF-8 
with just a few basic rules. If the code does a lot of arbitrary 
indexing into the data, a lot of "next/previous character" operations or 
needing to know how many codepoints are in a string can benefit with 
32-bit/UCS-4 internals. Note that even using UCS-4 you don't get 1 
character unit = 1 character on the display mapping due to non-printing 
code points and combining characters which use multiple code points to 
describe a single displayed glyph.

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

#59611

On 04/04/2015 23:54, Richard Damon wrote:
> On 4/4/15 11:28 AM, Bartc 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).
>>
>
> A things are now, I would not suggest 16 bit characters except in code
> that is stuck due to too early of an adoption of Unicode (which is the
> case of the Windows API).

If you want to use wchar_t to represent such strings, then under Windows 
that will be 16-bits. I'm not sure you can do much about that.

> UTF-16 has all the problems of UTF-8 in being
> variable length (just that the conditions where it breaks are rare
> enough they may well pass through testing and only break in the field),

But then you go on to say that a 32-bit encoding won't cover all the 
possibilities anyway, so why bother? UTF-16 will deal with all the 
characters that the 8-bit ANSI encoding was used for, with the bonus of 
thousands of extra characters.

> Which of UTF-8 or UCS-4 to use depends a lot on what the program is
> doing. It turns out that a lot of processing will "just work" with UTF-8
> with just a few basic rules. If the code does a lot of arbitrary
> indexing into the data, a lot of "next/previous character" operations or
> needing to know how many codepoints are in a string can benefit with
> 32-bit/UCS-4 internals.

If you're working on a library then you don't know how what the user 
will use the library for.

And if, for example, using C to to implementing some other language as 
is often done, you might want to provide a solid, indexable string type 
in that language without the user needing to be aware of all these 
issues; it should just work as expected, with random indexing, instant 
lengths, sub-strings and slicing all taking advantage of the constant 
char width.

> Note that even using UCS-4 you don't get 1
> character unit = 1 character on the display mapping due to non-printing
> code points and combining characters which use multiple code points to
> describe a single displayed glyph.

Here this is starting to deal with type-setting; you don't want to deal 
with such details in the language.

-- 
Bartc

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

#59571

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Friday April 3 2015 18:48, in comp.lang.c, "jacobnavia"

(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? 
> 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.)

And we should also have an EbcdicToInteger function ...

-- glen

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

#59572

jacobnavia <jacob@jacob.remcomp.fr> writes:
> 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...

I suggest StringToInteger.  You and 99+% of your readers use an
ASCII-based character set, but there's no real need to make that
assumption.

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

#59827

On 04/03/2015 06:48 PM, jacobnavia wrote:
...
> I think it would be better if we would call that first quick and dirty 
> implementation
> 
> AsciiToInteger
> 
> to avoid confusions...

If it's meant to be specific to ASCII, then you should use the correct
ASCII numeric encodings of the characters (for instance, 65 instead of
'A'), so that it will perform a correct ASCII conversion even if
compiled on platform where 'A' != 65.

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

#59832

Le 08/04/2015 17:23, James Kuyper a écrit :
> On 04/03/2015 06:48 PM, jacobnavia wrote:
> ...
>> I think it would be better if we would call that first quick and dirty
>> implementation
>>
>> AsciiToInteger
>>
>> to avoid confusions...
>
> If it's meant to be specific to ASCII, then you should use the correct
> ASCII numeric encodings of the characters (for instance, 65 instead of
> 'A'), so that it will perform a correct ASCII conversion even if
> compiled on platform where 'A' != 65.
>

Sigh...
I renamed the function to "TextToInteger".  I sincerely hope that will 
be a consensual name!
:-)

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

#59833

James Kuyper <jameskuyper@verizon.net> writes:
> On 04/03/2015 06:48 PM, jacobnavia wrote:
> ...
>> I think it would be better if we would call that first quick and dirty 
>> implementation
>> 
>> AsciiToInteger
>> 
>> to avoid confusions...
>
> If it's meant to be specific to ASCII, then you should use the correct
> ASCII numeric encodings of the characters (for instance, 65 instead of
> 'A'), so that it will perform a correct ASCII conversion even if
> compiled on platform where 'A' != 65.

For a quick and dirty implementation, the point of which is to show how
it can be *improved* (particularly by adding error checking), I'd say
implicitly assuming that 'A' == 65 isn't much of a problem.  But it's
not the way I'd do it.  In this case, there's simply no need to assume
ASCII.  Just call it something like StringToInteger.  It will work even
on an EBCDIC-based system operating on EBCDIC data.  There's no point
in putting "Ascii" (or, better, "ASCII") into the name.

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

#59838

On 04/08/2015 01:47 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 04/03/2015 06:48 PM, jacobnavia wrote:
>> ...
>>> I think it would be better if we would call that first quick and dirty 
>>> implementation
>>>
>>> AsciiToInteger
>>>
>>> to avoid confusions...
>>
>> If it's meant to be specific to ASCII, then you should use the correct
>> ASCII numeric encodings of the characters (for instance, 65 instead of
>> 'A'), so that it will perform a correct ASCII conversion even if
>> compiled on platform where 'A' != 65.
> 
> For a quick and dirty implementation, the point of which is to show how
> it can be *improved* (particularly by adding error checking), I'd say
> implicitly assuming that 'A' == 65 isn't much of a problem.  But it's
> not the way I'd do it.  In this case, there's simply no need to assume
> ASCII.  Just call it something like StringToInteger.  It will work even
> on an EBCDIC-based system operating on EBCDIC data.  There's no point
> in putting "Ascii" ...

Yes, that's really the point I was trying to make, but I worded it a way
that gave it a different emphasis.

> ... (or, better, "ASCII") into the name.

Also a good point.

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

#59583 — lltostr/ulltostr

The strtoXXX function was missing the reverse function

int lltostr(long long number,
             char *outStr,size_t bufsiz, int base);

int ulltostr(unsigned long long number,
             char *outStr,size_t bufsiz, int base);

These functions will convert any long long number into a string using 
the given buffer and base but without exceeding bufsiz. The bufsiz 
parameter includes the terminating zero.

They return the number of characters written or -1 if the buffer would 
overflow. The output buffer is always zero terminated.

----------------------------------------------------------cut here
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

int lltostr(long long number,char *outStr,
              size_t strSize, int base)
{
     char *p = outStr;
     unsigned long long m;

     if (strSize < 2 || outStr == NULL || base < 2
             || base > 36)
         return 0;
     if (number<0) {
         *p++ = '-';
         strSize--;
         number = -number;
     }
     else if (number == 0) {
         *p++ = '0';
         *p = 0;
         return 1;
     }
     while (number) {
         lldiv_t  d = lldiv(number,base);
         m = d.rem;
         if (m < 10)
             *p++ = '0'+m;
         else *p++ = 'a'+m-10;
         number = d.quot;
         strSize--;
         if (strSize < 2 && number != 0)
             break;
     }
     *p=0;
     strrev(outStr + (*outStr=='-'));
     return 1;
}
int ulltostr(unsigned long long number,
              char *outStr,size_t strSize, int base)
{
     char *p = outStr;
     unsigned long long m;

     if (strSize < 2 || outStr == NULL || base < 2
             || base > 36)
         return 0;
     if (number == 0) {
         *p++ = '0';
         *p = 0;
         return 1;
     }
     }
     while (number) {
         lldiv_t  d = lldiv(number,base);
         m = d.rem;
         if (m < 10)
             *p++ = '0'+m;
         else *p++ = 'a'+m-10;
         number = d.quot;
         strSize--;
         if (strSize < 2 && number != 0) {
             // Overflow of the given buffer */
             *outStr=0;
             return -1;
         }

     }
     *p=0;
     strrev(outStr);
     return (int)(p-outStr);
}
#ifdef TEST
// process the argv[1] and write results */
#include <stdio.h>
#include <math.h>
#include <string.h>
int main(int argc,char *argv[])
{
     char *end;
     char *s = "-2147483647";
     int save_errno;
     char buf[128];
     int base = 10;
     if (argc > 1) {
         s = argv[1];
         if (argc > 2)
             base = atoi(argv[2]);
     }

     else {
         fprintf(stderr,"Usage: %s <number> [base]\n",argv[0]);
         return EXIT_FAILURE;
     }
     if (argc > 2)
         base = atoi(argv[2]);
     errno = 0;
     unsigned long long m = strtoull(s,&end,0);
     save_errno = errno;
     printf("strtoull(%s):\n         %llu %lld",argv[1],m,end-s);
     printf(" errno = %s\n",strerror(save_errno));
     lltostr(m,buf,sizeof(buf),base);
     printf("lltostr(%s) base %d: %s\n",argv[1],base,buf);
}
#endif

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

#59584 — Re: lltostr/ulltostr

On 04/04/15 12:56, jacobnavia wrote:
> The strtoXXX function was missing the reverse function
>
> int lltostr(long long number,
>               char *outStr,size_t bufsiz, int base);
>
> int ulltostr(unsigned long long number,
>               char *outStr,size_t bufsiz, int base);

Indeed it was.

I have only a couple of comments. Er, three, actually.

The first is about the interface. It is usual, in standard C functions 
that update an object, to list that object first. Consider, for example:

strcpy(t, s);
fgets(s, sizeof s, fp);

This is not universal (putc is an obvious wart), but it is a 
sufficiently strong idiom that it is worth considering.

int lltostr(char *outStr, size_t bufsiz, int base, long long number);

for example ('base' belongs more to the string than it does to the 
number, for reasons I have outlined in previous articles in other threads).

The second comment is about an edge case. I believe that the function 
will silently fail for LLONG_MIN on systems where its magnitude is one 
greater than that of LLONG_MAX.

The third note regards strrev(). This is a non-standard function. It's 
trivial to write, of course, but anyone wishing to test the code will 
need to either write strrev() for themselves or steal one from somewhere.

Here is a non-robust strrev() that should fill the gap for those who 
just want to be able to test Jacob's code:

#include <string.h>
void strrev(char *s)
{
   size_t len = strlen(s);
   if(len > 1) /* "" and "X" don't need reversing */
   {
     char t;
     char *e = s + len - 1;
     while(s < e)
     {
       t = *e;
       *e-- = *s;
       *s++ = t;
     }
   }
}

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

#59606 — Re: lltostr/ulltostr

On Sat, 04 Apr 2015 13:56:52 +0200, jacobnavia
<jacob@jacob.remcomp.fr> wrote:

snip

>They return the number of characters written or -1 if the buffer would 
>overflow. The output buffer is always zero terminated.
>
>----------------------------------------------------------cut here
>#include <stdio.h>
>#include <stdlib.h>
>#include <string.h>
>#include <errno.h>
>
>int lltostr(long long number,char *outStr,
>              size_t strSize, int base)
>{
>     char *p = outStr;
>     unsigned long long m;
>
>     if (strSize < 2 || outStr == NULL || base < 2
>             || base > 36)
>         return 0;

I don't object to the 0 return value but you should either first store
a '\0' in *p or change the spec to indicate the actual conditions the
buffer is zero terminated.

-- 
Remove del for email

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

#59607 — Re: lltostr/ulltostr

Barry Schwarz wrote:
> On Sat, 04 Apr 2015 13:56:52 +0200, jacobnavia
> <jacob@jacob.remcomp.fr> wrote:
>
> snip
>
>> They return the number of characters written or -1 if the buffer would
>> overflow. The output buffer is always zero terminated.
>>
>> ----------------------------------------------------------cut here
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <string.h>
>> #include <errno.h>
>>
>> int lltostr(long long number,char *outStr,
>>               size_t strSize, int base)
>> {
>>      char *p = outStr;
>>      unsigned long long m;
>>
>>      if (strSize < 2 || outStr == NULL || base < 2
>>              || base > 36)
>>          return 0;
>
> I don't object to the 0 return value but you should either first store
> a '\0' in *p or change the spec to indicate the actual conditions the
> buffer is zero terminated.

Not a good idea if outStr == NULL...

-- 
Ian Collins

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

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

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

csiph-web