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

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

Code for strtol/strtoul

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

Contents

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

#58998

Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> I respect your attention to detail and also the effort you put in
> to read the Standard carefully.  And I'm not saying how you read
> the text here is wrong.  Really all I am saying is that how the
> WG14 committee expects the text will be read may be different
> than that, and IMO that alternate reading is not unreasonable,
> even if how the text is worded is somewhat poor and no doubt
> could benefit from some editing.  In short, I'm dissatisfied with
> what was written for this, but not so dissatisfied that I would
> say it is unequivocally wrong.  You okay with that?

No, you must have the same opinions I do, with all the same nuances down
to the tiniest detail.

Er, um, I mean yeah, sure, no problem.


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

#59148

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>> I respect your attention to detail and also the effort you put in
>> to read the Standard carefully.  And I'm not saying how you read
>> the text here is wrong.  Really all I am saying is that how the
>> WG14 committee expects the text will be read may be different
>> than that, and IMO that alternate reading is not unreasonable,
>> even if how the text is worded is somewhat poor and no doubt
>> could benefit from some editing.  In short, I'm dissatisfied with
>> what was written for this, but not so dissatisfied that I would
>> say it is unequivocally wrong.  You okay with that?
>
> No, you must have the same opinions I do, with all the same
> nuances down to the tiniest detail.
>
> Er, um, I mean yeah, sure, no problem.

When I said "you okay with that?" I didn't mean "do you share
my point of view," but something more like "does that seem like
a reasonable opinion to hold even though your opinion may be
different?".  But thank you for the humorous reply. :)

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

#58581

On 2015-03-21, jacob navia <jacob@jacob.remcomp.fr> wrote:
> After some days working in those functions, I would like to share this 
> work with you. I think discussing C is as interesting as discussing UFOs 
> ( :-) ), because there some interesting issues in this code.
>
> What to do with bad inputs? The "ever-green" question of what to do with 
> NULLs pops out.
>

I'm not too fond of code that blows up by way of telling I screwed up.
The return value/errno approach works for me.

> What to do with unspecified situations? In this case the standard 
> doesn't define a lot of situations.
>
> 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?
>

It looks right too me, not that looking right means a whole lot but I
did give it some thought.

> What about other stuff like code readability variable names, whatever.
>

Excellent readability. Full points for the comments.

> Thanks in advance for your comments.
>
> jacob
>
> P.S. COPYRIGHT:
>
> This code is my work. If you just read it, you should give me ALL YOUR 
> MONEY (and more, if possible). Anyway even if you do not read it, you
> are doomed since this copyright notice is copyrighted with the same
> rules!
>

All my money you say? You'll need to get more then that from me if you
hope to be able retire by 90.


-- 
http://www.softsprocket.com

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

#58892

Greg Martin <greg.at.softsprocket@dot.com> writes:

> On 2015-03-21, jacob navia <jacob@jacob.remcomp.fr> wrote:
>> After some days working in those functions, I would like to share
>> this work with you.  I think discussing C is as interesting as
>> discussing UFOs ( :-) ), because there some interesting issues in
>> this code.  [snip a few questions]
>>
>> What about other stuff like code readability variable names,
>> whatever.
>
> Excellent readability.  Full points for the comments.

I find this response astonishing.  The central function
is 179 lines long.  Any benefit from the content of the
comments is more than lost in the maze of the long
function body.

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

#58897

Le 25/03/2015 05:50, Tim Rentsch a écrit :
>> Excellent readability.  Full points for the comments.
> I find this response astonishing.  The central function
> is 179 lines long.  Any benefit from the content of the
> comments is more than lost in the maze of the long
> function body.

Given the specs, can you make it any shorter?

It is easy to say "Too long". But what would you take out?

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

#58898

jacob navia wrote:
> Le 25/03/2015 05:50, Tim Rentsch a écrit :
>>> Excellent readability.  Full points for the comments.
>> I find this response astonishing.  The central function
>> is 179 lines long.  Any benefit from the content of the
>> comments is more than lost in the maze of the long
>> function body.
>
> Given the specs, can you make it any shorter?
>
> It is easy to say "Too long". But what would you take out?

I'll show you what I came up with.  It may not be shorter, but it is 
broken down into discrete functions.  It also implements all four 
conversion functions:

#include <stdlib.h>
#include <errno.h>
#include <ctype.h>
#include <stdbool.h>
#include <limits.h>

static int
convertDigit( char digit, int base )
{
   if( base < 11 )
   {
     return digit - '0';
   }
   else
   {
     return digit <= '9' ? digit - '0' : (tolower(digit) - 'a')+10;
   }
}

static bool
isValidDigitForBase( char digit, int base )
{
   static const char beforeNumber = '0'-1;
   static const char afterNumber  = '9'+1;

   if( base < 11 )
   {
     return digit > beforeNumber && digit < '0'+base;
   }
   else
   {
     const bool isNumber = digit > beforeNumber && digit < afterNumber;

     if( isNumber )
     {
       return true;
     }

     digit = tolower(digit);

     return (digit >= 'a' && (digit - 'a') < base-10);
   }
}

static bool
checkPreconditions( const char* str, int base )
{
   return (str && (base == 0 || (base > 1 && base < 37)));
}

typedef const char* restrict rp;

static void
checkForAndConsumeHexPrefix( rp* str, int base )
{
   if( base == 16 )
   {
     rp p = *str;

     if( *p == '0' && tolower(*(p+1)) == 'x' )
     {
       *str += 2;
     }
   }
}

static void
checkForAndConsumeSign( rp* str, bool* isNegative )
{
   const char c = **str;

   if( c == '-' || c == '+')
   {
     ++*str;
   }

   *isNegative = (c == '-') ? true : false;
}

static unsigned long long
Strtoull( const char* restrict str,
           char** restrict      endptr,
           int                  base,
           bool*                isNegative )
{
   if( !checkPreconditions( str, base ) )
   {
     errno = EINVAL;
     return 0;
   }

   if( endptr ) *endptr = (char*)str;

   base = (base == 0) ? 10 : base;

   while( isspace(*str) ) ++str;

   checkForAndConsumeSign( &str, isNegative );

   checkForAndConsumeHexPrefix( &str, base );

   unsigned long long result = 0;

   while( isValidDigitForBase( *str, base) )
   {
     const int digit = convertDigit( *str++, base );

     if( endptr ) *endptr = (char*)str;

     const unsigned long long nextResult = result*base+digit;

     if( nextResult < result )
     {
       errno = ERANGE;
       return ULLONG_MAX;
     }

     result = nextResult;
   }

   return result;
}

static long long
rangeCheck( unsigned long long result, long long min, long long max, 
bool neg )
{
   if( neg )
   {
     const unsigned long long threshold = (unsigned long long)min*-1;

     if( result > threshold )
     {
       errno = ERANGE;
       return min;
     }

     return -result;
   }
   else
   {
     if( result > max )
     {
       errno = ERANGE;
       return max;
     }

     return result;
   }
}

unsigned long long
strtoull( const char* restrict str, char** restrict endptr, int base )
{
   bool neg = false;
   return Strtoull( str, endptr, base, &neg );
}

long long
strtoll( const char* restrict str, char** restrict endptr, int base )
{
   bool neg = false;
   unsigned long long result = Strtoull( str, endptr, base, &neg );

   return rangeCheck( result, LLONG_MIN, LLONG_MAX, neg );
}

unsigned long
strtoul( const char* restrict str, char** restrict endptr, int base )
{
   bool neg = false;

   unsigned long long result = Strtoull( str, endptr, base, &neg );

   return rangeCheck( result, 0, ULONG_MAX, false );
}

long
strtol( const char* restrict str, char** restrict endptr, int base )
{
   bool neg = false;
   unsigned long long result = Strtoull( str, endptr, base, &neg );

   return rangeCheck( result, LONG_MIN, LONG_MAX, neg );
}


-- 
Ian Collins

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

#58906

Le 25/03/2015 07:18, Ian Collins a écrit :
> static unsigned long long
> Strtoull( const char* restrict str,
>            char** restrict      endptr,
>            int                  base,
>            bool*                isNegative )
> {
>    if( !checkPreconditions( str, base ) )
>    {
>      errno = EINVAL;
>      return 0;
>    }
>
>    if( endptr ) *endptr = (char*)str;
>
>    base = (base == 0) ? 10 : base;
>
>    while( isspace(*str) ) ++str;
>
>    checkForAndConsumeSign( &str, isNegative );

If base is zero and the first digit is zero the base is 8. This is not 
done here.

>
>    checkForAndConsumeHexPrefix( &str, base );

This should be done ONLY if the base is zero. For all other bases except 
16 the prefix "0x" is WRONG. But you have overwriten base so you can't 
know now.

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

#58940

jacob navia wrote:
> Le 25/03/2015 07:18, Ian Collins a écrit :
>> static unsigned long long
>> Strtoull( const char* restrict str,
>>             char** restrict      endptr,
>>             int                  base,
>>             bool*                isNegative )
>> {
>>     if( !checkPreconditions( str, base ) )
>>     {
>>       errno = EINVAL;
>>       return 0;
>>     }
>>
>>     if( endptr ) *endptr = (char*)str;
>>
>>     base = (base == 0) ? 10 : base;
>>
>>     while( isspace(*str) ) ++str;
>>
>>     checkForAndConsumeSign( &str, isNegative );
>
> If base is zero and the first digit is zero the base is 8. This is not
> done here.

Thanks, I missed that requirement.

>>
>>     checkForAndConsumeHexPrefix( &str, base );
>
> This should be done ONLY if the base is zero. For all other bases except
> 16 the prefix "0x" is WRONG. But you have overwriten base so you can't
> know now.

If the base is 0 or 16, ditto previous comment.

-- 
Ian Collins

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

#58996

Ian Collins wrote:
> jacob navia wrote:
>> Le 25/03/2015 07:18, Ian Collins a écrit :
>>> static unsigned long long
>>> Strtoull( const char* restrict str,
>>>              char** restrict      endptr,
>>>              int                  base,
>>>              bool*                isNegative )
>>> {
>>>      if( !checkPreconditions( str, base ) )
>>>      {
>>>        errno = EINVAL;
>>>        return 0;
>>>      }
>>>
>>>      if( endptr ) *endptr = (char*)str;
>>>
>>>      base = (base == 0) ? 10 : base;
>>>
>>>      while( isspace(*str) ) ++str;
>>>
>>>      checkForAndConsumeSign( &str, isNegative );
>>
>> If base is zero and the first digit is zero the base is 8. This is not
>> done here.
>
> Thanks, I missed that requirement.

Updated to:

   checkForAndConsumeSign( &str, isNegative );

   base = checkForAndConsumePrefix( &str, base );

   base = (base == 0) ? 10 : base;

where:

static int
checkForAndConsumePrefix( rp* str, int base )
{
   if( base == 0 || base == 8 || base == 16 )
   {
     rp p = *str;

     if( *p == '0' )
     {
       ++p;

       if( tolower(*p) == 'x' && base != 8 )
       {
         *str += 2;

         base = 16;
       }
       else if( base != 16 )
       {
         *str += 1;

         base = 8;
       }
     }
   }

   return base;
}

-- 
Ian Collins

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

#59003

 in the Space u use For
checkForAndConsumePrefix() function
one would had write
all strtol() function
or strtou32()

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

#59107

asetofsymbols@gmail.com wrote:
>   in the Space u use For
> checkForAndConsumePrefix() function
> one would had write
> all strtol() function
> or strtou32()

I don't know who u is in this context, but assuming it was me all I can 
say is put up or shut up.

-- 
Ian Collins

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

#59116

I wrote:
<<
in the Space u use For 
checkForAndConsumePrefix() function
>>
Yes i forgot the respect...
I would had to use "you" in the
place of "u"

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

#58914

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

> Le 25/03/2015 05:50, Tim Rentsch a ecrit :
>>> Excellent readability.  Full points for the comments.
>>
>> I find this response astonishing.  The central function
>> is 179 lines long.  Any benefit from the content of the
>> comments is more than lost in the maze of the long
>> function body.
>
> Given the specs, can you make it any shorter?

I believe I can, yes.

> It is easy to say "Too long".  But what would you take out?

I will try to put something together and post it.  It may be
a few days before I can actually post something, as the
problem is not trivial (which I'm sure you can appreciate).

I should add that I applaud both the effort you put in to
writing the code, and posting the result in the newsgroup.
Whatever comments I might have about the code, I appreciate
the effort you have put in on this, which IMO benefits the
group significantly - we need more threads like this one.

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

#59181

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

> Le 25/03/2015 05:50, Tim Rentsch a ecrit :
>>> Excellent readability.  Full points for the comments.
>>
>> I find this response astonishing.  The central function
>> is 179 lines long.  Any benefit from the content of the
>> comments is more than lost in the maze of the long
>> function body.
>
> Given the specs, can you make it any shorter?  [snip]

I've had a chance to write a full version now.  The entry points
for the four strto*l() functions all go through a common core
routine called strcore().  Here is that function definition
(deliberately left commentless - there are notes following):

static ULL
strcore( String s0, char **tail, unsigned base, Edges edges ){
    if(  !s0  ||  base != 0  &&  base - 2 > 34  )  return  errno = EINVAL,  0;

    const String sign =  skip_white( s0 );
    const String p    =  sign + (*sign == '+' || *sign == '-');
    const int    oxN  =  p[0] == '0'  &&  V( p[1] ) == 33  &&  V( p[2] ) < 16;

    if(  base ==  0  &&  oxN          )  base = 16;
    if(  base ==  0  &&  p[0] == '0'  )  base =  8;
    if(  base ==  0                   )  base = 10;

    const String s    =  base == 16 && oxN  ?  p+2  :  p;
    const String t    =  skip_digits( s, base );
    if(  tail  )  *tail = (char*) (s == t  ? s0 : t);

    return  numeric_value( s, t, base, *sign == '-', edges );
}

Notes:

[1] The type "String' is just 'const char *'.

[2] The variable 'edges' is important in the called numeric
conversion routine but not in this function itself.

[3] The function V() (and don't ask me to explain why it's called
that) converts its character argument to the corresponding digit
value.  So for example an expression 'V( c ) < 16' tests whether
the argument c is a valid hexadecimal "digit".  Internally V()
basically just indexs an array to compute the return value.

[4] The routines skip_white() and skip_digits() do what you
probably expect, and are quite short (in my version they are
one line each, but in any case no more than a few lines).

[5] The function numeric_value() is of similar length to this
function.  It converts digits between 's' and 't' using the
given base, negating according to the logical value of the
fourth argument, and checking for out-of-range and giving
default values based on the values in 'edges'.

A summary outline of functions giving body line lengths is as
follows (first three columns are lines, non-blank lines,
and blank lines, respectively):

        2     2     0   my_strtoull
        2     2     0   my_strtoul
        2     2     0   my_strtoll
        2     2     0   my_strtol
        1     1     0   signed_value_for
       15    11     4   strcore
       13    11     2   numeric_value
        1     1     0   skip_white
        1     1     0   skip_digits
       22    21     1   V

       61    54     7   (total)

These numbers are not directly comparable to measuring
line counts in your code, both because of some style
differences and because the code you posted has extensive
comments inside function bodies whereas the functions
listed above do not.  Despite that though I think you
can see that the goal of having much shorter function
bodies can be achieved.  (Incidentally the longest function
body, for V(), is almost all defining the array that is
indexed to produce a value.)

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

#58910

On 2015-03-25, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Greg Martin <greg.at.softsprocket@dot.com> writes:
>
>> On 2015-03-21, jacob navia <jacob@jacob.remcomp.fr> wrote:
>>> After some days working in those functions, I would like to share
>>> this work with you.  I think discussing C is as interesting as
>>> discussing UFOs ( :-) ), because there some interesting issues in
>>> this code.  [snip a few questions]
>>>
>>> What about other stuff like code readability variable names,
>>> whatever.
>>
>> Excellent readability.  Full points for the comments.
>
> I find this response astonishing.  The central function
> is 179 lines long.  Any benefit from the content of the
> comments is more than lost in the maze of the long
> function body.

So you found it hard to read then? I can't say that I did, though I don't
entirely remember. If memory serves the comments were placed at the
point in the code where the code was they described. 

Short functions are often preferable but I don't recall finding the
function difficult to follow in any way - which I find the true measure
of readability.

-- 
http://www.softsprocket.com

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

#58992

Greg Martin <greg.at.softsprocket@dot.com> writes:

> On 2015-03-25, Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Greg Martin <greg.at.softsprocket@dot.com> writes:
>>
>>> On 2015-03-21, jacob navia <jacob@jacob.remcomp.fr> wrote:
>>>> After some days working in those functions, I would like to share
>>>> this work with you.  I think discussing C is as interesting as
>>>> discussing UFOs ( :-) ), because there some interesting issues in
>>>> this code.  [snip a few questions]
>>>>
>>>> What about other stuff like code readability variable names,
>>>> whatever.
>>>
>>> Excellent readability.  Full points for the comments.
>>
>> I find this response astonishing.  The central function
>> is 179 lines long.  Any benefit from the content of the
>> comments is more than lost in the maze of the long
>> function body.
>
> So you found it hard to read then?

I found it hard to comprehend in the sense that I felt like it
would have taken a lot of effort to convince myself that what it
was doing is correct.  That's probably my most important metric -
how hard do I have to work to convince myself that the code is
correct.

Also, for me, I find it hurts a lot more than it helps to
intermingle comments of specification and executable code.  This
style of commenting is one I used a long time ago (in a galaxy
far, far away from the other side of the universe) when I was
writing assembly language.  Looking back I see it as more of a
habit for beginners than a mature development practice.

> I can't say that I did, though
> I don't entirely remember.  If memory serves the comments were
> placed at the point in the code where the code was they described.

Yes, that's the assembly language style.  The main problem with that
style is it doesn't scale up (not to mention being a poor match for
natural cognitive modes, as some important research has shown).

> Short functions are often preferable but I don't recall finding
> the function difficult to follow in any way - which I find the
> true measure of readability.

Without reading the comments, how easily can you understand
what the function is doing?  How much effort is it to convince
yourself that the code is correct?  Code that is well-written
doesn't need comments to achieve these goals.  Incidentally,
on the term "readability" is one I find means different things
to different people, and often doesn't capture what I believe
is a more important aspect, namely comprehensibility.  A given
piece of code can be easy to read and hard to comprehend, or
(in some cases) vice versa;  IMO this makes it all the more
important to distinguish these different aspects (and sometimes
other aspects as well).

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

#59000

On 2015-03-26, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Greg Martin <greg.at.softsprocket@dot.com> writes:
>
>> On 2015-03-25, Tim Rentsch <txr@alumni.caltech.edu> wrote:
>>> Greg Martin <greg.at.softsprocket@dot.com> writes:
>>>
>>>> On 2015-03-21, jacob navia <jacob@jacob.remcomp.fr> wrote:
>>>>> After some days working in those functions, I would like to share
>>>>> this work with you.  I think discussing C is as interesting as
>>>>> discussing UFOs ( :-) ), because there some interesting issues in
>>>>> this code.  [snip a few questions]
>>>>>
>>>>> What about other stuff like code readability variable names,
>>>>> whatever.
>>>>
>>>> Excellent readability.  Full points for the comments.
>>>
>>> I find this response astonishing.  The central function
>>> is 179 lines long.  Any benefit from the content of the
>>> comments is more than lost in the maze of the long
>>> function body.
>>
>> So you found it hard to read then?
>
> I found it hard to comprehend in the sense that I felt like it
> would have taken a lot of effort to convince myself that what it
> was doing is correct.  That's probably my most important metric -
> how hard do I have to work to convince myself that the code is
> correct.

This metric is amazingly broadly applicable; it's the underlying
justification for any effective methodology, tool or practice.

- Functional programming: reduces the effort to convince yourself that
  it's correct, by removing difficult proof techniques related to side effects

- OOP: reduces effort to convince yourself that it's correct, by
  modularity, encapsulation, type substitutability and such.

- Functional decomposition: reduces the effort to convince yourself
  that the code is correct, by breaking it into smaller pieces that
  are easier to understand in isolation.

- Control structures: reduce the effort to convince yourself that
  imperative code is correct by detangling the flow graph.

- Lisp macros: reduce the effort to convince yourself that the code
  is correct by extending the language with robust constructs,
  which write code correctly that would otherwise be written by hand
  incorrectly.

- Code reuse: reduces the effort to convince yourself that
  the code is correct, since you can stop reading when you hit
  a familiar library function that is mature and widely used,
  and just replace it by its meaning.

- Threads? Errrr, the lesson is over for today, said the Tao master.

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

#59004

Kaz Kylheku wrote:<<
This metric is amazingly broadly applicable; it's the underlying 
justification for any effective methodology, tool or practice. 

- Functional programming: reduces the effort to convince yourself that 
  it's correct, by removing difficult proof techniques related to side effects 

- OOP: reduces effort to convince yourself that it's correct, by 
  modularity, encapsulation, type substitutability and such. 

- Functional decomposition: reduces the effort to convince yourself 
  that the code is correct, by breaking it into smaller pieces that 
  are easier to understand in isolation. 

- Control structures: reduce the effort to convince yourself that 
  imperative code is correct by detangling the flow graph. 

- Lisp macros: reduce the effort to convince yourself that the code 
  is correct by extending the language with robust constructs, 
  which write code correctly that would otherwise be written by hand 
  incorrectly. 

- Code reuse: reduces the effort to convince yourself that 
  the code is correct, since you can stop reading when you hit 
  a familiar library function that is mature and widely used, 
  and just replace it by its meaning. 

- Threads? Errrr, the lesson is over for>>

Yes all for think less...
One good language would be
 the one not
miss, (because complexities) 
the instruction that cpu execute
One language scalable...

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

#59019

On 2015-03-26, asetofsymbols@gmail.com <asetofsymbols@gmail.com> wrote:
> Kaz Kylheku wrote:<<
> This metric is amazingly broadly applicable; it's the underlying 
> justification for any effective methodology, tool or practice. 

Dickhead, please do not reply to me any more until you can do so with proper
quote marks.

> Yes all for think less...
> One good language would be
>  the one not
> miss, (because complexities) 
> the instruction that cpu execute
> One language scalable...

Sock puppet for fir?

It's literally raining dumb polacks around here lately.

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

#59020

W dniu czwartek, 26 marca 2015 14:44:15 UTC+1 użytkownik Kaz Kylheku napisał:
> On 2015-03-26, asetofsymbols@gmail.com <asetofsymbols@gmail.com> wrote:
> > Kaz Kylheku wrote:<<
> > This metric is amazingly broadly applicable; it's the underlying 
> > justification for any effective methodology, tool or practice. 
> 
> Dickhead, please do not reply to me any more until you can do so with proper
> quote marks.
> 
> > Yes all for think less...
> > One good language would be
> >  the one not
> > miss, (because complexities) 
> > the instruction that cpu execute
> > One language scalable...
> 
> Sock puppet for fir?
> 
> It's literally raining dumb polacks around here lately.

if someone writes insane doesnt make him
dickhead - but such insulting you make primitive 'dickhead insulter', are making you
strightl;y 'dickhead insulter'

yet some insults in stock, something more about 'primitive pollacks' maybe  ?

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

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

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

csiph-web