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

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

More trouble with strtoul

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

Contents

  More trouble with strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 08:13 +0100
    Re: More trouble with strtoul Richard Heathfield <rjh@cpax.org.uk> - 2015-03-20 07:31 +0000
    Re: More trouble with strtoul Robert Wessel <robertwessel2@yahoo.com> - 2015-03-20 03:36 -0500
      Re: More trouble with strtoul Richard Heathfield <rjh@cpax.org.uk> - 2015-03-20 08:42 +0000
      Re: More trouble with strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 10:12 +0100
        Re: More trouble with strtoul Richard Heathfield <rjh@cpax.org.uk> - 2015-03-20 10:16 +0000
          Re: More trouble with strtoul: BUG in MSVC jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 11:49 +0100
        Re: More trouble with strtoul Robert Wessel <robertwessel2@yahoo.com> - 2015-03-20 05:54 -0500
        Re: More trouble with strtoul Barry Schwarz <schwarzb@dqel.com> - 2015-03-20 08:16 -0700
          Re: More trouble with strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 16:31 +0100
        Re: More trouble with strtoul Keith Thompson <kst-u@mib.org> - 2015-03-20 08:48 -0700
          Re: More trouble with strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 16:51 +0100
            Re: More trouble with strtoul Keith Thompson <kst-u@mib.org> - 2015-03-20 09:21 -0700
              Re: More trouble with strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 17:53 +0100
          Re: More trouble with strtoul glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-20 17:23 +0000
            Re: More trouble with strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 18:25 +0100
            Re: More trouble with strtoul Keith Thompson <kst-u@mib.org> - 2015-03-20 10:35 -0700
              Re: More trouble with strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-21 08:52 +1300
                Re: More trouble with strtoul Keith Thompson <kst-u@mib.org> - 2015-03-20 13:41 -0700
        Re: More trouble with strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-21 08:45 +1300
          Re: More trouble with strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-21 08:47 +1300
          Re: More trouble with strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 21:16 +0100
            Re: More trouble with strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-21 09:33 +1300
        Re: More trouble with strtoul Kaz Kylheku <kaz@kylheku.com> - 2015-03-20 20:05 +0000
        Re: More trouble with strtoul Melzzzzz <mel@zzzzz.com> - 2015-03-20 21:55 +0100
          Re: More trouble with strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-21 11:13 +1300
            Re: More trouble with strtoul Melzzzzz <mel@zzzzz.com> - 2015-03-20 23:41 +0100
              Re: More trouble with strtoul Keith Thompson <kst-u@mib.org> - 2015-03-20 16:27 -0700
                Re: More trouble with strtoul Melzzzzz <mel@zzzzz.com> - 2015-03-21 01:47 +0100
            Re: More trouble with strtoul Richard Heathfield <rjh@cpax.org.uk> - 2015-03-21 02:03 +0000
              Re: More trouble with strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-21 15:13 +1300
                Re: More trouble with strtoul Melzzzzz <mel@zzzzz.com> - 2015-03-21 03:22 +0100
                Re: More trouble with strtoul Richard Heathfield <rjh@cpax.org.uk> - 2015-03-21 02:25 +0000
    Re: More trouble with strtoul Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-03-20 10:11 +0100
      Re: More trouble with strtoul Robert Wessel <robertwessel2@yahoo.com> - 2015-03-20 06:13 -0500
    Re: More trouble with strtoul Keith Thompson <kst-u@mib.org> - 2015-03-20 09:05 -0700
      Re: More trouble with strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 17:35 +0100
        Re: More trouble with strtoul Keith Thompson <kst-u@mib.org> - 2015-03-20 10:56 -0700
          Re: More trouble with strtoul Robert Wessel <robertwessel2@yahoo.com> - 2015-03-20 15:31 -0500
    Re: More trouble with strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 18:28 +0100
      Re: More trouble with strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-21 09:01 +1300
        Re: More trouble with strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 21:12 +0100
          Re: More trouble with strtoul Kaz Kylheku <kaz@kylheku.com> - 2015-03-20 20:21 +0000
          Re: More trouble with strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-21 09:36 +1300
          Re: More trouble with strtoul Robert Wessel <robertwessel2@yahoo.com> - 2015-03-20 15:47 -0500
            Re: More trouble with strtoul Kaz Kylheku <kaz@kylheku.com> - 2015-03-20 21:20 +0000
              Re: More trouble with strtoul Robert Wessel <robertwessel2@yahoo.com> - 2015-03-21 00:24 -0500
            Re: More trouble with strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 23:04 +0100
        Re: More trouble with strtoul Keith Thompson <kst-u@mib.org> - 2015-03-20 13:41 -0700
    Re: More trouble with strtoul raltbos@xs4all.nl (Richard Bos) - 2015-03-21 22:49 +0000
      Re: More trouble with strtoul Keith Thompson <kst-u@mib.org> - 2015-03-21 16:17 -0700
        Re: More trouble with strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 12:01 -0700

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

#58467 — More trouble with strtoul

Consider this call

strtoul("-4294967296",NULL,0)

This is what lcc-win returns

strtoul("-4294967296",0) len=11 res=4294967295 (0xffffffff)
strtoul("-4294967297",0) len=11 res=4294967295 (0xffffffff)

This is what gcc returns

strtoul("-4294967296",0) len=11 res=1 (0x1)
strtoul("-4294967297",0) len=11 res=1 (0x1)

CONSTRAINTS:

sizeof(unsigned long) == 4 (32 bits)

Explanation for the lcc result:

ULONG_MAX is 4294967295 (0xffffffff), so 4294967296 is clearly an overflow!

In that case (an error) the software is supposed to return an error 
value (in this case ULONG_MAX).

I just do not understand WHERE that "1" result from gcc is coming from.

This is one of the last diferences I have with gcc. Can anybody here 
enlighten me as to where did I get it wrong? (If at all I am wrong and 
not gcc)

jacob

P.S. this can't be tested in a UNIX system since there sizeof(long)==8
in modern Unix systems

[toc] | [next] | [standalone]

#58469

On 20/03/15 07:13, jacob navia wrote:
> Consider this call
>
> strtoul("-4294967296",NULL,0)
>
> This is what lcc-win returns
>
> strtoul("-4294967296",0) len=11 res=4294967295 (0xffffffff)
> strtoul("-4294967297",0) len=11 res=4294967295 (0xffffffff)
>
> This is what gcc returns
>
> strtoul("-4294967296",0) len=11 res=1 (0x1)
> strtoul("-4294967297",0) len=11 res=1 (0x1)

Interesting. I would guess - and it *is* a guess - that the GNU folks 
are reasoning thusly:

A) 7.22.1.4(5) in my doc, maybe different ref in yours: "If the subject 
sequence begins with a minus sign, the value resulting from the 
conversion is negated (in the return type)" - so take the number sans 
minus, work out its value, then negate it;
B) 6.2.5(9): "A computation involving unsigned operands can never 
overflow, because a result that cannot be represented by the resulting 
unsigned integer type is reduced modulo the number that is one greater 
than the largest value that can be represented by the resulting type" - 
here, 'reduce' means 'fit into the range', so take the number and keep 
adding or subtracting (ULONG_MAX + 1.0) to or from it until it's in the 
range 0 to ULONG_MAX - that way, we don't have to worry about range 
errors for unsigned longs.

Did they reason like that? I don't know, but it would explain their 
result. Is their reasoning (and therefore their result) in line with the 
Standard? Yes, I think so. Is your result also in line with the 
Standard? Yes, I think so. Does that mean the Standard is flawed? 
Possibly, although it's not something I'd be terribly worried about.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#58473

On Fri, 20 Mar 2015 08:13:31 +0100, jacob navia
<jacob@jacob.remcomp.fr> wrote:

>Consider this call
>
>strtoul("-4294967296",NULL,0)
>
>This is what lcc-win returns
>
>strtoul("-4294967296",0) len=11 res=4294967295 (0xffffffff)
>strtoul("-4294967297",0) len=11 res=4294967295 (0xffffffff)
>
>This is what gcc returns
>
>strtoul("-4294967296",0) len=11 res=1 (0x1)
>strtoul("-4294967297",0) len=11 res=1 (0x1)
>
>CONSTRAINTS:
>
>sizeof(unsigned long) == 4 (32 bits)
>
>Explanation for the lcc result:
>
>ULONG_MAX is 4294967295 (0xffffffff), so 4294967296 is clearly an overflow!
>
>In that case (an error) the software is supposed to return an error 
>value (in this case ULONG_MAX).
>
>I just do not understand WHERE that "1" result from gcc is coming from.
>
>This is one of the last diferences I have with gcc. Can anybody here 
>enlighten me as to where did I get it wrong? (If at all I am wrong and 
>not gcc)
>
>jacob
>
>P.S. this can't be tested in a UNIX system since there sizeof(long)==8
>in modern Unix systems


Personally I can't see how returning 1 is allowed.  The second
sentence of 7.22.1.4(8) (below) seems pretty clear that an
out-of-range input must return ULONG_MAX (and set errno).


N1570 7.22.1.4(8):
"If no conversion could be performed, zero is returned. If the correct
value is outside the range of representable values, LONG_MIN,
LONG_MAX, LLONG_MIN, LLONG_MAX, ULONG_MAX, or ULLONG_MAX is returned
(according to the return type and sign of the value, if any), and the
value of the macro ERANGE is stored in errno."


The linux man page for strtoul is worded a bit differently, but I
still don't see this of range input allowing a return of 1


"The strtoul() function returns either the result of the conversion
or, if there was a leading minus sign, the negation of the result of
the conversion represented as an unsigned value, unless the original
(nonnegated) value would overflow; in the latter case, strtoul()
returns ULONG_MAX and sets errno to ERANGE.  Precisely the same holds
for strtoull() (with ULLONG_MAX instead of ULONG_MAX)."

But that actually leave the handling of negative numbers that don't
overflow before the negation somewhat ambiguous, and one of the
clarifying notes doesn't help at all:

"Negative values are considered valid input and are silently converted
to the equivalent unsigned long int value."

Which seems to imply that the number is not actually negated?


OTOH, MSVC does the same thing.  It returns 1 in both cases, but does
set errno to ERANGE (does the GCC version set ERRNO correctly?).

I wonder if both implementations are actually generating the
ULONG_MAX, and then negating that, without considering the overflow at
that point.

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

#58476

On 20/03/15 08:36, Robert Wessel wrote:

<snip>
> But that actually leave the handling of negative numbers that don't
> overflow before the negation somewhat ambiguous, and one of the
> clarifying notes doesn't help at all:
>
> "Negative values are considered valid input and are silently converted
> to the equivalent unsigned long int value."
>
> Which seems to imply that the number is not actually negated?
>
>
> OTOH, MSVC does the same thing.  It returns 1 in both cases, but does
> set errno to ERANGE (does the GCC version set ERRNO correctly?).
>
> I wonder if both implementations are actually generating the
> ULONG_MAX, and then negating that, without considering the overflow at
> that point.

Perhaps it's time to take this to comp.std.c - it may be that a DR is 
required.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#58478

Le 20/03/2015 09:36, Robert Wessel a écrit :
> does the GCC version set ERRNO correctly?

YES! THAT's the thing to test.

I copiled following program with gcc:

   1 #include <stdio.h>
   2 #include <math.h>
   3 #include <stdlib.h>
   4 #include <errno.h>
   5 int main(int argc,char *argv[])
   6 {
   7     char *end;
   8     char *s = "-2147483647";
   9     if (argc > 1)
  10         s = argv[1];
  11     errno = 0;
  12     unsigned long m = strtoul(s,&end,0);
  13     printf("%lu %lld",m,end-s);
  14     printf(" errno = %s\n",strerror(errno));
  15 }

and obtained

   1 1 11 errno = Result too large

Then, since I set errno to zero at line 11, that gcc is setting errno 
correctly meaning that this is an error, but not returning the error 
result, meaning it is negating something after the overflow.

Is this a bug in gcc?

Looks like but I can't really say this... If MSVC and gcc agree on this 
it doesn't look very favorably to me.

What do you think?

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

#58481

On 20/03/15 09:12, jacob navia wrote:
> Le 20/03/2015 09:36, Robert Wessel a écrit :
>> does the GCC version set ERRNO correctly?
>
> YES! THAT's the thing to test.

When you do, remember to test errno, not ERRNO :-)

>
> I copiled following program with gcc:
>
<snip>

>
> and obtained
>
>     1 1 11 errno = Result too large
>
> Then, since I set errno to zero at line 11, that gcc is setting errno
> correctly meaning that this is an error, but not returning the error
> result, meaning it is negating something after the overflow.
>
> Is this a bug in gcc?
>
> Looks like but I can't really say this... If MSVC and gcc agree on this
> it doesn't look very favorably to me.
>
> What do you think?

It's certainly not a bug in gcc itself, although it might be a bug in 
glibc. I am surprised by the result. I would expect exactly one of the 
following interpretations:

A) The "fail" interpretation: set errno to ERANGE and return ULONG_MAX 
(I think this is what you are doing, yes?)

B) The "pass" interpretation: don't set errno at all, and return the 
result reduced modulo (ULONG_MAX + 1).

I would *not* expect a mixture of the two, which is what glibc appears 
to be doing. I think either interpretation is at least defensible if not 
necessarily valid, but a mixture doesn't seem to me to make any sense.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#58483 — Re: More trouble with strtoul: BUG in MSVC

Le 20/03/2015 11:16, Richard Heathfield a écrit :
>> What do you think?
>
> It's certainly not a bug in gcc itself, although it might be a bug in
> glibc. I am surprised by the result. I would expect exactly one of the
> following interpretations:
>
> A) The "fail" interpretation: set errno to ERANGE and return ULONG_MAX
> (I think this is what you are doing, yes?)
>

Yes, of course. I think this is the correct answer, its a bug in gcc
that's all.

This is good news! I am done with strtoul.


> B) The "pass" interpretation: don't set errno at all, and return the
> result reduced modulo (ULONG_MAX + 1).
>
> I would *not* expect a mixture of the two, which is what glibc appears
> to be doing. I think either interpretation is at least defensible if not
> necessarily valid, but a mixture doesn't seem to me to make any sense.
>

Yes, this is obviously a problem in their stuff. Can't blame them. This 
is hellish difficult to get correctly done.

Phew!

DONE!

:-)

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

#58484

On Fri, 20 Mar 2015 10:12:15 +0100, jacob navia
<jacob@jacob.remcomp.fr> wrote:

>Le 20/03/2015 09:36, Robert Wessel a écrit :
>> does the GCC version set ERRNO correctly?
>
>YES! THAT's the thing to test.
>
>I copiled following program with gcc:
>
>   1 #include <stdio.h>
>   2 #include <math.h>
>   3 #include <stdlib.h>
>   4 #include <errno.h>
>   5 int main(int argc,char *argv[])
>   6 {
>   7     char *end;
>   8     char *s = "-2147483647";
>   9     if (argc > 1)
>  10         s = argv[1];
>  11     errno = 0;
>  12     unsigned long m = strtoul(s,&end,0);
>  13     printf("%lu %lld",m,end-s);
>  14     printf(" errno = %s\n",strerror(errno));
>  15 }
>
>and obtained
>
>   1 1 11 errno = Result too large
>
>Then, since I set errno to zero at line 11, that gcc is setting errno 
>correctly meaning that this is an error, but not returning the error 
>result, meaning it is negating something after the overflow.


Just to make sure that I didn't muck something up, I ran your program
on MSVC (slightly modified - no C99):


#include <stdio.h>
#include <math.h>
#include <stdlib.h>
#include <errno.h>
int main(int argc,char *argv[])
{
    char *end;
    char *s = "-2147483647";
    unsigned long m;
    if (argc > 1)
        s = argv[1];
    errno = 0;
    m = strtoul(s,&end,0);
    printf("%lu %lld",m,end-s);
    printf(" errno = %s\n",strerror(errno));
}



G:\wessel>test186 -4294967297
1 4294967307 errno = Result too large

G:\wessel>test186 -4294967296
1 4294967307 errno = Result too large


Same result.


>Is this a bug in gcc?
>
>Looks like but I can't really say this... If MSVC and gcc agree on this 
>it doesn't look very favorably to me.
>
>What do you think?


I think trying a few other compilers is in order.  Certainly I can't
see the GCC/MSVC result from what I read in the standard.

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

#58508

On Fri, 20 Mar 2015 10:12:15 +0100, jacob navia
<jacob@jacob.remcomp.fr> wrote:

> 13     printf("%lu %lld",m,end-s);

Just out of curiosity, why do you expect the difference of two char*
to be a long long int?

-- 
Remove del for email

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

#58509

Le 20/03/2015 16:16, Barry Schwarz a écrit :
> On Fri, 20 Mar 2015 10:12:15 +0100, jacob navia
> <jacob@jacob.remcomp.fr> wrote:
>
>> 13     printf("%lu %lld",m,end-s);
>
> Just out of curiosity, why do you expect the difference of two char*
> to be a long long int?
>
Because I am using 64 bit windows and pointers are 64 bit

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

#58510

jacob navia <jacob@jacob.remcomp.fr> writes:
> Le 20/03/2015 09:36, Robert Wessel a écrit :
>> does the GCC version set ERRNO correctly?
>
> YES! THAT's the thing to test.
>
> I copiled following program with gcc:
>
>   1 #include <stdio.h>
>   2 #include <math.h>
>   3 #include <stdlib.h>
>   4 #include <errno.h>
>   5 int main(int argc,char *argv[])
>   6 {
>   7     char *end;
>   8     char *s = "-2147483647";
>   9     if (argc > 1)
>  10         s = argv[1];
>  11     errno = 0;
>  12     unsigned long m = strtoul(s,&end,0);
>  13     printf("%lu %lld",m,end-s);
>  14     printf(" errno = %s\n",strerror(errno));
>  15 }
>
> and obtained
>
>   1 1 11 errno = Result too large

Is that the exact code you ran?  I get several warnings when I compile
it.  On line 13, "%lld" is the incorrect format for end-s (unless
ptrdiff_t happens to be long long). I suggest:

    printf("%lu %d", m, (int)end-s);

> Then, since I set errno to zero at line 11, that gcc is setting errno
> correctly meaning that this is an error, but not returning the error
> result, meaning it is negating something after the overflow.

On line 14, strerror is undeclared; you need #include <string.h>.  Also,
the printf call on line 13 is likely to clobber the value of errno, so
depending on the implementation the output from line 14 may be
meaningless.

> Is this a bug in gcc?

If it's a bug, it's not in gcc.  All gcc does is generate a call to the
strtoul function.  The implementation of the function is in the library.
What implementation are you using?  On most Linux systems, strtoul is
implemented by glic (GNU libc).  If you happen to be using Cygwin, the
library implementation is "newlib", if I recall correctly.

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

#58511

Le 20/03/2015 16:48, Keith Thompson a écrit :
> Is that the exact code you ran?  I get several warnings when I compile
> it.  On line 13, "%lld" is the incorrect format for end-s (unless
> ptrdiff_t happens to be long long). I suggest:
>
>      printf("%lu %d", m, (int)end-s);
I am running 64 bit version of gcc under 64 bit windows ptrdiff_t is 64 bit

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

#58513

jacob navia <jacob@jacob.remcomp.fr> writes:
> Le 20/03/2015 16:48, Keith Thompson a écrit :
>> Is that the exact code you ran?  I get several warnings when I compile
>> it.  On line 13, "%lld" is the incorrect format for end-s (unless
>> ptrdiff_t happens to be long long). I suggest:
>>
>>      printf("%lu %d", m, (int)end-s);
> I am running 64 bit version of gcc under 64 bit windows ptrdiff_t is 64 bit

Yes, I understand that it happens to work on your system, but it's not
portable, and you might as well write it portably.

In fact, there's a specific format for type ptrdiff_t:

    printf("%lu %td", m, end-s);

Any comment on the other errors I pointed out?

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

#58517

Le 20/03/2015 17:21, Keith Thompson a écrit :
> Any comment on the other errors I pointed out?

If I save the result of errno just after the call and print it later 
that doesn't change anything

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

#58519

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

(snip on printing difference of pointers)

> Is that the exact code you ran?  I get several warnings when I compile
> it.  On line 13, "%lld" is the incorrect format for end-s (unless
> ptrdiff_t happens to be long long). I suggest:
 
>    printf("%lu %d", m, (int)end-s);

I would have done (int)(end-s). 

-- glen

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

#58521

Le 20/03/2015 18:23, glen herrmannsfeldt a écrit :
> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip on printing difference of pointers)
>
>> Is that the exact code you ran?  I get several warnings when I compile
>> it.  On line 13, "%lld" is the incorrect format for end-s (unless
>> ptrdiff_t happens to be long long). I suggest:
>
>>     printf("%lu %d", m, (int)end-s);
>
> I would have done (int)(end-s).
>
> -- glen
>

I am running in 64 bit windows. ptrdiff_t is a 64 bit number

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

#58523

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip on printing difference of pointers)
>
>> Is that the exact code you ran?  I get several warnings when I compile
>> it.  On line 13, "%lld" is the incorrect format for end-s (unless
>> ptrdiff_t happens to be long long). I suggest:
>  
>>    printf("%lu %d", m, (int)end-s);
>
> I would have done (int)(end-s). 

You're right, of course.  In fact I did that; I should have
copy-and-pasted my working code rather than re-typing it.

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

#58532

Keith Thompson wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> wrote:
>>
>> (snip on printing difference of pointers)
>>
>>> Is that the exact code you ran?  I get several warnings when I compile
>>> it.  On line 13, "%lld" is the incorrect format for end-s (unless
>>> ptrdiff_t happens to be long long). I suggest:
>>
>>>     printf("%lu %d", m, (int)end-s);
>>
>> I would have done (int)(end-s).
>
> You're right, of course.  In fact I did that; I should have
> copy-and-pasted my working code rather than re-typing it.

Why would you do that when, as you pointed out else-thread, there is %td?

-- 
Ian Collins

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

#58541

Ian Collins <ian-news@hotmail.com> writes:
> Keith Thompson wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> wrote:
>>>
>>> (snip on printing difference of pointers)
>>>
>>>> Is that the exact code you ran?  I get several warnings when I compile
>>>> it.  On line 13, "%lld" is the incorrect format for end-s (unless
>>>> ptrdiff_t happens to be long long). I suggest:
>>>
>>>>     printf("%lu %d", m, (int)end-s);
>>>
>>> I would have done (int)(end-s).
>>
>> You're right, of course.  In fact I did that; I should have
>> copy-and-pasted my working code rather than re-typing it.
>
> Why would you do that when, as you pointed out else-thread, there is %td?

Because I hadn't yet remembered the existence of %td when I posted that
first followup.

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

#58530

jacob navia wrote:
> Le 20/03/2015 09:36, Robert Wessel a écrit :
>> does the GCC version set ERRNO correctly?
>
> YES! THAT's the thing to test.
>
> I copiled following program with gcc:
>
>     1 #include <stdio.h>
>     2 #include <math.h>
>     3 #include <stdlib.h>
>     4 #include <errno.h>
>     5 int main(int argc,char *argv[])
>     6 {
>     7     char *end;
>     8     char *s = "-2147483647";
>     9     if (argc > 1)
>    10         s = argv[1];
>    11     errno = 0;
>    12     unsigned long m = strtoul(s,&end,0);
>    13     printf("%lu %lld",m,end-s);
>    14     printf(" errno = %s\n",strerror(errno));
>    15 }
>
> and obtained
>
>     1 1 11 errno = Result too large
>
> Then, since I set errno to zero at line 11, that gcc is setting errno
> correctly meaning that this is an error, but not returning the error
> result, meaning it is negating something after the overflow.
>
> Is this a bug in gcc?

Platform library issue more like.

On Linux and Solaris, compiling (with the missing header added) with:

gcc -std=c99 -pedantic -Wall x.c -m64; ./a.out
-2147483647 11 errno = Success

gcc -std=c99 -pedantic -Wall x.c -m32; ./a.out
-2147483647 11 errno = Success

-- 
Ian Collins

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

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

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

csiph-web