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

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

better atoi

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

Contents

  better atoi fir <profesor.fir@gmail.com> - 2017-02-10 12:24 -0800
    Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-10 12:35 -0800
    Re: better atoi Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-10 14:48 -0700
      Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-10 14:12 -0800
        Re: better atoi Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-10 22:36 -0700
          Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-11 01:07 -0800
            Re: better atoi Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-11 10:10 -0700
              Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-11 09:26 -0800
                Re: better atoi Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-11 15:36 -0700
                  Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-12 00:18 -0800
                    Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-12 00:31 -0800
                      Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-12 03:47 -0800
                        Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-12 04:22 -0800
                          Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-12 06:08 -0800
                            Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-12 06:13 -0800
                              Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-12 07:31 -0800
                                Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-12 08:02 -0800
                                  Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-12 08:08 -0800
                                    Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-12 08:17 -0800
                                      Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-12 08:23 -0800
                            Re: better atoi Robert Latest <boblatest@yahoo.com> - 2017-02-19 11:11 +0000
              Re: better atoi Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-11 17:33 +0000
                Re: better atoi Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-11 15:35 -0700
                  Re: better atoi "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-11 17:52 -0500
                    Re: better atoi Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-11 18:53 -0700
      Re: better atoi Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 22:50 +0000
        Re: better atoi Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-10 21:59 -0700
          Re: better atoi Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-11 12:08 +0000
            Re: better atoi Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-11 09:39 -0700
              Re: better atoi Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-11 17:26 +0000
                Re: better atoi Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-11 15:30 -0700
                  Re: better atoi Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-11 22:58 +0000
                    Re: better atoi Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-11 18:48 -0700
                      Re: better atoi Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-12 02:16 +0000
                      Re: better atoi "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-12 09:57 -0500
                        Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-12 07:27 -0800
                          Re: better atoi jameskuyper@verizon.net - 2017-02-12 08:44 -0800
                            Re: better atoi fir <profesor.fir@gmail.com> - 2017-02-12 09:15 -0800
                              Re: better atoi Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-12 09:44 -0800
                                Re: better atoi BartC <bc@freeuk.com> - 2017-02-12 18:32 +0000
                                  Re: better atoi Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-12 18:56 +0000
                                    Re: better atoi BartC <bc@freeuk.com> - 2017-02-12 19:18 +0000
                                      Re: better atoi Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-13 00:16 +0000
                                        Re: better atoi BartC <bc@freeuk.com> - 2017-02-13 01:56 +0000
                                          Re: better atoi Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-13 10:44 +0000
                                            Re: better atoi BartC <bc@freeuk.com> - 2017-02-13 11:38 +0000
                                              Re: better atoi Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-13 14:37 +0000
                                                Re: better atoi BartC <bc@freeuk.com> - 2017-02-13 15:00 +0000
                                  Re: better atoi Keith Thompson <kst-u@mib.org> - 2017-02-12 11:15 -0800
                                    Re: better atoi BartC <bc@freeuk.com> - 2017-02-12 19:25 +0000
                                      Re: better atoi Keith Thompson <kst-u@mib.org> - 2017-02-12 11:54 -0800
                                  Re: better atoi supercat@casperkitty.com - 2017-02-12 13:13 -0800
      Re: better atoi Keith Thompson <kst-u@mib.org> - 2017-02-10 15:16 -0800
        Re: better atoi Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-10 22:01 -0700
          Re: better atoi Keith Thompson <kst-u@mib.org> - 2017-02-11 01:30 -0800
        Re: better atoi Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-10 22:26 -0700
      Re: better atoi Nick Bowler <nbowler@draconx.ca> - 2017-02-11 00:26 +0000
        Re: better atoi Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-10 22:32 -0700
      Re: better atoi "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-19 11:10 -0500

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

#104182

fir wrote:
> for example how it would look like a code 
> needed to mine (dig) all integers form given 
> string like 
>
> char* txt = "some: 100, 200, 300; then: 3, 4, 5, 6, 7, 8, 9; and then: -10, -20, -30; "
>
> i will consider some simple version that will come to my mind ->
>
> if such function will take pointer to "current char" in string it could move it to another char after digged int 
> (if no int digged it could set it to last char (it is string trailing null)) 

That's quite simple using something along the lines of:

    ep = s;
    for (; *s && !isdigit(*s); ++s);
    num = strtol(s, &ep, base);
    /* do stuff with num */
    s = ep;

wrapped in a loop peppered with appropriate checks for errors and
end-of-string. If your numbers contain signs and non-decimal digits the
isdigit() check needs to be broadened accordingly.

robert

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

#103686

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

> fir <profesor.fir@gmail.com> writes:
>>
>> well im not sure, could you tell maybe how i can check if
>> there was an out of range, or non numer , and number but with 'dirty'
>> input provided?
>
> Seriously?  OK.
>
> #include <errno.h>
> #include <limits.h>
> #include <stdio.h>
> #include <stdlib.h>
>
> void checknum(const char *nptr, int base)
> {
>     long int val;
>     char *endptr;
>
>     fprintf(stderr, "testing string \"%s\" in base %d\n", nptr, base);
>     errno = 0;
>     val = strtol(nptr, &endptr, base);
>
>     if (val == LONG_MAX)
> 	fputs("value returned is LONG_MAX\n", stderr);
>     else if (val == LONG_MIN)
> 	fputs("value returned is LONG_MIN\n", stderr);
>     else
> 	fprintf(stderr, "value returned is %ld\n", val);

You have a problem here because the neither the description of fputs nor
of fprintf document the use of errno so either may set errno to non-zero
(even when there is no error!).

>     if (errno != 0)
> 	perror("Error in input");
>
>     if (endptr == nptr)
> 	fputs("string does not start with whitespace followed by number\n", stderr);
>     else if (*endptr != '\0')
> 	fprintf(stderr, "more characters in string after number \"%s\"\n", endptr);
>     else fputs("no characters in string after number\n", stderr);
>
>     fputc('\n', stderr);
> 
> }

<snip>
-- 
Ben.

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

#103699

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> You have a problem here because the neither the description of fputs nor
> of fprintf document the use of errno so either may set errno to non-zero
> (even when there is no error!).

Given that I'm the guy with apparently unjustified fears of errno
changing, that's doubly embarrassing!  Here we go:

#include <errno.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>

void checknum(const char *nptr, int base)
{
    long int val;
    char *endptr;

    fprintf(stderr, "testing string \"%s\" in base %d\n", nptr, base);
    errno = 0;
    val = strtol(nptr, &endptr, base);
    
    if (errno != 0)
	perror("Error in input");

    if (val == LONG_MAX)
	fputs("value returned is LONG_MAX\n", stderr);
    else if (val == LONG_MIN)
	fputs("value returned is LONG_MIN\n", stderr);
    else
	fprintf(stderr, "value returned is %ld\n", val);

    if (endptr == nptr)
	fputs("string does not start with whitespace followed by number\n", stderr);
    else if (*endptr != '\0')
	fprintf(stderr, "more characters in string after number \"%s\"\n", endptr);
    else fputs("no characters in string after number\n", stderr);

    fputc('\n', stderr);
}

int main(void)
{
    char *str1 = " 0034aaa";  // may or may not be a single number
    char *str2 = "fffffffffffffffff"; // won't fit in 64 bit long

    checknum(str1, 16); // 'a' is a digit in base 16
    checknum(str1, 10); // 'a' is not a digit in base 10
    checknum(str2, 16); // too big
    checknum(str2, 10); // no number in string in base 10
}

-- 
"Erwin, have you seen the cat?" -- Mrs. Shrödinger

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

#103702

On 02/11/2017 05:35 PM, Joe Pfeiffer wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> You have a problem here because the neither the description of fputs nor
>> of fprintf document the use of errno so either may set errno to non-zero
>> (even when there is no error!).
>
> Given that I'm the guy with apparently unjustified fears of errno
> changing, that's doubly embarrassing!  Here we go:
>
> #include <errno.h>
> #include <limits.h>
> #include <stdio.h>
...
>     errno = 0;
>     val = strtol(nptr, &endptr, base);
>
>     if (errno != 0)
> 	perror("Error in input");

I'd recommend enclosing this part in
   if(errno==ERANGE)
   {

>     if (val == LONG_MAX)
> 	fputs("value returned is LONG_MAX\n", stderr);
>     else if (val == LONG_MIN)
> 	fputs("value returned is LONG_MIN\n", stderr);
   }

If ERANGE has been set, LONG_MAX indicates that the value was too high 
to be representable, and LONG_MIN indicates that it was to low to be 
representable. However, if errno was not set to ERANGE, a return value 
of either LONG_MAX or LONG_MIN means only that the input string 
represented that value.

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

#103709

"James R. Kuyper" <jameskuyper@verizon.net> writes:

> On 02/11/2017 05:35 PM, Joe Pfeiffer wrote:
>
> I'd recommend enclosing this part in
>   if(errno==ERANGE)
>   {
>
>>     if (val == LONG_MAX)
>> 	fputs("value returned is LONG_MAX\n", stderr);
>>     else if (val == LONG_MIN)
>> 	fputs("value returned is LONG_MIN\n", stderr);
>   }
>
> If ERANGE has been set, LONG_MAX indicates that the value was too high
> to be representable, and LONG_MIN indicates that it was to low to be
> representable. However, if errno was not set to ERANGE, a return value
> of either LONG_MAX or LONG_MIN means only that the input string
> represented that value.

In a "real" program, you're right.  This program is just trying to show
the returns as simply as possible (but still seems to be beyond fir's
ability to read code...).
-- 
"Erwin, have you seen the cat?" -- Mrs. Shrödinger

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

#103634

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

> fir <profesor.fir@gmail.com> writes:
>>
>> http://www.cplusplus.com/reference/cstdlib/strtol/
>>
>> it is said that strtol sets  errno to ERANGE but is
>> not mentioned with wrong value, so im not sure if
>> it can be uniformly checked (probably yest though 
>> but only not noted (i not checked it though))
>
> It says it returns LONG_MAX or LONG_MIN in this case (so it appears it
> is possible that if the string does in fact represent one of those
> values, you can't reliably detect the conversion was successful -- as
> we've seen in other places, we can't rely on ERRNO being 0 on success.
> We'd sort of hope for it in this function...).

I don't think that's the right reading of the situation.  Here's the
relevant text (with stuff about threads elided):

  "The value of errno [...] is zero at program startup [...], but is
  never set to zero by any library function.  The value of errno may be
  set to nonzero by a library function call whether or not there is an
  error, provided the use of errno is not documented in the description
  of the function in this International Standard."

<snip>
-- 
Ben.

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

#103657

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>
>> fir <profesor.fir@gmail.com> writes:
>>>
>>> http://www.cplusplus.com/reference/cstdlib/strtol/
>>>
>>> it is said that strtol sets  errno to ERANGE but is
>>> not mentioned with wrong value, so im not sure if
>>> it can be uniformly checked (probably yest though 
>>> but only not noted (i not checked it though))
>>
>> It says it returns LONG_MAX or LONG_MIN in this case (so it appears it
>> is possible that if the string does in fact represent one of those
>> values, you can't reliably detect the conversion was successful -- as
>> we've seen in other places, we can't rely on ERRNO being 0 on success.
>> We'd sort of hope for it in this function...).
>
> I don't think that's the right reading of the situation.  Here's the
> relevant text (with stuff about threads elided):
>
>   "The value of errno [...] is zero at program startup [...], but is
>   never set to zero by any library function.  The value of errno may be
>   set to nonzero by a library function call whether or not there is an
>   error, provided the use of errno is not documented in the description
>   of the function in this International Standard."

I hope you're right -- as I remember it, the documentation required is a
statement saying it *doesn't* set it unless there is an error.  My
recollection is that some functions (I want to say open()?) will set it,
even though there is no error.  You have to check the return value for
error, and then look at errno to see what the error is.

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

#103674

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>
>>> fir <profesor.fir@gmail.com> writes:
>>>>
>>>> http://www.cplusplus.com/reference/cstdlib/strtol/
>>>>
>>>> it is said that strtol sets  errno to ERANGE but is
>>>> not mentioned with wrong value, so im not sure if
>>>> it can be uniformly checked (probably yest though 
>>>> but only not noted (i not checked it though))
>>>
>>> It says it returns LONG_MAX or LONG_MIN in this case (so it appears it
>>> is possible that if the string does in fact represent one of those
>>> values, you can't reliably detect the conversion was successful -- as
>>> we've seen in other places, we can't rely on ERRNO being 0 on success.
>>> We'd sort of hope for it in this function...).
>>
>> I don't think that's the right reading of the situation.  Here's the
>> relevant text (with stuff about threads elided):
>>
>>   "The value of errno [...] is zero at program startup [...], but is
>>   never set to zero by any library function.  The value of errno may be
>>   set to nonzero by a library function call whether or not there is an
>>   error, provided the use of errno is not documented in the description
>>   of the function in this International Standard."
>
> I hope you're right

Well, I'm right about the quote -- it's a direct cut-and-paste!!

> -- as I remember it, the documentation required is a
> statement saying it *doesn't* set it unless there is an error.

The three "it"s are confusing me.  Do you mean "as I remember it, the
documentation required is a statement saying that strtol *doesn't* set
errno unless there is an error"?  Or are you making a more general point
about other functions?

> My recollection is that some functions (I want to say open()?) will
> set it, even though there is no error.

Yes, they may -- provided the standard does not document the use of
errno for that function.

> You have to check the return
> value for error, and then look at errno to see what the error is.

That's the normal pattern, but for the strto* functions you need to test
for a range error and for a conversion error.  There's a lot of
confusion about how to use them so here's an example:

  bool parse_long(const char *s, long *lp)
  {
       char *endp;
       errno = 0;
       *(lp ? lp : &(long){0}) = strtol(s, &endp, 0);
       return endp > s && errno != ERANGE && endp[strspn(endp, " \t")] == 0;
  }

This function extracts a long int value from a string, putting it in *lp
if lp is not null.  The key part is the return.  In this case it checks
that a conversion was made (endp > s), that the result was in range
(errno != ERANGE) and that nothing but spaces and tabs follow the
number.

I hope people will pile in in the usual c.l.c way to make sure that this
really is conforming and/or to offer other ways to do this sort of
check.

(The use of strspn makes the function asymmetric -- it accepts other
kinds of space in front of the number but not after.  This would be
nicer:

  const char *skip(const char *s, int (*test)(int))
  {
       while (test((unsigned char)*s)) s++;
       return s;
  }
   
  bool parse_long(const char *s, long *lp)
  {
       char *endp;
       errno = 0;
       *(lp ? lp : &(long){0}) = strtol(s, &endp, 0);
       return endp > s && errno != ERANGE && *skip(endp, isspace) == 0;
  }

but at the expense of complicating parts that were not relevant.)

-- 
Ben.

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

#103681

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>>
>>>> fir <profesor.fir@gmail.com> writes:
>>>>>
>>>>> http://www.cplusplus.com/reference/cstdlib/strtol/
>>>>>
>>>>> it is said that strtol sets  errno to ERANGE but is
>>>>> not mentioned with wrong value, so im not sure if
>>>>> it can be uniformly checked (probably yest though 
>>>>> but only not noted (i not checked it though))
>>>>
>>>> It says it returns LONG_MAX or LONG_MIN in this case (so it appears it
>>>> is possible that if the string does in fact represent one of those
>>>> values, you can't reliably detect the conversion was successful -- as
>>>> we've seen in other places, we can't rely on ERRNO being 0 on success.
>>>> We'd sort of hope for it in this function...).
>>>
>>> I don't think that's the right reading of the situation.  Here's the
>>> relevant text (with stuff about threads elided):
>>>
>>>   "The value of errno [...] is zero at program startup [...], but is
>>>   never set to zero by any library function.  The value of errno may be
>>>   set to nonzero by a library function call whether or not there is an
>>>   error, provided the use of errno is not documented in the description
>>>   of the function in this International Standard."
>>
>> I hope you're right
>
> Well, I'm right about the quote -- it's a direct cut-and-paste!!

Well, yeah -- I mean the interpretation.
>> -- as I remember it, the documentation required is a
>> statement saying it *doesn't* set it unless there is an error.
>
> The three "it"s are confusing me.  Do you mean "as I remember it, the
> documentation required is a statement saying that strtol *doesn't* set
> errno unless there is an error"?  Or are you making a more general point
> about other functions?

Telepathy not working today? :)

As I remember the situation, the documentation required is a
statement saying the function *doesn't* set errno unless there is an
error.

>> My recollection is that some functions (I want to say open()?) will
>> set it, even though there is no error.
>
> Yes, they may -- provided the standard does not document the use of
> errno for that function.
>
>> You have to check the return
>> value for error, and then look at errno to see what the error is.
>
> That's the normal pattern, but for the strto* functions you need to test
> for a range error and for a conversion error.  There's a lot of
> confusion about how to use them so here's an example:
>
>   bool parse_long(const char *s, long *lp)
>   {
>        char *endp;
>        errno = 0;
>        *(lp ? lp : &(long){0}) = strtol(s, &endp, 0);
>        return endp > s && errno != ERANGE && endp[strspn(endp, " \t")] == 0;
>   }
>
> This function extracts a long int value from a string, putting it in *lp
> if lp is not null.  The key part is the return.  In this case it checks
> that a conversion was made (endp > s), that the result was in range
> (errno != ERANGE) and that nothing but spaces and tabs follow the
> number.
>
> I hope people will pile in in the usual c.l.c way to make sure that this
> really is conforming and/or to offer other ways to do this sort of
> check.
>
> (The use of strspn makes the function asymmetric -- it accepts other
> kinds of space in front of the number but not after.  This would be
> nicer:
>
>   const char *skip(const char *s, int (*test)(int))
>   {
>        while (test((unsigned char)*s)) s++;
>        return s;
>   }
>    
>   bool parse_long(const char *s, long *lp)
>   {
>        char *endp;
>        errno = 0;
>        *(lp ? lp : &(long){0}) = strtol(s, &endp, 0);
>        return endp > s && errno != ERANGE && *skip(endp, isspace) == 0;
>   }
>
> but at the expense of complicating parts that were not relevant.)

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

#103685

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
<snip>
>>>>   "The value of errno [...] is zero at program startup [...], but is
>>>>   never set to zero by any library function.  The value of errno may be
>>>>   set to nonzero by a library function call whether or not there is an
>>>>   error, provided the use of errno is not documented in the description
>>>>   of the function in this International Standard."

<snip>
> As I remember the situation, the documentation required is a
> statement saying the function *doesn't* set errno unless there is an
> error.

I must be rather dense to day because I just don't get what you are
saying.  Can you give an example of either some documentation or a code
fragment that does not comport with that quote above from the standard?

<snip>
-- 
Ben.

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

#103698

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>>
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> <snip>
>>>>>   "The value of errno [...] is zero at program startup [...], but is
>>>>>   never set to zero by any library function.  The value of errno may be
>>>>>   set to nonzero by a library function call whether or not there is an
>>>>>   error, provided the use of errno is not documented in the description
>>>>>   of the function in this International Standard."
>
> <snip>
>> As I remember the situation, the documentation required is a
>> statement saying the function *doesn't* set errno unless there is an
>> error.
>
> I must be rather dense to day because I just don't get what you are
> saying.  Can you give an example of either some documentation or a code
> fragment that does not comport with that quote above from the standard?

As Keith pointed out, my standard example of a function that can screw
up errno in spite of success, open(), isn't actually defined in the C
standard (it's in POSIX), so it isn't strictly relevant after all...

-- 
"Erwin, have you seen the cat?" -- Mrs. Shrödinger

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

#103703

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>>>
>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> <snip>
>>>>>>   "The value of errno [...] is zero at program startup [...], but is
>>>>>>   never set to zero by any library function.  The value of errno may be
>>>>>>   set to nonzero by a library function call whether or not there is an
>>>>>>   error, provided the use of errno is not documented in the description
>>>>>>   of the function in this International Standard."
>>
>> <snip>
>>> As I remember the situation, the documentation required is a
>>> statement saying the function *doesn't* set errno unless there is an
>>> error.
>>
>> I must be rather dense to day because I just don't get what you are
>> saying.  Can you give an example of either some documentation or a code
>> fragment that does not comport with that quote above from the standard?
>
> As Keith pointed out, my standard example of a function that can screw
> up errno in spite of success, open(), isn't actually defined in the C
> standard (it's in POSIX), so it isn't strictly relevant after all...

So would fopen be an example of what you mean?  fopen is a standard
function and many implementations of fopen have it set errno.  The errno
setting is essential for good diagnostics in many systems.

-- 
Ben.

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

#103708

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>>
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>
>>>>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>>>>
>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> <snip>
>>>>>>>   "The value of errno [...] is zero at program startup [...], but is
>>>>>>>   never set to zero by any library function.  The value of errno may be
>>>>>>>   set to nonzero by a library function call whether or not there is an
>>>>>>>   error, provided the use of errno is not documented in the description
>>>>>>>   of the function in this International Standard."
>>>
>>> <snip>
>>>> As I remember the situation, the documentation required is a
>>>> statement saying the function *doesn't* set errno unless there is an
>>>> error.
>>>
>>> I must be rather dense to day because I just don't get what you are
>>> saying.  Can you give an example of either some documentation or a code
>>> fragment that does not comport with that quote above from the standard?
>>
>> As Keith pointed out, my standard example of a function that can screw
>> up errno in spite of success, open(), isn't actually defined in the C
>> standard (it's in POSIX), so it isn't strictly relevant after all...
>
> So would fopen be an example of what you mean?  fopen is a standard
> function and many implementations of fopen have it set errno.  The errno
> setting is essential for good diagnostics in many systems.

If it can set errno in spite of being successful, yes.
-- 
"Erwin, have you seen the cat?" -- Mrs. Shrödinger

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

#103710

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>>>
>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>>
>>>>>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>>>>>
>>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> <snip>
>>>>>>>>   "The value of errno [...] is zero at program startup [...], but is
>>>>>>>>   never set to zero by any library function.  The value of errno may be
>>>>>>>>   set to nonzero by a library function call whether or not there is an
>>>>>>>>   error, provided the use of errno is not documented in the description
>>>>>>>>   of the function in this International Standard."
>>>>
>>>> <snip>
>>>>> As I remember the situation, the documentation required is a
>>>>> statement saying the function *doesn't* set errno unless there is an
>>>>> error.
>>>>
>>>> I must be rather dense to day because I just don't get what you are
>>>> saying.  Can you give an example of either some documentation or a code
>>>> fragment that does not comport with that quote above from the standard?
>>>
>>> As Keith pointed out, my standard example of a function that can screw
>>> up errno in spite of success, open(), isn't actually defined in the C
>>> standard (it's in POSIX), so it isn't strictly relevant after all...
>>
>> So would fopen be an example of what you mean?  fopen is a standard
>> function and many implementations of fopen have it set errno.  The errno
>> setting is essential for good diagnostics in many systems.
>
> If it can set errno in spite of being successful, yes.

No library function may set errno to zero but I think you mean if fopen
can set errno to a non-zero in spite of being successful.  If that is
what you meant then let's assume that such a fopen exists.

Are you saying that an fopen like that (which, let's say, sets errno to
42 on success) is in some way wrong or problematic?

-- 
Ben.

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

#103728

On 02/11/2017 08:48 PM, Joe Pfeiffer wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
...
>>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> <snip>
>>>>>>>>   "The value of errno [...] is zero at program startup [...], but is
>>>>>>>>   never set to zero by any library function.  The value of errno may be
>>>>>>>>   set to nonzero by a library function call whether or not there is an
>>>>>>>>   error, provided the use of errno is not documented in the description
>>>>>>>>   of the function in this International Standard."
...
>> So would fopen be an example of what you mean?  fopen is a standard
>> function and many implementations of fopen have it set errno.  The errno
>> setting is essential for good diagnostics in many systems.
>
> If it can set errno in spite of being successful, yes.

It's easy to confirm that "... the use of errno is not documented in the 
description of" fopen(). Just look at (7.21.5.3). Therefore, "The value 
of errno may be set to nonzero by a ... call" to fopen() "whether or not 
there is an error".

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

#103729

W dniu niedziela, 12 lutego 2017 15:57:13 UTC+1 użytkownik James R. Kuyper napisał:
> On 02/11/2017 08:48 PM, Joe Pfeiffer wrote:
> > Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> ...
> >>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> >>>> <snip>
> >>>>>>>>   "The value of errno [...] is zero at program startup [...], but is
> >>>>>>>>   never set to zero by any library function.  The value of errno may be
> >>>>>>>>   set to nonzero by a library function call whether or not there is an
> >>>>>>>>   error, provided the use of errno is not documented in the description
> >>>>>>>>   of the function in this International Standard."
> ...
> >> So would fopen be an example of what you mean?  fopen is a standard
> >> function and many implementations of fopen have it set errno.  The errno
> >> setting is essential for good diagnostics in many systems.
> >
> > If it can set errno in spite of being successful, yes.
> 
> It's easy to confirm that "... the use of errno is not documented in the 
> description of" fopen(). Just look at (7.21.5.3). Therefore, "The value 
> of errno may be set to nonzero by a ... call" to fopen() "whether or not 
> there is an error".

if is not documented then i would assume that it is not 
touched

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

#103736

On Sunday, February 12, 2017 at 10:27:32 AM UTC-5, fir wrote:
...
> > >>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> > >>>> <snip>
> > >>>>>>>>   "The value of errno [...] is zero at program startup [...], but is
> > >>>>>>>>   never set to zero by any library function.  The value of errno may be
> > >>>>>>>>   set to nonzero by a library function call whether or not there is an
> > >>>>>>>>   error, provided the use of errno is not documented in the description
> > >>>>>>>>   of the function in this International Standard."
...
> if is not documented then i would assume that it is not 
> touched

That's probably why the section of the standard quoted above explicitly contradicts that assumption; otherwise, people might have thought that assumption was correct.

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

#103737

W dniu niedziela, 12 lutego 2017 17:44:28 UTC+1 użytkownik james...@verizon.net napisał:
> On Sunday, February 12, 2017 at 10:27:32 AM UTC-5, fir wrote:
> ...
> > > >>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> > > >>>> <snip>
> > > >>>>>>>>   "The value of errno [...] is zero at program startup [...], but is
> > > >>>>>>>>   never set to zero by any library function.  The value of errno may be
> > > >>>>>>>>   set to nonzero by a library function call whether or not there is an
> > > >>>>>>>>   error, provided the use of errno is not documented in the description
> > > >>>>>>>>   of the function in this International Standard."
> ...
> > if is not documented then i would assume that it is not 
> > touched
> 
> That's probably why the section of the standard quoted above explicitly contradicts that assumption; otherwise, people might have thought that assumption was correct.

i dislike reading standards - it was mentioned that they
use not clear language even for native englishmen - so it seems is badly written
despite if so (undocumented my change errno) is (or at least seems) silly to me

duh, i realized now that i forgot to check also for out of range in those examples of strtol /digint, must revrite again

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

#103741

On Sunday, February 12, 2017 at 5:16:00 PM UTC, fir wrote:
>
> i dislike reading standards - it was mentioned that they
> use not clear language even for native englishmen - so it 
> seems is badly written despite if so (undocumented my change errno) 
> is (or at least seems) silly to me
> 
> duh, i realized now that i forgot to check also for out of range 
> in those examples of strtol /digint, must revrite again
>
Standards are mainly aimed at those implementing compilers. It's
useful to have a copy for reference however. Like the dictionary,
99% of it you probably won't read, but still needs to be there.

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

#103747

On 12/02/2017 17:44, Malcolm McLean wrote:
> On Sunday, February 12, 2017 at 5:16:00 PM UTC, fir wrote:
>>
>> i dislike reading standards - it was mentioned that they
>> use not clear language even for native englishmen - so it
>> seems is badly written despite if so (undocumented my change errno)
>> is (or at least seems) silly to me
>>
>> duh, i realized now that i forgot to check also for out of range
>> in those examples of strtol /digint, must revrite again
>>
> Standards are mainly aimed at those implementing compilers.

They don't seem to be much use for that either, as I'm finding out. Not 
for C anyway.

The Standard is convoluted because the language is convoluted. They 
could have fixed that in the very early days, as they did with BCPL and 
B which didn't seem to last long, but C presumably must have been 
perfect because few of the troublesome details has been touched for decades!

(The type declaration system in particular is a masterpiece of design, 
as I'm finding out this afternoon. First, it is necessary to split all 
type declarations into two parts. The first part is the base type, and 
might contain, for example, some combination of these keywords:

    long int unsigned long

in any order. You can also have const, volatile etc anywhere in the 
sequence, and can repeat those as often as you like.

Also added to the mix are typedef, static, extern, which can also appear 
anywhere in that sequence (even though it's not part of the type, you 
can stick it in the middle of a type!). But you can't repeat those for 
some reason like you can with const.

That's Part I of the type. But there could be a Part II, which handles 
pointers, arrays and function params. Now, if a name is being declared, 
it is necessary for Part II to wrap itself around either side of the 
name. If there is no name, then Part II needs to pretend there /is/ a 
name to wrap itself around.

If several names are being declared, there it is possible for each to 
share the same Part I, but to have its own Part II.

And, just in case you've still got all your own hair, you have an 
example like this:

   int (*abc)[10];

This follows the recursive definition in the Standard beautifully. 
Except the implementation of it doesn't match the grammar: that "*" 
pointer somewhere has to find its way outside the brackets, and be 
applied to type represented here: int (abc)][10].

..... And this was the simplest and best way they could find of 
declaring a type in 1970.)

> It's
> useful to have a copy for reference however. Like the dictionary,
> 99% of it you probably won't read, but still needs to be there.

Yes, so that most compilers can ignore it! Apparently:

   int;

is illegal according to the grammar. Yes out of six compilers I tried, 
three don't consider that an error, while one just gives a warning.

-- 
Bartc

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

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

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

csiph-web