Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #58570 > unrolled thread
| Started by | jacob navia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2015-03-21 12:09 +0100 |
| Last post | 2015-03-29 11:30 +1300 |
| Articles | 16 on this page of 96 — 20 participants |
Back to article view | Back to comp.lang.c
Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-21 12:09 +0100
Re: Code for strtol/strtoul Bartc <bc@freeuk.com> - 2015-03-21 11:33 +0000
Re: Code for strtol/strtoul Bartc <bc@freeuk.com> - 2015-03-21 11:47 +0000
Re: Code for strtol/strtoul Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-21 15:58 +0000
Re: Code for strtol/strtoul Lőrinczy Zsigmond <nospam@for.me> - 2015-03-21 16:10 +0100
Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-21 16:34 +0100
Re: Code for strtol/strtoul Kaz Kylheku <kaz@kylheku.com> - 2015-03-21 16:10 +0000
Re: Code for strtol/strtoul James Kuyper <jameskuyper@verizon.net> - 2015-03-21 12:53 -0400
Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-21 14:18 -0700
Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-21 22:46 +0100
Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-21 15:23 -0700
Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-21 23:42 +0100
Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-21 16:06 -0700
Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 00:29 +0100
Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-21 20:18 -0700
Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-21 15:54 -0700
Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 08:34 +0100
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 19:42 -0700
Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-25 10:40 -0700
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:17 -0700
Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-25 20:27 -0700
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 09:08 -0700
Re: Code for strtol/strtoul Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-21 15:53 +0000
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 21:50 -0700
Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-25 06:54 +0100
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-25 19:18 +1300
Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-25 09:57 +0100
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-26 07:07 +1300
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-26 14:22 +1300
Re: Code for strtol/strtoul asetofsymbols@gmail.com - 2015-03-26 00:17 -0700
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-28 12:07 +1300
Re: Code for strtol/strtoul asetofsymbols@gmail.com - 2015-03-28 02:53 -0700
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 08:19 -0700
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 16:13 -0700
Re: Code for strtol/strtoul Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-25 13:42 +0000
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 17:20 -0700
Re: Code for strtol/strtoul Kaz Kylheku <kaz@kylheku.com> - 2015-03-26 04:16 +0000
Re: Code for strtol/strtoul asetofsymbols@gmail.com - 2015-03-26 00:27 -0700
Re: Code for strtol/strtoul Kaz Kylheku <kaz@kylheku.com> - 2015-03-26 13:44 +0000
Re: Code for strtol/strtoul fir <profesor.fir@gmail.com> - 2015-03-26 07:13 -0700
Re: Code for strtol/strtoul asetofsymbols@gmail.com - 2015-03-26 08:30 -0700
Re: Code for strtol/strtoul raltbos@xs4all.nl (Richard Bos) - 2015-03-29 15:13 +0000
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 09:47 -0700
Re: Code for strtol/strtoul Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-26 15:00 +0000
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-27 07:12 +1300
Re: Code for strtol/strtoul Bartc <bc@freeuk.com> - 2015-03-26 19:11 +0000
Re: Code for strtol/strtoul Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-26 15:09 -0700
Re: Code for strtol/strtoul Richard Heathfield <rjh@cpax.org.uk> - 2015-03-26 22:13 +0000
Re: Code for strtol/strtoul Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-26 15:20 -0700
Re: Code for strtol/strtoul raltbos@xs4all.nl (Richard Bos) - 2015-03-30 09:59 +0000
Re: Code for strtol/strtoul Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-30 06:38 -0700
Re: Code for strtol/strtoul Richard Heathfield <rjh@cpax.org.uk> - 2015-03-30 14:41 +0100
Re: Code for strtol/strtoul raltbos@xs4all.nl (Richard Bos) - 2015-04-06 12:52 +0000
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-27 18:07 +1300
Re: Code for strtol/strtoul raltbos@xs4all.nl (Richard Bos) - 2015-03-29 15:17 +0000
Re: Code for strtol/strtoul Kaz Kylheku <kaz@kylheku.com> - 2015-03-29 15:26 +0000
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-30 07:09 +1300
Re: Code for strtol/strtoul raltbos@xs4all.nl (Richard Bos) - 2015-03-30 10:02 +0000
Re: Code for strtol/strtoul Bartc <bc@freeuk.com> - 2015-03-29 18:53 +0100
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 15:38 -0700
Re: Code for strtol/strtoul Robert Wessel <robertwessel2@yahoo.com> - 2015-03-21 16:48 -0500
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-22 20:45 +1300
Re: Code for strtol/strtoul Ike Naar <ike@iceland.freeshell.org> - 2015-03-23 09:40 +0000
Re: Code for strtol/strtoul Richard Heathfield <rjh@cpax.org.uk> - 2015-03-23 09:46 +0000
Re: Code for strtol/strtoul Reinhardt Behm <rbehm@hushmail.com> - 2015-03-23 18:44 +0800
Re: Code for strtol/strtoul Les Cargill <lcargill99@comcast.com> - 2015-03-23 20:29 -0500
Re: Code for strtol/strtoul Richard Heathfield <rjh@cpax.org.uk> - 2015-03-24 08:12 +0000
Re: Code for strtol/strtoul Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 05:27 -0500
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-24 07:03 +1300
Re: Code for strtol/strtoul Ike Naar <ike@iceland.freeshell.org> - 2015-03-23 22:40 +0000
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-24 17:17 +1300
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 21:42 -0700
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-25 17:55 +1300
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 08:43 -0700
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-26 14:15 +1300
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 14:53 -0700
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-29 11:04 +1300
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 12:34 -0700
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-31 21:20 +1300
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 22:31 -0700
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-25 19:30 +1300
Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 08:24 -0700
Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-25 22:43 +0100
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-27 19:18 +1300
Re: Code for strtol/strtoul Steve Thompson <stevet810@gmail.com> - 2015-03-27 15:02 +0000
Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-27 16:10 +0100
Re: Code for strtol/strtoul Steve Thompson <stevet810@gmail.com> - 2015-03-27 22:44 +0000
Re: Code for strtol/strtoul raltbos@xs4all.nl (Richard Bos) - 2015-03-29 15:18 +0000
Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-29 17:35 +0200
Re: Code for strtol/strtoul Robert Wessel <robertwessel2@yahoo.com> - 2015-03-28 03:57 -0500
Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-28 14:09 +0100
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-28 22:58 +1300
Re: Code for strtol/strtoul Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-28 11:33 +0000
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-29 08:49 +1300
Re: Code for strtol/strtoul Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-28 22:11 +0000
Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-29 11:30 +1300
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-25 19:30 +1300 |
| Message-ID | <cnf30hFlek5U3@mid.individual.net> |
| In reply to | #58894 |
Tim Rentsch wrote: > jacob navia <jacob@jacob.remcomp.fr> writes: > >> After some days working in those functions, I would like to share >> this work with you [snip], because there some interesting issues >> in this code. > > An outstanding programming exercise. Implementing strtoul() > and friends is not nearly as easy as it might seem. > >> What to do with bad inputs? [eg, NULL] > > An easy question, but not necessarily an easy answer. In cases > where there is undefined behavior, you might abort, or return a > special value (with an errno setting), or have an option for > choosing one or the other (eg, by setting an environment variable). > The main thing is to do _something_ reliably whenver that is > possible. This aspect is under specified. POSIX goes part way (setting errno to EINVAL if base is invalid, but no mention of what to return). I chose returning 0 and setting errno to EINVAL for both a null string and a bad base. >> What to do with weird cases? For instance the sequence >> >> strtol( >> "56724399879677657653445435435456765675755435435432223444465444565466654666ULL", >> &endptr,10); > > AFAIK the behavior in this case is completely specified (namely, > the return value is LONG_MAX, 'endptr' is set to point to the 'U' > character, and errno is set to ERANGE). Do you have a different > reading? That is the case. >> I developed a formula for calculating the maximum number of digits to >> read for a number base N. Is that formula correct? > > I didn't look at the formula closely because I think it's > easier and better to code around it. It's possible a > conservative estimate might give a performance gain in > some common cases, but an exact formula (with floating > point and everything) just seems like more trouble than > help. If you look at my implementation, you will see I chose to check for overflow during the conversion. This may be an inefficiency when converting to 32 bit longs. > Minor remark - the implicit reliance on how the type conversion > works in strtol() deserves at least a comment. Even better would > be to write the code so it is implementation-independent, or at > least more independent of implementation than it is now. I strove to do this, if you see any portability issues, I'd like to know. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-25 08:24 -0700 |
| Message-ID | <kfnoanhcd7c.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #58899 |
Ian Collins <ian-news@hotmail.com> writes: > Tim Rentsch wrote: >> jacob navia <jacob@jacob.remcomp.fr> writes: >> >>> After some days working in those functions, I would like to share >>> this work with you [snip], because there some interesting issues >>> in this code. >> >> An outstanding programming exercise. Implementing strtoul() >> and friends is not nearly as easy as it might seem. >> >>> What to do with bad inputs? [eg, NULL] >> >> An easy question, but not necessarily an easy answer. In cases >> where there is undefined behavior, you might abort, or return a >> special value (with an errno setting), or have an option for >> choosing one or the other (eg, by setting an environment variable). >> The main thing is to do _something_ reliably whenver that is >> possible. > > This aspect is under specified. POSIX goes part way (setting > errno to EINVAL if base is invalid, but no mention of what to > return). I chose returning 0 and setting errno to EINVAL for both > a null string and a bad base. That is good to know, thanks. >>> I developed a formula for calculating the maximum number of digits >>> to read for a number base N. Is that formula correct? >> >> I didn't look at the formula closely because I think it's >> easier and better to code around it. It's possible a >> conservative estimate might give a performance gain in >> some common cases, but an exact formula (with floating >> point and everything) just seems like more trouble than >> help. > > If you look at my implementation, [snip] I am deliberately not looking until after I have written my own version. I will try to remember to look afterwards. >> Minor remark - the implicit reliance on how the type conversion >> works in strtol() deserves at least a comment. Even better would >> be to write the code so it is implementation-independent, or at >> least more independent of implementation than it is now. > > I strove to do this, if you see any portability issues, I'd like > to know. Ditto my last remark.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-03-25 22:43 +0100 |
| Message-ID | <meva6j$rc3$1@speranza.aioe.org> |
| In reply to | #58570 |
Th code posted doesn't handle the case: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005 Since I have a max length, I missed this case. I have fixed it, will post the fix later
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-27 19:18 +1300 |
| Message-ID | <cnkb13F1tlmU2@mid.individual.net> |
| In reply to | #58969 |
jacob navia wrote: > Th code posted doesn't handle the case: > > 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005 > > Since I have a max length, I missed this case. I have fixed it, will > post the fix later How about the LP64 issues? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-03-27 15:02 +0000 |
| Message-ID | <j3RGDi.zPs.4TK2E@gmail.com> |
| In reply to | #58969 |
On Wed, Mar 25, 2015 at 10:43:49PM +0100, jacob navia wrote: > Th code posted doesn't handle the case: > > 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005 > > Since I have a max length, I missed this case. I have fixed it, will > post the fix later I'm surprised no-one has suggested that he use a textual number representation that has some sort simple RLL compression. That also makes it much more efficient to do strlen() on average because the char array will often be so much shorter if numbers like the above are at all common in the program input. Regards, Steve Thompson -- "If I had a nickel for every time some idiot called me about a computer problem that turned out to be user error, I would be able to retire and spend the rest of my days cultivating clues in my backyard hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-03-27 16:10 +0100 |
| Message-ID | <mf3rtq$985$1@speranza.aioe.org> |
| In reply to | #59086 |
Le 27/03/2015 16:02, Steve Thompson a écrit : > On Wed, Mar 25, 2015 at 10:43:49PM +0100, jacob navia wrote: >> Th code posted doesn't handle the case: >> >> 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005 >> >> Since I have a max length, I missed this case. I have fixed it, will >> post the fix later > > I'm surprised no-one has suggested that he use a textual number > representation that has some sort simple RLL compression. That also > makes it much more efficient to do strlen() on average because the > char array will often be so much shorter if numbers like the above are > at all common in the program input. > > > > Regards, > > Steve Thompson > Hi Steve The input of strtol is fixed: it is a char *. I can't change that. I receive a sequence of digits, and I should output a number.
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-03-27 22:44 +0000 |
| Message-ID | <sJpGGh.iy8.risqm@gmail.com> |
| In reply to | #59087 |
On Fri, Mar 27, 2015 at 04:10:51PM +0100, jacob navia wrote: > Le 27/03/2015 16:02, Steve Thompson a écrit : > >On Wed, Mar 25, 2015 at 10:43:49PM +0100, jacob navia wrote: > >>Th code posted doesn't handle the case: > >> > >>0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005 > >> > >>Since I have a max length, I missed this case. I have fixed it, will > >>post the fix later > > > >I'm surprised no-one has suggested that he use a textual number > >representation that has some sort simple RLL compression. That also > >makes it much more efficient to do strlen() on average because the > >char array will often be so much shorter if numbers like the above are > >at all common in the program input. > > Hi Steve > > The input of strtol is fixed: it is a char *. I can't change that. > I receive a sequence of digits, and I should output a number. My mistake. It should surprise no-one that handling pathological input cases is no picnic. I can't count the number of times I've had to fix an input routine because I forgot to handle some corner case or the other. There's a lot of talk about "undefined behaviour" in non- conforming C but "unexpected behaviour" ought to get honorable mention even if it does not fully depend on non-conformance. Regards, Steve Thompson -- "If I had a nickel for every time some idiot called me about a computer problem that turned out to be user error, I would be able to retire and spend the rest of my days cultivating clues in my backyard hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-03-29 15:18 +0000 |
| Message-ID | <551817c6.21116890@news.xs4all.nl> |
| In reply to | #59087 |
jacob navia <jacob@jacob.remcomp.fr> wrote: > Le 27/03/2015 16:02, Steve Thompson a écrit : > > On Wed, Mar 25, 2015 at 10:43:49PM +0100, jacob navia wrote: > >> Th code posted doesn't handle the case: > >> > >> 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005 > >> > >> Since I have a max length, I missed this case. I have fixed it, will > >> post the fix later > > > > I'm surprised no-one has suggested that he use a textual number > > representation that has some sort simple RLL compression. That also > > makes it much more efficient to do strlen() on average because the > > char array will often be so much shorter if numbers like the above are > > at all common in the program input. > > > > > > > > Regards, > > > > Steve Thompson > > > > Hi Steve > > The input of strtol is fixed: it is a char *. I can't change that. > I receive a sequence of digits, and I should output a number. > Yet another fake post? Sounds like it. Richard
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-03-29 17:35 +0200 |
| Message-ID | <mf964c$7oq$2@speranza.aioe.org> |
| In reply to | #59210 |
Le 29/03/2015 17:18, Richard Bos a écrit : > jacob navia <jacob@jacob.remcomp.fr> wrote: > >> Le 27/03/2015 16:02, Steve Thompson a écrit : >>> On Wed, Mar 25, 2015 at 10:43:49PM +0100, jacob navia wrote: >>>> Th code posted doesn't handle the case: >>>> >>>> 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005 >>>> >>>> Since I have a max length, I missed this case. I have fixed it, will >>>> post the fix later >>> >>> I'm surprised no-one has suggested that he use a textual number >>> representation that has some sort simple RLL compression. That also >>> makes it much more efficient to do strlen() on average because the >>> char array will often be so much shorter if numbers like the above are >>> at all common in the program input. >>> >>> >>> >>> Regards, >>> >>> Steve Thompson >>> >> >> Hi Steve >> >> The input of strtol is fixed: it is a char *. I can't change that. >> I receive a sequence of digits, and I should output a number. >> > > Yet another fake post? Sounds like it. > > Richard > Please Richard, do not force it ok? It is not fake at all, the input of strtol *IS* fixed by the standard.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-03-28 03:57 -0500 |
| Message-ID | <j7rcha1h2pdpkrdg8tid9obqg5c60rffpl@4ax.com> |
| In reply to | #58969 |
On Wed, 25 Mar 2015 22:43:49 +0100, jacob navia <jacob@jacob.remcomp.fr> wrote: >Th code posted doesn't handle the case: > >0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005 > >Since I have a max length, I missed this case. I have fixed it, will >post the fix later I did mention that, and some possible fixes a week ago...
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-03-28 14:09 +0100 |
| Message-ID | <mf6971$k6p$1@speranza.aioe.org> |
| In reply to | #59115 |
Le 28/03/2015 09:57, Robert Wessel a écrit : > On Wed, 25 Mar 2015 22:43:49 +0100, jacob navia > <jacob@jacob.remcomp.fr> wrote: > >> Th code posted doesn't handle the case: >> >> 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005 >> >> Since I have a max length, I missed this case. I have fixed it, will >> post the fix later > > > I did mention that, and some possible fixes a week ago... > Yes, I have incorporated them into the 64 + 32 bit version. That version tests for overflow at each step, as you proposed, and eliminates the MaxChars construct. It is almost finished but I wanted to do more tests before I repost. Thanks for your input.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-28 22:58 +1300 |
| Message-ID | <cnncb9Foba2U1@mid.individual.net> |
| In reply to | #58570 |
jacob navia wrote: > What to do with weird cases? For instance the sequence > > strtol( > "56724399879677657653445435435456765675755435435432223444465444565466654666ULL", > &endptr,10); > > I developed a formula for calculating the maximum number of digits to > read for a number base N. Is that formula correct? That calculation appears to be impacting the performance of your routine. Being a another quiet weekend, I got bored and wrote a test wrapper that creates an array of 1000 random number strings and then cycles them 10000 times to perform enough conversions for a decent elapsed time. Compiled with gcc -O3, your version takes ~9.9 seconds, my version ~6.4 seconds. Considering the only significant difference is I don't bother calculating the maximum number of digits, it probably isn't a good thing to do. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-03-28 11:33 +0000 |
| Message-ID | <87ego98igi.fsf@bsb.me.uk> |
| In reply to | #59117 |
Ian Collins <ian-news@hotmail.com> writes: > jacob navia wrote: > >> What to do with weird cases? For instance the sequence >> >> strtol( >> "56724399879677657653445435435456765675755435435432223444465444565466654666ULL", >> &endptr,10); >> >> I developed a formula for calculating the maximum number of digits to >> read for a number base N. Is that formula correct? > > That calculation appears to be impacting the performance of your routine. > > Being a another quiet weekend, I got bored and wrote a test wrapper > that creates an array of 1000 random number strings and then cycles > them 10000 times to perform enough conversions for a decent elapsed > time. > > Compiled with gcc -O3, your version takes ~9.9 seconds, my version > ~6.4 seconds. Considering the only significant difference is I don't > bother calculating the maximum number of digits, it probably isn't a > good thing to do. But at least in your case, the code does not correctly scan the whole string of digits, so that might be another difference depending on how many ling strings your test includes. (I didn't check Jacob's version, and I can't currently find the post, so they may bit the same in this respect.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-29 08:49 +1300 |
| Message-ID | <cnoeueFobieU1@mid.individual.net> |
| In reply to | #59123 |
Ben Bacarisse wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> jacob navia wrote: >> >>> What to do with weird cases? For instance the sequence >>> >>> strtol( >>> "56724399879677657653445435435456765675755435435432223444465444565466654666ULL", >>> &endptr,10); >>> >>> I developed a formula for calculating the maximum number of digits to >>> read for a number base N. Is that formula correct? >> >> That calculation appears to be impacting the performance of your routine. >> >> Being a another quiet weekend, I got bored and wrote a test wrapper >> that creates an array of 1000 random number strings and then cycles >> them 10000 times to perform enough conversions for a decent elapsed >> time. >> >> Compiled with gcc -O3, your version takes ~9.9 seconds, my version >> ~6.4 seconds. Considering the only significant difference is I don't >> bother calculating the maximum number of digits, it probably isn't a >> good thing to do. > > But at least in your case, the code does not correctly scan the whole > string of digits, so that might be another difference depending on how > many ling strings your test includes. In this test, none. Adding ~8% of excessively long strings added about 0.2 seconds to my version. I had corrected the not swallowing all valid digits bug. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-03-28 22:11 +0000 |
| Message-ID | <87r3s87oxo.fsf@bsb.me.uk> |
| In reply to | #59158 |
Ian Collins <ian-news@hotmail.com> writes: > Ben Bacarisse wrote: <snip> >> But at least in your case, the code does not correctly scan the whole >> string of digits, so that might be another difference depending on how >> many [long] strings your test includes. > > In this test, none. Adding ~8% of excessively long strings added > about 0.2 seconds to my version. > > I had corrected the not swallowing all valid digits bug. Ah, I missed that update (and I can't find it, but that may be my bad search skills). I did see a change to the prefix/base calculations but that had it's own problems though. Mind you, that could be me applying the change in the wrong way, but it looked erroneous to me. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-29 11:30 +1300 |
| Message-ID | <cnoobhFoba2U8@mid.individual.net> |
| In reply to | #59177 |
Ben Bacarisse wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> Ben Bacarisse wrote: > <snip> >>> But at least in your case, the code does not correctly scan the whole >>> string of digits, so that might be another difference depending on how >>> many [long] strings your test includes. >> >> In this test, none. Adding ~8% of excessively long strings added >> about 0.2 seconds to my version. >> >> I had corrected the not swallowing all valid digits bug. > > Ah, I missed that update (and I can't find it, but that may be my bad > search skills). I did see a change to the prefix/base calculations but > that had it's own problems though. Mind you, that could be me applying > the change in the wrong way, but it looked erroneous to me. A later change, sorry. I can post the revised version if anyone is interested. -- Ian Collins
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web