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

#103750

BartC <bc@freeuk.com> writes:
<snip>
> ...  but C presumably must have been
> perfect because few of the troublesome details has been touched for
> decades!

More accurately: C has been successful for decades because few of the
details have been touched.

<snip>
>   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,

It matches the grammar just fine (as you say).  If your implementation
does does not reflect the parse, that's not C's fault.  The * must be
inside the brackets or the type would an array type.

<snip>
-- 
Ben.

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

#103754

On 12/02/2017 18:56, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
> <snip>
>> ...  but C presumably must have been
>> perfect because few of the troublesome details has been touched for
>> decades!
>
> More accurately: C has been successful for decades because few of the
> details have been touched.
>
> <snip>
>>   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,
>
> It matches the grammar just fine (as you say).  If your implementation
> does does not reflect the parse, that's not C's fault.  The * must be
> inside the brackets or the type would an array type.

The type in the example can be expressed definitively in English as the 
left-to-right sequence:

   Pointer-Array-Int

If "*" is Pointer, abc is Int, and [10] is Array, then the declaration 
is arranged like this:

   (Pointer-Int)-Array

I can just about get the Array part to be moved in between the other 
two, but it's an ugly hack.

However, if I change abc to Pointer-Array-Int, "*" to "Deref", and 
"[10]" to index, then the declaration becomes:

  (Deref-Pointer-Array-Int)-Index

Now, Deref-Pointer cancel, leaving (Array-Int)Index. Array-Index cancel, 
leaving Int, the type you can get when you evaluate abc[i]. This is the 
famous Declaration-follows-use, the reason type-decls are as they are.

But clearly that is no use at all in parsing those type-decls. For a 
start, you don't know abc is Pointer-Array-Int, as that's what you're 
trying to establish! And you don't want to end up with Int, but with 
Pointer-Array-Int.


-- 
Bartc

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

#103766

BartC <bc@freeuk.com> writes:

> On 12/02/2017 18:56, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>> <snip>
>>> ...  but C presumably must have been
>>> perfect because few of the troublesome details has been touched for
>>> decades!
>>
>> More accurately: C has been successful for decades because few of the
>> details have been touched.
>>
>> <snip>
>>>   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,
>>
>> It matches the grammar just fine (as you say).  If your implementation
>> does does not reflect the parse, that's not C's fault.  The * must be
>> inside the brackets or the type would an array type.
>
> The type in the example can be expressed definitively in English as
> the left-to-right sequence:
>
>   Pointer-Array-Int

Sure.

> If "*" is Pointer, abc is Int, and [10] is Array, then the declaration
> is arranged like this:
>
>   (Pointer-Int)-Array

Eh?  Why would you rename "abc" as "Int"?  That looks like you are
trying to mess up the meaning.  If you rename int as Int, * as Pointer,
[10] as Array you get

  Int (Pointer-abc)Array

but how does that help?  You've just renamed things.

> I can just about get the Array part to be moved in between the other
> two, but it's an ugly hack.

Nothing needs to be "moved".  The declarator is parsed like you'd parse
an expression.  Write the reverse polish (or stack operations) you'd get
from the expressions

  (*abc)[10]  and  *abc[10]

and you'll see.  The first is abc deref 10 index and the second is abc
10 index deref.  Parse the declarators in the same way but change the
wording and you get the types in a linear form.

> However, if I change abc to Pointer-Array-Int, "*" to "Deref", and
> "[10]" to index, then the declaration becomes:
>
>  (Deref-Pointer-Array-Int)-Index
>
> Now, Deref-Pointer cancel, leaving (Array-Int)Index. Array-Index
> cancel, leaving Int, the type you can get when you evaluate
> abc[i]. This is the famous Declaration-follows-use, the reason
> type-decls are as they are.

This is even more odd than renaming "abc" "Int".  What is Deref doing in
a declaration?  I think you are trying to confuse yourself.

<snip>
-- 
Ben.

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

#103767

On 13/02/2017 00:16, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> I can just about get the Array part to be moved in between the other
>> two, but it's an ugly hack.
>
> Nothing needs to be "moved".  The declarator is parsed like you'd parse
> an expression.  Write the reverse polish (or stack operations) you'd get
> from the expressions
>
>   (*abc)[10]  and  *abc[10]
>
> and you'll see.  The first is abc deref 10 index and the second is abc
> 10 index deref.  Parse the declarators in the same way but change the
> wording and you get the types in a linear form.

Where does the 'int' go in 'abc deref 10 index'? If it replaces the 
'abc', then it gives me the type in the wrong order.

Presumably, then, the 'abc' represents 'pointer[10]int', and the ops are 
processed left-to-right, which will then yield a final int type. But as 
I pointed out a couple of posts ago, we're trying to /get/ 'pointer[10]int]!

So I have to try and construct the type by going through the motions of 
evaluating a term, and noting the *, [] and () ops, so that I can build 
it. What a palaver!

(And less efficient than I was hoping because I have to build the 
type-spec as a temporary data structure and process it again at the end.

The C syntax could have had one advantage, in being able to create a 
type 'bottom-up' very efficiently: start with int, add pointer to, add 
array, etc, but the parentheses mean it can be specified out-of-order 
rather than using a linear but still C-style syntax like this:

   int A*[10];       // array[10] of pointer to int
   int A[10]*;       // pointer to array[10] of int)

-- 
bartc

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

#103783

BartC <bc@freeuk.com> writes:

> On 13/02/2017 00:16, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> I can just about get the Array part to be moved in between the other
>>> two, but it's an ugly hack.
>>
>> Nothing needs to be "moved".  The declarator is parsed like you'd parse
>> an expression.  Write the reverse polish (or stack operations) you'd get
>> from the expressions
>>
>>   (*abc)[10]  and  *abc[10]
>>
>> and you'll see.  The first is abc deref 10 index and the second is abc
>> 10 index deref.  Parse the declarators in the same way but change the
>> wording and you get the types in a linear form.
>
> Where does the 'int' go in 'abc deref 10 index'? If it replaces the
> 'abc', then it gives me the type in the wrong order.

Why would you replace the name with anything (other than some internal
representation in a symbol table of course)?

A declaration is made up of two parts.  Declaration specifiers (the int
and so on) and a list of declarators (in fact, declarators with optional
initial values).  You have to treat each declarator separately from the
specifiers -- it defines the relationship the name has with the
specified type.  This, too, is expressed in the grammar.  In

  int a, *p, m[3], f(void), (*x)[10];

each of "a", "*p", "m[3]", "f(void)" and "(*x)[10]" describe the way the
name relates to "int".  You can read them as "a is", "p is a pointer
to", "m is any array of", "f is a function taking void and returning"
and "x is a pointer to an array of".  In this form, the "int" simply
goes at the end.

<snip>
-- 
Ben.

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

#103787

On 13/02/2017 10:44, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> Where does the 'int' go in 'abc deref 10 index'? If it replaces the
>> 'abc', then it gives me the type in the wrong order.
>
> Why would you replace the name with anything (other than some internal
> representation in a symbol table of course)?
>
> A declaration is made up of two parts.  Declaration specifiers (the int
> and so on) and a list of declarators (in fact, declarators with optional
> initial values).  You have to treat each declarator separately from the
> specifiers -- it defines the relationship the name has with the
> specified type.  This, too, is expressed in the grammar.  In
>
>   int a, *p, m[3], f(void), (*x)[10];
>
> each of "a", "*p", "m[3]", "f(void)" and "(*x)[10]" describe the way the
> name relates to "int".  You can read them as "a is", "p is a pointer
> to", "m is any array of", "f is a function taking void and returning"
> and "x is a pointer to an array of".  In this form, the "int" simply
> goes at the end.

I've sorted out dealing with 'int *abc[]' and 'int (*abc)[]'. But it 
needed two passes rather than one. To get it into the internal form I 
need anyway.

I take it that with a const pointer, the 'const' (one  or more of them) 
has to go immediately after the '*'?

So 'int const *p;', while legal, is misleading as the const belongs to 
the int. It has to be 'int * const p;'.


-- 
Bartc

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

#103807

BartC <bc@freeuk.com> writes:

> On 13/02/2017 10:44, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> Where does the 'int' go in 'abc deref 10 index'? If it replaces the
>>> 'abc', then it gives me the type in the wrong order.
>>
>> Why would you replace the name with anything (other than some internal
>> representation in a symbol table of course)?
>>
>> A declaration is made up of two parts.  Declaration specifiers (the int
>> and so on) and a list of declarators (in fact, declarators with optional
>> initial values).  You have to treat each declarator separately from the
>> specifiers -- it defines the relationship the name has with the
>> specified type.  This, too, is expressed in the grammar.  In
>>
>>   int a, *p, m[3], f(void), (*x)[10];
>>
>> each of "a", "*p", "m[3]", "f(void)" and "(*x)[10]" describe the way the
>> name relates to "int".  You can read them as "a is", "p is a pointer
>> to", "m is any array of", "f is a function taking void and returning"
>> and "x is a pointer to an array of".  In this form, the "int" simply
>> goes at the end.
>
> I've sorted out dealing with 'int *abc[]' and 'int (*abc)[]'. But it
> needed two passes rather than one. To get it into the internal form I
> need anyway.

If it works, it works.  But try not to suggest that because you did it
in some particular apparently messy way, it must be done that way.

> I take it that with a const pointer, the 'const' (one  or more of
> them) has to go immediately after the '*'?

Of course.

> So 'int const *p;', while legal, is misleading as the const belongs to
> the int. It has to be 'int * const p;'.

Well obviously you can write int const *p; if that is what you mean.  If
you mean int *const p;" then that is what you have to write.  What I
think you mean is that you find this distinction complicated.

-- 
Ben.

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

#103808

On 13/02/2017 14:37, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> I take it that with a const pointer, the 'const' (one  or more of
>> them) has to go immediately after the '*'?
>
> Of course.
>
>> So 'int const *p;', while legal, is misleading as the const belongs to
>> the int. It has to be 'int * const p;'.
>
> Well obviously you can write int const *p; if that is what you mean.  If
> you mean int *const p;" then that is what you have to write.  What I
> think you mean is that you find this distinction complicated.

It's not something I've thought about much before, and possibly others 
haven't either. (Not that I've ever used const, but I have to understand 
it in others' code.)

But with 'int', you can have 'const int' or 'int const'. When a pointer 
is const, it must be '* const'; it must always go after the '*'. Or, if 
you start with int const A, and need to turn that into a const pointer, 
the '*' must go between 'int' and 'const'. Also, if you start with 'int 
*const A' and remove the *, the 'const' needs to come out too.

This is not as obvious as it would be if 'const' was always applied on 
the left of what it was modifying. (And the same applies to volatile, 
restrict, and _Atomic.)

-- 
Bartc

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

#103753

BartC <bc@freeuk.com> writes:
> On 12/02/2017 17:44, Malcolm McLean wrote:
[...]
>> 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.

So four out of the six compilers you tried correctly diagosed the error
(a warning is a valid diagnostic for a syntax error or constraint
violation).  The other two probably are not conforming by default, but
such compilers commonly can be made conforming with appropriate options.

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

#103756

On 12/02/2017 19:15, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 12/02/2017 17:44, Malcolm McLean wrote:
> [...]
>>> 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.
>
> So four out of the six compilers you tried correctly diagosed the error

3 didn't say anything about it (no error or warning)
1 gave a warning
2 gave an error

That's one out of three that took it seriously.

It's not the most serious error, as adding that to a program and then 
having it ignored will do nothing. But that would mean you can write any 
old rubbish in program. It should be diagnosed because probably 
something is wrong.

-- 
bartc

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

#103757

BartC <bc@freeuk.com> writes:
> On 12/02/2017 19:15, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 12/02/2017 17:44, Malcolm McLean wrote:
>> [...]
>>>> 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.
>>
>> So four out of the six compilers you tried correctly diagosed the error
>
> 3 didn't say anything about it (no error or warning)
> 1 gave a warning
> 2 gave an error
>
> That's one out of three that took it seriously.

If a diagnostic is a non-fatal warning, then you say that the compiler
doesn't consider it an error.  I disagree; as has been said many times,
a non-fatal warning is a valid diagnostic for an error.

So 3 out of 6 correctly diagnosed the error, 2 fatally and 1
non-fatally.

The other three compilers are non-conforming *in the mode in which you
invoked them*.  Can you make them conforming with appropriate options?

> It's not the most serious error, as adding that to a program and then 
> having it ignored will do nothing. But that would mean you can write any 
> old rubbish in program. It should be diagnosed because probably 
> something is wrong.

If you invoke a compiler *in conforming mode*, you can't get away with
writting "any old rubbish".

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

#103762

On Sunday, February 12, 2017 at 12:32:34 PM UTC-6, Bart wrote:
> 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!

If one accepts the premises that the authors of the Standard made no effort
to forbid all of the unreasonable things a compiler might do, that actions
which are reasonable for some platforms and application fields may be
unreasonable in others, and that programmers should be entitled to expect
a compiler to behave reasonably even when the Standard doesn't require that
it do so, many parts of the Standard that are problematic today would have
been just fine when they were written.

The reason problems have emerged is that changes in compiler technology have
shifted the costs and benefits of supporting certain behaviors for which
the cost of support used to be zero, and consequently change what sorts of
behavioral guarantees would simply be "common sense" on various platforms.

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

If a particular implementation does not promise anything about how it places
objects with static duration, such a construct would be meaningless.  If,
however, an implementation happens to specify that static objects will be
allocated consecutively, being able to request that a compiler reserve space
without having to attach a name could be useful.  Some language designers
seem to be inclined toward forbidding constructs which would fit the grammar
but for which they see no particular usefulness, but my own taste would tend
toward leaving such things open except when doing so would cause some
actual problem.

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

#103641

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

No, if you set errno to 0 before calling strtol() you can rely in it not
being set to ERANGE unless there's an error.

N1570 7.5p3:

    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.

Since the use of errno *is* documented for strtol(), it can't set it to
nonzero unless there's an error.  (I suppose you could interpret that
wording in a way that allows to set errno even if it's successful, but
that's not a reasonable reading.)

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

#103658

Keith Thompson <kst-u@mib.org> 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...).
>
> No, if you set errno to 0 before calling strtol() you can rely in it not
> being set to ERANGE unless there's an error.
>
> N1570 7.5p3:
>
>     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.
>
> Since the use of errno *is* documented for strtol(), it can't set it to
> nonzero unless there's an error.  (I suppose you could interpret that
> wording in a way that allows to set errno even if it's successful, but
> that's not a reasonable reading.)

My recollection is that there are functions that do that (though I can't
provide an example that I remember clearly does it -- I want to say
open(), but would be very happy to be wrong).

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

#103665

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> No, if you set errno to 0 before calling strtol() you can rely in it not
>> being set to ERANGE unless there's an error.
>>
>> N1570 7.5p3:
>>
>>     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.
>>
>> Since the use of errno *is* documented for strtol(), it can't set it to
>> nonzero unless there's an error.  (I suppose you could interpret that
>> wording in a way that allows to set errno even if it's successful, but
>> that's not a reasonable reading.)
>
> My recollection is that there are functions that do that (though I can't
> provide an example that I remember clearly does it -- I want to say
> open(), but would be very happy to be wrong).

open() is not defined by the C standard (it's defined by POSIX), so it's
not 100% relevant.  But POSIX says:

    Upon successful completion, these functions shall open the
    file and return a non-negative integer representing the file
    descriptor. Otherwise, these functions shall return -1 and set
    errno to indicate the error. If -1 is returned, no files shall
    be created or modified.

The value returned by open() is sufficient to tell you whether it
succeeded or failed.  If it failed, errno tells you why.

In general, functions *can* set errno to some non-zero value even if
they succeed, as long as they still indicate that they succeeded.
That's because functions can call other functions, and the caller can
succeed even if the callee fails.

I think strtol() is a bit of a special case, since there are cases where
errno is the only direct way to tell whether it succeeded or failed.

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

#103659

Keith Thompson <kst-u@mib.org> 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...).
>
> No, if you set errno to 0 before calling strtol() you can rely in it not
> being set to ERANGE unless there's an error.
>
> N1570 7.5p3:
>
>     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.
>
> Since the use of errno *is* documented for strtol(), it can't set it to
> nonzero unless there's an error.  (I suppose you could interpret that
> wording in a way that allows to set errno even if it's successful, but
> that's not a reasonable reading.)

Ah, I note the Linux man page does specify that, at least on that
system, strtol()'s use of errno is sane.

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

#103651

On Fri, 10 Feb 2017 14:48:31 -0700, Joe Pfeiffer wrote:
> fir <profesor.fir@gmail.com> writes:
>> even if this strtol works ok there is also a doubt
>> how it shoud treat 'non pure' numbers (like "  0034aaa" or
>> "  035 aaa") should it rise an error or just return 34 - not fully
>> clear maybe (maybe clear maybe not it needs a bit of insight)
> 
> No, this is clearly stated in the page you cited:
> 
>     The function first discards as many whitespace characters as
>     necessary until the first non-whitespace character is found. Then,
>     starting from this character, takes as many characters as possible
>     that are valid following a syntax that depends on the base
>     parameter, and interprets them as a numerical value. Finally, a
>     pointer to the first character following the integer representation
>     in str is stored in the object pointed by endptr.
> 
> (and it goes on to define the syntax)

Well, sortof.  The results of strtol on a string like "  035 aaa"
are not fully specified, because (outside of the "C" locale) the
implementation is permitted to accept arbitrary locale-specific
forms for the subject sequence in addition to the forms specified
in the standard.

This means that portable programs cannot generally rely on strtol
for strings consisting of anything other than a single number to
be parsed.  This usually isn't a major problem, but it limits the
usefulness of the endptr argument for anything other than error
checking (e.g., can't reliably use strtol to split up a string).

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

#103660

Nick Bowler <nbowler@draconx.ca> writes:

> On Fri, 10 Feb 2017 14:48:31 -0700, Joe Pfeiffer wrote:
>> fir <profesor.fir@gmail.com> writes:
>>> even if this strtol works ok there is also a doubt
>>> how it shoud treat 'non pure' numbers (like "  0034aaa" or
>>> "  035 aaa") should it rise an error or just return 34 - not fully
>>> clear maybe (maybe clear maybe not it needs a bit of insight)
>> 
>> No, this is clearly stated in the page you cited:
>> 
>>     The function first discards as many whitespace characters as
>>     necessary until the first non-whitespace character is found. Then,
>>     starting from this character, takes as many characters as possible
>>     that are valid following a syntax that depends on the base
>>     parameter, and interprets them as a numerical value. Finally, a
>>     pointer to the first character following the integer representation
>>     in str is stored in the object pointed by endptr.
>> 
>> (and it goes on to define the syntax)
>
> Well, sortof.  The results of strtol on a string like "  035 aaa"
> are not fully specified, because (outside of the "C" locale) the
> implementation is permitted to accept arbitrary locale-specific
> forms for the subject sequence in addition to the forms specified
> in the standard.
>
> This means that portable programs cannot generally rely on strtol
> for strings consisting of anything other than a single number to
> be parsed.  This usually isn't a major problem, but it limits the
> usefulness of the endptr argument for anything other than error
> checking (e.g., can't reliably use strtol to split up a string).

Interesting -- I don't have much experience working with oddball
locales.  Could you give me an example of one where there would be a
weird result?

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

#104201

On 02/10/2017 04:48 PM, Joe Pfeiffer wrote:
> 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.

I don't know about ERRNO, you'll have to tell me what that is.

7.5p3 gives standard library functions permission to set errno to a 
non-zero value, whether or not there's any error, but it only gives that 
permission to functions where the standard does NOT specify how errno is 
used. 7.22.1.4p8 specifies how errno will be used by strtol(): errno 
will be set to ERANGE if correct value is outside of the range that can 
be represented as a long. Therefore, strtol doesn't have permission to 
set errno to any other value, for any other reason. If you set errno to 
0 immediately before the call to strtol(), and examine it's value 
immediately after the call, a value of 0 will reliably indicate that 
there was no range error.

[toc] | [prev] | [standalone]

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

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

csiph-web