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

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

code for 32/64 bit strtoul strtol strtoull strtoll

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

Contents

  code for 32/64 bit strtoul strtol strtoull strtoll jacob navia <jacob@jacob.remcomp.fr> - 2015-03-29 17:33 +0200
    code for 32/64 bit strtoul strtol strtoull strtoll asetofsymbols@gmail.com - 2015-03-29 09:22 -0700
      Re: code for 32/64 bit strtoul strtol strtoull strtoll Barry Schwarz <schwarzb@dqel.com> - 2015-03-29 15:12 -0700
        Re: code for 32/64 bit strtoul strtol strtoull strtoll asetofsymbols@gmail.com - 2015-03-29 23:07 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Barry Schwarz <schwarzb@dqel.com> - 2015-03-29 09:44 -0700
      Re: code for 32/64 bit strtoul strtol strtoull strtoll jacob navia <jacob@jacob.remcomp.fr> - 2015-03-29 19:05 +0200
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-29 12:15 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-30 02:01 +0100
      Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-29 19:48 -0700
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Barry Schwarz <schwarzb@dqel.com> - 2015-03-29 22:08 -0700
          Re: code for 32/64 bit strtoul strtol strtoull strtoll Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-30 12:44 +0100
            Re: code for 32/64 bit strtoul strtol strtoull strtoll Barry Schwarz <schwarzb@dqel.com> - 2015-03-30 09:04 -0700
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-30 21:00 +0100
          Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-30 08:24 -0700
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 07:21 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Ian Collins <ian-news@hotmail.com> - 2015-03-30 18:02 +1300
      Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-30 08:03 +0100
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Ian Collins <ian-news@hotmail.com> - 2015-03-30 20:33 +1300
          Re: code for 32/64 bit strtoul strtol strtoull strtoll Ian Collins <ian-news@hotmail.com> - 2015-03-30 20:35 +1300
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 07:27 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-30 09:08 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-30 09:29 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-03-30 15:16 -0500
      Re: code for 32/64 bit strtoul strtol strtoull strtoll jacob navia <jacob@jacob.remcomp.fr> - 2015-03-31 00:15 +0200
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-03-31 01:42 -0500
      Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-30 23:39 +0100
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-03-31 01:44 -0500
          Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-31 13:01 +0100
            Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-31 05:13 -0700
            Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 08:06 -0700
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 08:26 -0700
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 16:40 +0100
                Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-31 09:39 -0700
                Re: code for 32/64 bit strtoul strtol strtoull strtoll Kaz Kylheku <kaz@kylheku.com> - 2015-03-31 18:22 +0000
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 19:36 +0100
                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 12:11 -0700
                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Kaz Kylheku <kaz@kylheku.com> - 2015-03-31 19:23 +0000
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-31 16:52 +0100
                Re: code for 32/64 bit strtoul strtol strtoull strtoll glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-31 17:54 +0000
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll raltbos@xs4all.nl (Richard Bos) - 2015-03-31 18:51 +0000
                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 20:05 +0100
                      Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-03-31 15:18 -0400
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 20:49 +0100
                          Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-31 13:06 -0700
                          Re: code for 32/64 bit strtoul strtol strtoull strtoll raltbos@xs4all.nl (Richard Bos) - 2015-04-06 13:03 +0000
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-04-06 14:27 +0100
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-04-06 17:01 +0100
                              Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-06 11:25 -0700
                              Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-04-06 23:34 -0400
                                Re: code for 32/64 bit strtoul strtol strtoull strtoll glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-07 03:46 +0000
                                  Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-04-08 11:05 -0400
                                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 08:31 -0700
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-31 19:54 +0000
                          Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-03-31 16:55 -0400
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-31 22:20 +0100
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 14:36 -0700
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-31 14:55 -0700
                              Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 17:00 -0700
                                Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-04-01 01:24 +0100
                                Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-03-31 23:33 -0400
                                  Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-04-01 04:42 +0100
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-31 20:26 +0100
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Ian Collins <ian-news@hotmail.com> - 2015-04-01 10:33 +1300
                Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-04-01 04:33 -0500
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-04-01 12:43 +0100
                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-04-02 01:02 -0500
                      Re: code for 32/64 bit strtoul strtol strtoull strtoll asetofsymbols@gmail.com - 2015-04-01 23:57 -0700
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-04-03 00:29 -0500
                      Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-02 09:01 -0700
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-04-02 14:30 -0700
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-04-03 00:39 -0500
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-01 15:55 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#59213 — code for 32/64 bit strtoul strtol strtoull strtoll

Hi

Here is the code for the above functions.

1: A single function will perform all 4 conventions.

2: I have incorporated the suggestions of Mr Wessel and eliminated all 
tables/floating point calculations for getting the maximum number of 
digits.

3: I test for overflow at each stage. For the version presented here I 
stay within C99 and I am not using the _overflow() function of lcc-win 
that returns the value of the overflow flag.

4: I added at the end two small pieces of code to test it with an input 
string that is passed through the argc/argv mechanism, or to test the 
speed of the software passing a number of iterations and a number to 
convert. Two #defines select them: TEST and SPEED respectively. By 
default there are no defines and the software needs a main function to 
get an executable

5: To avoid conflicts with the standard library of the compiler you are 
using I have written all visible function names with upper case "S"

/*------------------------------------------------------------------
  * strtoul() - Conversion of a string of base n to an unsigned long
/*----------------------------------------------------------------*/
#include <ctype.h>
#include <errno.h>
#include <limits.h>
#include <stdlib.h>

#define SIGNED32    1
#define UNSIGNED32  2
#define SIGNED64    4
#define UNSIGNED64  8
#define OVERFLOW_FLAG   -1

static unsigned long long _Strtoull(const char *input,
                      char **endptr, int base, int Flags)
{
     char nbmax; // The maximum numerical digit that can be read
     int tbase = 10; // Default base when base is zero
     int ScanSuffix = 0; // Do we scan any suffixes?
     int ReadSomething=0; // Did we read something in?
     char sign = 0;   // If negative sign is '-'
     char cbmax = 0;  // Max digit that can be read for base > 10
     int digit = 0;  // Digit  read. Reused as overflow flag.
     int c;      // Character just read.
     unsigned long long temp;
     unsigned long long maxval; // Max value that doesn't overflow
     unsigned long long errval; /* Error return */
     unsigned long long value = 0; /* The number we are scanning */

     /* Store input into endptr immediately to save its value
       since we are going to reuse it */
     if (endptr) *endptr = input;

     /* The value of the "base" argument should be zero or
       2 <= base <= 36.  What happens with negative values of "base"
       or with base 1? The standard is silent about that.
       We just do not accept any other values for "base" besides
       those explicitely allowed.  Is it better to crash later
       when dereferencing a NULL pointer? Or to give just an
       error now? */
     if (base < 0 || base == 1 || base > 36 || input == NULL) {
         errno = ERANGE;
         return 0;
     }

     /* C99: 7.20.1.4.2
       First, they decompose the input string into three parts:
     * an initial, possibly empty, sequence of white-space
     * characters  (as specified by the isspace function),
     */
     while (isspace(*input)) { input++; }

     if((*input == '-') || (*input == '+')) {
         sign = *input;
         input++;
     }

     /* C99: 7.20.1.4.5:
     If the subject sequence has the expected form and the value
     of base is zero, the sequence of characters starting with the
     first digit is interpreted as an integer constant according
     to the rules of 6.4.4.1.
     C99: 7.20.1.4.3:
     If the value of base is 16, the characters 0x or 0X may
     optionally precede the sequence of letters and digits,
     following the sign if present.
     */
     if(*input == '0' && (base == 0 || base == 16)) {
         if((input[1] == 'X') || (input[1] == 'x')) {
             tbase = 16;
             input+=2;
         }
         else if (base == 0) {
             tbase = 8;
             /* We have read a zero! We MUST bump "ReadSomething"
               because if not the trivial sequence "0" wouldn't
               be recognized!! Note that "0x" is NOT a valid
               sequence so we haven't read anything UNTIL we
               read a number later
             */
             ReadSomething=1;
             input++;
         }
     }

     /* C99: 7.20.1.4.7:
     If the subject sequence is empty or does not have the
     expected form, no conversion is performed; the value of
     nptr is stored in the object pointed to by endptr,
     provided that endptr is not a null pointer.
     */
     if (*input == 0 && ReadSomething == 0)      return 0;

     /* If we set tbase above put its value into base. We
     must save the fact that if the original base was zero
     we should look for an eventual suffix. Put that
     into the ScanSuffix variable. Obviously ScanSuffix
     could be eliminated and we could set tbase to 4876 say,
     since its value is no longer used. At the end we
     could test if tbase is 4876. That would save 4 bytes
     but make this more unreadable... Not worth */

     if (base == 0) {
         base = tbase;
         ScanSuffix = 1;
     }

     if (base <= 10) {
         nbmax = (char)((char)'0' + (char)(base - 1));
     }
     else {
         nbmax = '9';
         cbmax = (char)((char)'a' + (char)(base - 11));
     }
     /* Set error return / maxval according to the flags given */
     if (Flags&SIGNED64) { /* Returning a signed 64 bit number */
         if(sign == '-') {
             maxval = LLONG_MAX;
             errval = (unsigned long long)LLONG_MIN;
         }
         else maxval = errval = LLONG_MAX;
     }
     else if (Flags&UNSIGNED64) { /* Returning a 64 bit unsigned */
         errval = maxval = ~0ULL;
     }
     else if (Flags &SIGNED32) {
         errval = maxval = LONG_MAX;
     }
     else { /* Must be UNSIGNED32 */
         errval = maxval = ULONG_MAX;
     }
     while (*input == '0') input++; /* Ignore leading zeroes */
     /* Preliminary work is ended. Start converting the number */
     while ( (c=*input) != 0) {
         if((c >= '0') && (c <= nbmax)) {
             digit = c - '0';
         }
         else if ((c >= 'a') && (c <= cbmax)) {
             digit = (c - 'a') + 10;
         }
         else if ( (c >= 'A') && (c <= (char)toupper(cbmax))) {
             digit = (c - 'A') + 10;
         }
         else { /* invalid char. Stop. */
             break;
         }
         temp = (value* (unsigned long)base);
         /* Test for overflow in the multiplication above */
         if (temp < value) {
             digit = OVERFLOW_FLAG;
             break;
         }
         temp += digit;
         // Test for overflow again
         if (temp < value) {
             digit = OVERFLOW_FLAG;
             break;
         }
         value = temp;
         input++;
         ReadSomething++;
     }
     if (c != 0 && digit == OVERFLOW_FLAG) {
         /* Ignore all excess digits */
         while (((*input >= '0') && (*input <= nbmax)) ||
             ((*input >= 'a') && (*input <= cbmax)) ||
             ((*input >= 'A') && (*input <= (char)toupper(cbmax)))) {
             input++;
         }
     }
     if (endptr && ReadSomething && ScanSuffix) {
         /* Accept U,L, UL, ULL suffixes.
           All other suffixes are ignored */
         if (*input == 'u' || *input == 'U') input++;
         if (*input == 'l' || *input == 'L') input ++;
         if ((Flags&(SIGNED64|UNSIGNED64)) &&
               (*input == 'l' || *input == 'L')) input++;
     }
     if (endptr != NULL && ReadSomething > 0) {
         *endptr = input;
     }
     if (value > maxval || digit == OVERFLOW_FLAG) {
         errno = ERANGE;
         value = errval;
     }
     else if (sign ==  '-') {
         if (Flags&(SIGNED32|UNSIGNED32))
             value = -(long long)(value&0xffffffff);
         else
             value = -(long long)value;
     }
     return(value);
}

/*-------------------------------------------------------------*/
/* strtol() - string of base n to an unsigned long integer     */
/*-------------------------------------------------------------*/
unsigned long Strtol(const char *input, char **endptr, int base)
{
     return(_Strtoull(input, endptr, base, SIGNED32));
}

/*------------------------------------------------------------*/
/* strtol() - string of base n to an unsigned long integer    */
/*------------------------------------------------------------*/
long Strtoul(const char *input, char **endptr, int base)
{
     return(_Strtoull(input, endptr, base, UNSIGNED32));
}

/*------------------------------------------------------------*/
/* strtoull() String base n to an unsigned long long r        */
/*------------------------------------------------------------*/
unsigned long long Strtoull(const char *input, char **endptr, int base)
{
     return(_Strtoull(input, endptr, base, UNSIGNED64));
}

/*-----------------------------------------------------------*/
/* strtoll() String of base n to a signed long long          */
/*-----------------------------------------------------------*/
long long Strtoll(const char *input, char **endptr, int base)
{
     return(_Strtoull(input, endptr, base, SIGNED64));
}

#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;
     int base = 0;
     if (argc > 1)
         s = argv[1];
     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));
     errno = 0;
     m = Strtoll(s,&end,0);
     save_errno=errno;
     printf("strtoll(%s):\n        %llu %lld",argv[1],m,end-s);
     printf(" errno = %s\n",strerror(save_errno));
}
#endif
#ifdef SPEED
// argv[1] is number of iterations, argv[2] is value */
#include <stdio.h>
int main(int argc,char *argv[])
{
     int i;
     char *s = "-123456789";
     if (argc > 1)
         i = atoi(argv[1]);
     else {
         fprintf(stderr,"Usage: %s <iterations> <number>\n",argv[0]);
         return EXIT_FAILURE;
     }
     if (argc > 2)
         s = argv[2];
     while (i > 0) {
         Strtoll(s,NULL,10);
         i--;
     }
}
#endif

[toc] | [next] | [standalone]

#59215

So strtoul("-23"...
should be ok? 
Strtoul not means string to
unsigned long?

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

#59238

On Sun, 29 Mar 2015 09:22:01 -0700 (PDT), asetofsymbols@gmail.com
wrote:

>So strtoul("-23"...
>should be ok? 
>Strtoul not means string to
>unsigned long?

Assigning a negative value to an unsigned integer is well defined.

-- 
Remove del for email

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

#59247

Barry Schwarz  wrote:
<<
On Sun, 29 Mar 2015 09:22:01 -0700 (PDT), asetof...@gmail.com 
wrote:

Assigning a negative value to an unsigned integer is well defined
>>
My function that gets unsigned
so would be C language abnormal...
consider that, one error
and not increment a char in 
the pointer to string...
Thanks 
Buon Giorno 

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

#59216

On Sun, 29 Mar 2015 17:33:27 +0200, jacob navia
<jacob@jacob.remcomp.fr> wrote:

>Hi
>
>Here is the code for the above functions.

I snipped the comments and explanations simply for brevity.

>static unsigned long long _Strtoull(const char *input,
>                      char **endptr, int base, int Flags)

Consider the case of input string "0x", endptr not NULL, and base 0.

>{
>     char nbmax; // The maximum numerical digit that can be read
>     int tbase = 10; // Default base when base is zero
>     int ScanSuffix = 0; // Do we scan any suffixes?
>     int ReadSomething=0; // Did we read something in?
>     char sign = 0;   // If negative sign is '-'
>     char cbmax = 0;  // Max digit that can be read for base > 10
>     int digit = 0;  // Digit  read. Reused as overflow flag.
>     int c;      // Character just read.
>     unsigned long long temp;
>     unsigned long long maxval; // Max value that doesn't overflow
>     unsigned long long errval; /* Error return */
>     unsigned long long value = 0; /* The number we are scanning */
>
>     if (endptr) *endptr = input;

input still points to the '0'.

>     if (base < 0 || base == 1 || base > 36 || input == NULL) {
>         errno = ERANGE;
>         return 0;
>     }
>
>     while (isspace(*input)) { input++; }

input still points to the '0'.

>     if((*input == '-') || (*input == '+')) {
>         sign = *input;
>         input++;
>     }

input still points to the '0'.

>     if(*input == '0' && (base == 0 || base == 16)) {
>         if((input[1] == 'X') || (input[1] == 'x')) {
>             tbase = 16;
>             input+=2;
>         }

input now points to the '\0' and ReadSomething is still 0.

>         else if (base == 0) {
>             tbase = 8;
>             ReadSomething=1;
>             input++;
>         }

else not executed.

>     }
>
>     if (*input == 0 && ReadSomething == 0)      return 0;

The if evaluates to true and 0 is correct return value but *endptr
still points to '0' when it should point to 'x'.  Since 0x is not a
valid hex constant, the string "0x" should be treated the same as
"0a".

-- 
Remove del for email

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

#59220

Le 29/03/2015 18:44, Barry Schwarz a écrit :
>
> The if evaluates to true and 0 is correct return value but *endptr
> still points to '0' when it should point to 'x'.  Since 0x is not a
> valid hex constant, the string "0x" should be treated the same as
> "0a".
>

That would be the case if the standard was logical but it is explicitely 
stated that 0x should NOT advance the pointer.

<quote>
C99:
7 If the subject sequence is empty or does not have the expected form, 
no conversion is performed; the value of nptr is stored in the object 
pointed to by endptr, provided that endptr is not a null pointer.
<end quote>

In this case the sequence has not the expected form, i.e. an hexadecimal 
number

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

#59230

jacob navia <jacob@jacob.remcomp.fr> writes:
> Le 29/03/2015 18:44, Barry Schwarz a écrit :
>> The if evaluates to true and 0 is correct return value but *endptr
>> still points to '0' when it should point to 'x'.  Since 0x is not a
>> valid hex constant, the string "0x" should be treated the same as
>> "0a".
>>
>
> That would be the case if the standard was logical but it is
> explicitely stated that 0x should NOT advance the pointer.
>
> <quote>
> C99:
> 7 If the subject sequence is empty or does not have the expected form,
> no conversion is performed; the value of nptr is stored in the object
> pointed to by endptr, provided that endptr is not a null pointer.
> <end quote>
>
> In this case the sequence has not the expected form, i.e. an
> hexadecimal number

"0x" does not have the expected form.  "0" does.

strtol("0x", endptr, 0) should return 0 and set *endptr to point to the
'x'.  The expected form is not a hexadecimal number; it's a number (with
optional sign) that may or may not have a leading 0x.

You use the identifier _Strtoull, which is reserved.  That's ok for code
that's part of the implementation, which this is intended to be.  But
since the function is static, it's not necessary to use a reserved
identifier.

In your main program (enabled if TEST is #defined), you assign the
result of strtoll() to an unsigned long long object.  When I run your
program with an argument of "-1", I get:

strtoull(-1):
         18446744073709551615 2 errno = Success
strtoll(-1):
        18446744073709551615 2 errno = Success

The functions work correctly for this case, but the result of
strtoll(-1) is displayed in a misleading form.

I get several warnings when I compile your program.  The assignments

    *endptr = input;

discard the "const" qualifier.  The solution, in this case, is to add a
cast.  That's unfortunate, but the strto*() functions, via endptr, can
give you a non-const pointer to const data.  (I'm surprised your
compiler didn't warn about this.)

You use "%lld" to print the value end-s, which is of type ptrdiff_t.
The correct format is "%td".  (Yes, I know it happens to work on your
system, but "%td" is both correct and portable.)

At the bottom of this article I've included a patch that corrects some
but not all of these problems.  (It doesn't correct the "0x" and
"-9223372036854775808" problems.)  It also shows the results of both
your functions and the implementation's standard functions.

After applying these changes, when I run your program (compiled with
-DTEST) with an argument of "0x" I get:

Strtoull(0x):
         0 0 errno = Success
Strtoll(0x):
        0 0 errno = Success
strtoull(0x):
         0 1 errno = Success
strtoll(0x):
        0 1 errno = Success

The endptr-s value is inconsistent.

With an argument of "-9223372036854775808" I get:

Strtoull(-9223372036854775808):
         9223372036854775808 20 errno = Success
Strtoll(-9223372036854775808):
        -9223372036854775808 20 errno = Numerical result out of range
strtoull(-9223372036854775808):
         9223372036854775808 20 errno = Success
strtoll(-9223372036854775808):
        -9223372036854775808 20 errno = Success

This is the ambiguous case we discussed before.
strtoll(-9223372036854775808) should, I think, return
-9223372036854775808 and set errno to 0.  (glibc's version does this.)

Here's the patch:

diff --git navia-strto.c navia-strto.c
index 664e13c..4016ba0 100644
--- navia-strto.c
+++ navia-strto.c
@@ -14,3 +14,3 @@
 
-static unsigned long long _Strtoull(const char *input,
+static unsigned long long Strtoull_(const char *input,
                       char **endptr, int base, int Flags)
@@ -32,3 +32,3 @@ static unsigned long long _Strtoull(const char *input,
        since we are going to reuse it */
-     if (endptr) *endptr = input;
+     if (endptr) *endptr = (char*)input;
 
@@ -180,3 +180,3 @@ static unsigned long long _Strtoull(const char *input,
      if (endptr != NULL && ReadSomething > 0) {
-         *endptr = input;
+         *endptr = (char*)input;
      }
@@ -200,3 +200,3 @@ unsigned long Strtol(const char *input, char **endptr, int base)
 {
-     return(_Strtoull(input, endptr, base, SIGNED32));
+     return(Strtoull_(input, endptr, base, SIGNED32));
 }
@@ -208,3 +208,3 @@ long Strtoul(const char *input, char **endptr, int base)
 {
-     return(_Strtoull(input, endptr, base, UNSIGNED32));
+     return(Strtoull_(input, endptr, base, UNSIGNED32));
 }
@@ -216,3 +216,3 @@ unsigned long long Strtoull(const char *input, char **endptr, int base)
 {
-     return(_Strtoull(input, endptr, base, UNSIGNED64));
+     return(Strtoull_(input, endptr, base, UNSIGNED64));
 }
@@ -224,3 +224,3 @@ long long Strtoll(const char *input, char **endptr, int base)
 {
-     return(_Strtoull(input, endptr, base, SIGNED64));
+     return(Strtoull_(input, endptr, base, SIGNED64));
 }
@@ -235,3 +235,3 @@ int main(int argc,char *argv[])
      char *end;
-     char *s = "-2147483647";
+     char *s;
      int save_errno;
@@ -246,12 +246,29 @@ int main(int argc,char *argv[])
          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));
-     errno = 0;
-     m = Strtoll(s,&end,0);
-     save_errno=errno;
-     printf("strtoll(%s):\n        %llu %lld",argv[1],m,end-s);
-     printf(" errno = %s\n",strerror(save_errno));
+
+     {
+         errno = 0;
+         unsigned long long ull = Strtoull(s,&end,0);
+         save_errno = errno;
+         printf("Strtoull(%s):\n         %llu %td",argv[1],ull,end-s);
+         printf(" errno = %s\n",strerror(save_errno));
+         errno = 0;
+         long long ll = Strtoll(s,&end,0);
+         save_errno=errno;
+         printf("Strtoll(%s):\n        %lld %td",argv[1],ll,end-s);
+         printf(" errno = %s\n",strerror(save_errno));
+     }
+
+     {
+         errno = 0;
+         unsigned long long ull = strtoull(s,&end,0);
+         save_errno = errno;
+         printf("strtoull(%s):\n         %llu %td",argv[1],ull,end-s);
+         printf(" errno = %s\n",strerror(save_errno));
+         errno = 0;
+         long long ll = strtoll(s,&end,0);
+         save_errno=errno;
+         printf("strtoll(%s):\n        %lld %td",argv[1],ll,end-s);
+         printf(" errno = %s\n",strerror(save_errno));
+     }
+
 }

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

#59243

jacob navia <jacob@jacob.remcomp.fr> writes:

> Here is the code for the above functions.

I don't think this conforms in these cases:

  "0x"
  "0x0"
  "0u"

The first two are, I think, bugs, but the last is deliberate.  Why do
you accept a suffix on the number?

<snip>
-- 
Ben.

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

#59244

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> jacob navia <jacob@jacob.remcomp.fr> writes:
>
>> Here is the code for the above functions.
>
> I don't think this conforms in these cases:
>
>   "0x"
>   "0x0"
>   "0u"
>
> The first two are, I think, bugs, but the last is deliberate.  Why do
> you accept a suffix on the number?
>
> <snip>

Because a suffix is permitted when base==0.  N1570 7.22.1.3p3.

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

#59246

On Sun, 29 Mar 2015 19:48:49 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> jacob navia <jacob@jacob.remcomp.fr> writes:
>>
>>> Here is the code for the above functions.
>>
>> I don't think this conforms in these cases:
>>
>>   "0x"
>>   "0x0"
>>   "0u"
>>
>> The first two are, I think, bugs, but the last is deliberate.  Why do
>> you accept a suffix on the number?
>>
>> <snip>
>
>Because a suffix is permitted when base==0.  N1570 7.22.1.3p3.

7.22.1.3 is strtod and friends.

7.22.1.4p3 (my copy dated 12Apr2011) states (emphasis mine)":

"If the value of base is zero, the expected form of the subject
sequence is that of an integer constant as described in 6.4.4.1,
optionally preceded by a plus or minus sign, but ****not**** including
an integer suffix."

-- 
Remove del for email

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

#59262

Barry Schwarz <schwarzb@dqel.com> writes:

> On Sun, 29 Mar 2015 19:48:49 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
>
>>Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> jacob navia <jacob@jacob.remcomp.fr> writes:
>>>
>>>> Here is the code for the above functions.
>>>
>>> I don't think this conforms in these cases:
>>>
>>>   "0x"
>>>   "0x0"
>>>   "0u"
>>>
>>> The first two are, I think, bugs, but the last is deliberate.  Why do
>>> you accept a suffix on the number?
>>>
>>> <snip>
>>
>>Because a suffix is permitted when base==0.  N1570 7.22.1.3p3.
>
> 7.22.1.3 is strtod and friends.
>
> 7.22.1.4p3 (my copy dated 12Apr2011) states (emphasis mine)":

Typo?

> "If the value of base is zero, the expected form of the subject
> sequence is that of an integer constant as described in 6.4.4.1,
> optionally preceded by a plus or minus sign, but ****not**** including
> an integer suffix."

Indeed.  But did you mistype the section number?  It is in 7.22.1.3p3
(as claimed) in my copy.

-- 
Ben.

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

#59286

On Mon, 30 Mar 2015 12:44:18 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>Barry Schwarz <schwarzb@dqel.com> writes:
>
>> On Sun, 29 Mar 2015 19:48:49 -0700, Keith Thompson <kst-u@mib.org>
>> wrote:
>>
>>>Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> jacob navia <jacob@jacob.remcomp.fr> writes:
>>>>
>>>>> Here is the code for the above functions.
>>>>
>>>> I don't think this conforms in these cases:
>>>>
>>>>   "0x"
>>>>   "0x0"
>>>>   "0u"
>>>>
>>>> The first two are, I think, bugs, but the last is deliberate.  Why do
>>>> you accept a suffix on the number?
>>>>
>>>> <snip>
>>>
>>>Because a suffix is permitted when base==0.  N1570 7.22.1.3p3.
>>
>> 7.22.1.3 is strtod and friends.
>>
>> 7.22.1.4p3 (my copy dated 12Apr2011) states (emphasis mine)":
>
>Typo?
>
>> "If the value of base is zero, the expected form of the subject
>> sequence is that of an integer constant as described in 6.4.4.1,
>> optionally preceded by a plus or minus sign, but ****not**** including
>> an integer suffix."
>
>Indeed.  But did you mistype the section number?  It is in 7.22.1.3p3
>(as claimed) in my copy.

I'm confused.  I never generate pdf files so I have no software that
can modify one.  This is a cut and paste from my pdf file:

"7.22.1.4 The strtol, strtoll, strtoul, and strtoull functions
Synopsis
1 #include <stdlib.h>
long int strtol(
const char * restrict nptr,
char ** restrict endptr,
int base);
long long int strtoll(
const char * restrict nptr,
char ** restrict endptr,
int base);
unsigned long int strtoul(
const char * restrict nptr,
char ** restrict endptr,
int base);
unsigned long long int strtoull(
const char * restrict nptr,
char ** restrict endptr,
int base);"

and here is the "title" line from the top of the page"

"ISO/IEC 9899:201x Committee Draft — April 12, 2011 N1570"

7.22.1.1 is atof; .2 is atoi etc; .3 is strtod etc; and .4 is strtol
etc.

What is different in yours and is it the same date?

-- 
Remove del for email

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

#59304

Barry Schwarz <schwarzb@dqel.com> writes:

> On Mon, 30 Mar 2015 12:44:18 +0100, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>Barry Schwarz <schwarzb@dqel.com> writes:
>>
>>> On Sun, 29 Mar 2015 19:48:49 -0700, Keith Thompson <kst-u@mib.org>
>>> wrote:
<snip>
>>>>Because a suffix is permitted when base==0.  N1570 7.22.1.3p3.
>>>
>>> 7.22.1.3 is strtod and friends.
>>>
>>> 7.22.1.4p3 (my copy dated 12Apr2011) states (emphasis mine)":
>>
>>Typo?
<snip>
>>Indeed.  But did you mistype the section number?  It is in 7.22.1.3p3
>>(as claimed) in my copy.
>
> I'm confused.  I never generate pdf files so I have no software that
> can modify one.

No, I was confused.  Now, of course, I can't work out why I thought the
section number was as Keith reported it.  I've looked though various
PDFs I have and, although that text appears in difference sections in
different versions, it is never in 7.22.1.3 (for example it's in
7.20.1.4 in the draft of C99).  Sorry for the confusion.

<snip>
-- 
Ben.

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

#59285

Barry Schwarz <schwarzb@dqel.com> writes:
> On Sun, 29 Mar 2015 19:48:49 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
>>Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> jacob navia <jacob@jacob.remcomp.fr> writes:
>>>
>>>> Here is the code for the above functions.
>>>
>>> I don't think this conforms in these cases:
>>>
>>>   "0x"
>>>   "0x0"
>>>   "0u"
>>>
>>> The first two are, I think, bugs, but the last is deliberate.  Why do
>>> you accept a suffix on the number?
>>>
>>> <snip>
>>
>>Because a suffix is permitted when base==0.  N1570 7.22.1.3p3.
>
> 7.22.1.3 is strtod and friends.
>
> 7.22.1.4p3 (my copy dated 12Apr2011) states (emphasis mine)":
>
> "If the value of base is zero, the expected form of the subject
> sequence is that of an integer constant as described in 6.4.4.1,
> optionally preceded by a plus or minus sign, but ****not**** including
> an integer suffix."

Right on both counts; my mistake(s).  That was extraordinarily sloppy of me.

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

#59272

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> jacob navia <jacob@jacob.remcomp.fr> writes:
>>
>>> Here is the code for the above functions.
>>
>> I don't think this conforms in these cases:
>>
>>   "0x"
>>   "0x0"
>>   "0u"
>>
>> The first two are, I think, bugs, but the last is deliberate.
>> Why do you accept a suffix on the number?
>>
>> <snip>
>
> Because a suffix is permitted when base==0.  N1570 7.22.1.3p3.

I see there is some question (or confusion?) about what section
this is in.  In my copy of of N1570, the section headers read:

    7.22.1.3 The strtod, strtof, and strtold functions

(which appears on the page numbered '342'), and

    7.22.1.4 The strtol, strtoll, strtoul, and strtoull functions

(which appears on page numbered '344').

Paragraph 3 of 7.22.1.4 appears on the page numbered '345'.  The
first sentence states:

    If the value of base is zero, the expected form of the
    subject sequence is that of an integer constant as described
    in 6.4.4.1, optionally preceded by a plus or minus sign, but
    not including an integer suffix.

I take this sentence to mean that any integer suffix portion of
an integer constant in not part of the "subject sequence", as
that section uses the term.  That conclusion agrees with glibc's
behavior on the two platforms I tested on.

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

#59245

jacob navia wrote:
> Hi
>
> Here is the code for the above functions.
>
> /*-------------------------------------------------------------*/
> /* strtol() - string of base n to an unsigned long integer     */
> /*-------------------------------------------------------------*/
> unsigned long Strtol(const char *input, char **endptr, int base)
> {
>       return(_Strtoull(input, endptr, base, SIGNED32));
> }
>
> /*------------------------------------------------------------*/
> /* strtol() - string of base n to an unsigned long integer    */
> /*------------------------------------------------------------*/
> long Strtoul(const char *input, char **endptr, int base)
> {
>       return(_Strtoull(input, endptr, base, UNSIGNED32));
> }

These two function names are muddled up.

> /*------------------------------------------------------------*/
> /* strtoull() String base n to an unsigned long long r        */
> /*------------------------------------------------------------*/
> unsigned long long Strtoull(const char *input, char **endptr, int base)
> {
>       return(_Strtoull(input, endptr, base, UNSIGNED64));
> }
>
> /*-----------------------------------------------------------*/
> /* strtoll() String of base n to a signed long long          */
> /*-----------------------------------------------------------*/
> long long Strtoll(const char *input, char **endptr, int base)
> {
>       return(_Strtoull(input, endptr, base, SIGNED64));
> }

Why not use the correct, not capitalised,  names for these functions?

-- 
Ian Collins

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

#59250

On 30/03/15 06:02, Ian Collins wrote:
> jacob navia wrote:

>>
>> /*-----------------------------------------------------------*/
>> /* strtoll() String of base n to a signed long long          */
>> /*-----------------------------------------------------------*/
>> long long Strtoll(const char *input, char **endptr, int base)
>> {
>>       return(_Strtoull(input, endptr, base, SIGNED64));
>> }
>
> Why not use the correct, not capitalised,  names for these functions?

I assumed he was doing that so that readers could test the code without 
it clashing with their standard library. Jolly considerate of him, I 
thought.

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

#59251

Richard Heathfield wrote:
> On 30/03/15 06:02, Ian Collins wrote:
>> jacob navia wrote:
>
>>>
>>> /*-----------------------------------------------------------*/
>>> /* strtoll() String of base n to a signed long long          */
>>> /*-----------------------------------------------------------*/
>>> long long Strtoll(const char *input, char **endptr, int base)
>>> {
>>>        return(_Strtoull(input, endptr, base, SIGNED64));
>>> }
>>
>> Why not use the correct, not capitalised,  names for these functions?
>
> I assumed he was doing that so that readers could test the code without
> it clashing with their standard library. Jolly considerate of him, I
> thought.

I'm so used to platforms where the standard library symbols are week, I 
sometimes forget there are some where they aren't!

-- 
Ian Collins

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

#59252

Ian Collins wrote:
> Richard Heathfield wrote:
>> On 30/03/15 06:02, Ian Collins wrote:
>>> jacob navia wrote:
>>
>>>>
>>>> /*-----------------------------------------------------------*/
>>>> /* strtoll() String of base n to a signed long long          */
>>>> /*-----------------------------------------------------------*/
>>>> long long Strtoll(const char *input, char **endptr, int base)
>>>> {
>>>>         return(_Strtoull(input, endptr, base, SIGNED64));
>>>> }
>>>
>>> Why not use the correct, not capitalised,  names for these functions?
>>
>> I assumed he was doing that so that readers could test the code without
>> it clashing with their standard library. Jolly considerate of him, I
>> thought.
>
> I'm so used to platforms where the standard library symbols are week, I
> sometimes forget there are some where they aren't!

Weak :)

-- 
Ian Collins

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

#59273

jacob navia <jacob@jacob.remcomp.fr> writes:

> Here is the code for the above functions.
>
> [...]
>
> /*-------------------------------------------------------------*/
> /* strtol() - string of base n to an unsigned long integer     */
> /*-------------------------------------------------------------*/
> unsigned long Strtol(const char *input, char **endptr, int base)
> {
>     return(_Strtoull(input, endptr, base, SIGNED32));
> }

The header comment on this function is wrong.  Also the return
types of this function and the next one should be swapped

> /*------------------------------------------------------------*/
> /* strtol() - string of base n to an unsigned long integer    */
> /*------------------------------------------------------------*/
> long Strtoul(const char *input, char **endptr, int base)
> {
>     return(_Strtoull(input, endptr, base, UNSIGNED32));
> }

The header comment here has the right description but gives the
wrong name.

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web