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

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

on an analogy for verifying whether another digit fits (into an unsigned type)

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

Contents

  on an analogy for verifying whether another digit fits (into an unsigned type) Meredith Montgomery <mmontgomery@levado.to> - 2022-01-15 23:27 -0300
    Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-16 18:44 +0000
      Re: on an analogy for verifying whether another digit fits (into an unsigned type) Meredith Montgomery <mmontgomery@levado.to> - 2022-01-17 09:48 -0300
        Re: on an analogy for verifying whether another digit fits (into an unsigned type) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-17 17:27 +0000
          Re: on an analogy for verifying whether another digit fits (into an unsigned type) scott@slp53.sl.home (Scott Lurndal) - 2022-01-17 18:06 +0000
            Re: on an analogy for verifying whether another digit fits (into an unsigned type) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-17 20:59 +0000
              Re: on an analogy for verifying whether another digit fits (into an unsigned type) scott@slp53.sl.home (Scott Lurndal) - 2022-01-18 01:01 +0000
          Re: on an analogy for verifying whether another digit fits (into an unsigned type) Meredith Montgomery <mmontgomery@levado.to> - 2022-01-28 22:15 -0300
            Re: on an analogy for verifying whether another digit fits (into an unsigned type) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-29 02:36 +0000
              Re: on an analogy for verifying whether another digit fits (into an unsigned type) Meredith Montgomery <mmontgomery@levado.to> - 2022-01-30 09:12 -0300
                Re: on an analogy for verifying whether another digit fits (into an unsigned type) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-30 15:13 +0000
    Re: on an analogy for verifying whether another digit fits (into an unsigned type) Öö Tiib <ootiib@hot.ee> - 2022-01-16 12:15 -0800
      Re: on an analogy for verifying whether another digit fits (into an unsigned type) Meredith Montgomery <mmontgomery@levado.to> - 2022-01-17 09:53 -0300
        Re: on an analogy for verifying whether another digit fits (into an unsigned type) Meredith Montgomery <mmontgomery@levado.to> - 2022-01-17 10:12 -0300
    Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-19 08:52 +0100
      Re: on an analogy for verifying whether another digit fits (into an unsigned type) Öö Tiib <ootiib@hot.ee> - 2022-01-19 06:08 -0800
        Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-19 16:31 +0100
          Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-19 18:02 +0100
            Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-19 18:27 +0000
              Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-19 19:44 +0100
                Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-20 08:08 +0100
                  Re: on an analogy for verifying whether another digit fits (into an unsigned type) Öö Tiib <ootiib@hot.ee> - 2022-01-20 09:47 -0800
              Re: on an analogy for verifying whether another digit fits (into an unsigned type) scott@slp53.sl.home (Scott Lurndal) - 2022-01-19 18:46 +0000
                Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-19 20:59 +0000
                  Re: on an analogy for verifying whether another digit fits (into an unsigned type) scott@slp53.sl.home (Scott Lurndal) - 2022-01-19 21:12 +0000
                    Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-19 22:25 +0000
                      Re: on an analogy for verifying whether another digit fits (into an unsigned type) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-20 03:49 +0000
                        Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-20 10:05 +0000
                          Re: on an analogy for verifying whether another digit fits (into an unsigned type) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-20 17:02 +0000
                            Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-20 19:20 +0000
                              Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-20 19:31 +0000
                  Re: on an analogy for verifying whether another digit fits (into an unsigned type) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-23 14:26 -0800
                    Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-24 00:13 +0000
                      Re: on an analogy for verifying whether another digit fits (into an unsigned type) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-01-24 00:38 +0000
                        Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-24 01:09 +0000
                      Re: on an analogy for verifying whether another digit fits (into an unsigned type) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-24 01:15 +0000
                        Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-24 11:21 +0000
                          Re: on an analogy for verifying whether another digit fits (into an unsigned type) scott@slp53.sl.home (Scott Lurndal) - 2022-01-24 15:54 +0000
                            Re: on an analogy for verifying whether another digit fits (into an unsigned type) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-24 13:08 -0800
                              Re: on an analogy for verifying whether another digit fits (into an unsigned type) scott@slp53.sl.home (Scott Lurndal) - 2022-01-24 22:51 +0000
                          Re: on an analogy for verifying whether another digit fits (into an unsigned type) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-24 15:57 +0000
                            Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-24 16:52 +0000
                              Re: on an analogy for verifying whether another digit fits (into an unsigned type) Öö Tiib <ootiib@hot.ee> - 2022-01-24 10:17 -0800
                                Re: on an analogy for verifying whether another digit fits (into an unsigned type) scott@slp53.sl.home (Scott Lurndal) - 2022-01-24 18:23 +0000
                          Re: on an analogy for verifying whether another digit fits (into an unsigned type) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-24 13:15 -0800
                        Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-24 11:51 +0000
                      Re: on an analogy for verifying whether another digit fits (into an unsigned type) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-23 17:38 -0800
                        Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-24 11:22 +0000
                      Re: on an analogy for verifying whether another digit fits (into an unsigned type) scott@slp53.sl.home (Scott Lurndal) - 2022-01-24 15:51 +0000
                        Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-24 22:03 +0000
                          Re: on an analogy for verifying whether another digit fits (into an unsigned type) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-24 15:33 -0800
                            Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-25 00:09 +0000
                              Re: on an analogy for verifying whether another digit fits (into an unsigned type) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-24 21:14 -0800
                              Re: on an analogy for verifying whether another digit fits (into an unsigned type) Manfred <invalid@invalid.add> - 2022-01-26 21:01 +0100
                                Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bart <bc@freeuk.com> - 2022-01-26 20:53 +0000
                                  Re: on an analogy for verifying whether another digit fits (into an unsigned type) Manfred <noname@add.invalid> - 2022-01-27 03:42 +0100
    Re: on an analogy for verifying whether another digit fits (into an unsigned type) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-20 19:24 -0800
      Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-21 08:07 +0100
        Re: on an analogy for verifying whether another digit fits (into an unsigned type) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-21 06:01 -0800
          Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-21 17:59 +0100
            Re: on an analogy for verifying whether another digit fits (into an unsigned type) scott@slp53.sl.home (Scott Lurndal) - 2022-01-21 17:41 +0000
              Re: on an analogy for verifying whether another digit fits (into an unsigned type) Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-21 19:26 +0100
            Re: on an analogy for verifying whether another digit fits (into an unsigned type) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-21 17:12 -0800
      Re: on an analogy for verifying whether another digit fits (into an unsigned type) Meredith Montgomery <mmontgomery@levado.to> - 2022-01-28 22:25 -0300

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

#164582

Bart <bc@freeuk.com> writes:

> On 24/01/2022 01:15, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:

>>>    #define strtoull _strtoui64
>> Which, of course, means "unless I don't use strtoull".
>
> It's better not to. If I were to post code anywhere that used it, then
> at least some people trying it wouldn't be able to build it. And I'm
> not having /my/ code full of those implementation-specific conditional
> blocks that I despise.

What level of broken are you prepared to work around?  If I produce a C
implementation, based, say, on tcc, which fails to link strlen, would
you feel you have to work round that?  I don't think so.  You'd tell me
that my implementation is broken.

Conditional blocks are ugly, but writing potentially buggy code just to
avoid a standard library function is also hardly ideal.

> For the same reason, I tend not to write shared code that uses '$' in
> identifiers, because tcc doesn't support it.

Not even in the same ball-park.  No C implementation is required to
support $ in identifiers, but every conforming C implementation is
required to support strtoull.

>> If your code must work with non-standard C implementations, then there
>> might well be a whole raft of things you should avoid.  But since you
>> seem to use C a lot, wouldn't it be better either to try to fix your tcc
>> installation or to simply uninstall it?
>
> What do you mean by fix? Fixing my tcc doesn't help people compiling
> my code unless everybody fixes theirs too.

I didn't realise anyone else compiled your code.  I thought your C
projects were personal ones.  You could just say that a conforming C
compiler is required.  Would that really disenfranchise a large
user-base?

-- 
Ben.

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

#164585

On 24/01/2022 15:57, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 24/01/2022 01:15, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
> 
>>>>     #define strtoull _strtoui64
>>> Which, of course, means "unless I don't use strtoull".
>>
>> It's better not to. If I were to post code anywhere that used it, then
>> at least some people trying it wouldn't be able to build it. And I'm
>> not having /my/ code full of those implementation-specific conditional
>> blocks that I despise.
> 
> What level of broken are you prepared to work around?  If I produce a C
> implementation, based, say, on tcc, which fails to link strlen, would
> you feel you have to work round that?  I don't think so.  You'd tell me
> that my implementation is broken.


/That's/ not in the same ballpark! Without strlen, very few C programs 
would build. Any problems would quickly be found.

With strtoull, people can spend decades coding C and not need to use it 
or encounter it. Apparently no one has with tcc on Windows, or they 
couldn't find where to file a bug report.


> Conditional blocks are ugly, but writing potentially buggy code just to
> avoid a standard library function is also hardly ideal.
> 
>> For the same reason, I tend not to write shared code that uses '$' in
>> identifiers, because tcc doesn't support it.
> 
> Not even in the same ball-park.  No C implementation is required to
> support $ in identifiers, but every conforming C implementation is
> required to support strtoull.

Yet most do support '$'; why bother to allow it, unless they expect 
people to use it?

The exceptions I've come across are tcc, and lccwin which has limited 
support (I think only as a starter).

I used '$' extensively in generated C (when it occurs in the source 
language, and is used as the 'dot' in qualified names). But because tcc 
is such an important target for me, I had to work around it.

> 
>>> If your code must work with non-standard C implementations, then there
>>> might well be a whole raft of things you should avoid.  But since you
>>> seem to use C a lot, wouldn't it be better either to try to fix your tcc
>>> installation or to simply uninstall it?
>>
>> What do you mean by fix? Fixing my tcc doesn't help people compiling
>> my code unless everybody fixes theirs too.
> 
> I didn't realise anyone else compiled your code.

A lot of my C code is posted on forums or linked to. If it's not to be 
compiled as C, then there's no point in using C, as my own language is 
much sweeter.

So if I go to that trouble, it has to compile. But I only test with tcc, 
gcc and bcc. Usually if it passes bcc, it will work with anything, other 
than tcc + $ symbols.

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

#164588

On Monday, 24 January 2022 at 18:52:57 UTC+2, Bart wrote:
> On 24/01/2022 15:57, Ben Bacarisse wrote: 
> > Bart <b...@freeuk.com> writes: 
> > 
> >> For the same reason, I tend not to write shared code that uses '$' in 
> >> identifiers, because tcc doesn't support it. 
> > 
> > Not even in the same ball-park. No C implementation is required to 
> > support $ in identifiers, but every conforming C implementation is 
> > required to support strtoull.
> 
> Yet most do support '$'; why bother to allow it, unless they expect 
> people to use it? 

They expect that people may need to use it. ABI on several platforms
allows '$'  in symbol names and there might arise need to link 
C code to library or shared object that contains such name.  The
implementer tries to be helpful by allowing what ABI allows and 
what can not otherwise contradict with C syntax. It does not mean
that one  should start to use  '$' instead of 'S' to look cool or 
something.

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

#164589

=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> writes:
>On Monday, 24 January 2022 at 18:52:57 UTC+2, Bart wrote:
>> On 24/01/2022 15:57, Ben Bacarisse wrote: 
>> > Bart <b...@freeuk.com> writes: 
>> > 
>> >> For the same reason, I tend not to write shared code that uses '$' in 
>> >> identifiers, because tcc doesn't support it. 
>> > 
>> > Not even in the same ball-park. No C implementation is required to 
>> > support $ in identifiers, but every conforming C implementation is 
>> > required to support strtoull.
>> 
>> Yet most do support '$'; why bother to allow it, unless they expect 
>> people to use it? 
>
>They expect that people may need to use it. ABI on several platforms
>allows '$'  in symbol names and there might arise need to link 
>C code to library or shared object that contains such name.  The
>implementer tries to be helpful by allowing what ABI allows and 
>what can not otherwise contradict with C syntax. It does not mean
>that one  should start to use  '$' instead of 'S' to look cool or 
>something.

C on VMS, for example, required '$' in identifiers for the system
services (library functions, system calls) such as $QIOW or $GETJPI et alia.

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

#164593

Bart <bc@freeuk.com> writes:
> On 24/01/2022 01:15, Ben Bacarisse wrote:
[...]
>> Which, of course, means "unless I don't use strtoull".
>
> It's better not to. If I were to post code anywhere that used it, then
> at least some people trying it wouldn't be able to build it. And I'm
> not having /my/ code full of those implementation-specific conditional 
> blocks that I despise.
>
> For the same reason, I tend not to write shared code that uses '$' in
> identifiers, because tcc doesn't support it.

Again, both strtoll and strtoull have been standard since ISO C 1999.
I remember when it wasn't safe to assume C99 support for portable
code, but I don't get the impression that that's the case anymore.
Workarounds might still be needed, but I suggest it's not worth
worrying about too much.

(Bart knows that it's the library, not the tcc compiler, that supports
or doesn't support strtoull.  I will not argue with him about that.  And
as I recall we recently had a discussion indicating that there are
multiple versions of msvcrt.dll.)

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#164577

On 24/01/2022 01:15, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 23/01/2022 22:26, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 19/01/2022 18:46, Scott Lurndal wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>>> On 19/01/2022 17:02, Bonita Montero wrote:
>>>>>> Complicated. I used the simpler **C** code below. It's runtime was 10%
>>>>>> slower than the C++ (that is, elapsed time of the 10,000 outer loop for
>>>>>> both).
>>>>> I just use strtoll.  Why reinvent the wheel?
>>>>
>>>> It needs to be stroull() for this purpose, which is more elusive (gcc
>>>> has it on Windows, but the two other compilers I have don't),
>>> gcc does not provide strtoll() or strtoull().  Both are provided by the
>>> library, not by the compiler.  (And both were introduced in C99, so I'd
>>> be at least mildly surprised by an implementation that provides one
>>> but not the other.)
>>> I know you're tired of people pointing out that the compiler (gcc
>>> in this case) does not provide library functions.  The solution is
>>> for you to stop making that mistake.  Or should I assume you enjoy
>>> these arguments?
>>
>> gcc/tdm compiles programs using strtoull.
>>
>> bcc/tcc fail with a link error,
> 
> My tcc-based C installation handles it fine.  That's because, as you
> must know, it's not a compiler issue.
> 
>> unless I include this line:
>>
>>    #define strtoull _strtoui64
> 
> Which, of course, means "unless I don't use strtoull".
> 
>> but then gcc will complain about it.
>>
>> Actually why that is the case, I don't know, don't care, and probably
>> no else cares who just installs a 'bundle' without wanting to trace
>> and check the provenance of each library function that it comes with.
> 
> I'd hope it's rare to not want to know what's going on.

I know what's going on here; but I can't do anything about it.

Inside my tcc's stdlib.h is this:

   unsigned long long  __cdecl strtoull(const char* __restrict__, char** 
__restrict__, int);

Tha's identical to that from gcc/tdm's stdlib.h, but minus a 
__MINGW_EXTENSION macro at the start.

However my gcc/tdm manages to associate that with an actual function 
somewhere called 'strtoull'; tcc won't be able to do that if it only 
makes use of msvcrt.dll.

Clearly no one ever tested strtoull on Windows tcc; neither did I on my 
bcc; I copied the strtoull declaration from lccwin's stdlib.h; that one 
uses its own implementation of the function.

(If I change tcc's stdlib to use _strtoui64 and add that define, then it 
will work. But so what? I'm only changing my personal copy.)

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

#164564

Bart <bc@freeuk.com> writes:
> On 23/01/2022 22:26, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 19/01/2022 18:46, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 19/01/2022 17:02, Bonita Montero wrote:
>>>>> Complicated. I used the simpler **C** code below. It's runtime was 10%
>>>>> slower than the C++ (that is, elapsed time of the 10,000 outer loop for
>>>>> both).
>>>> I just use strtoll.  Why reinvent the wheel?
>>>
>>> It needs to be stroull() for this purpose, which is more elusive (gcc
>>> has it on Windows, but the two other compilers I have don't),
>> gcc does not provide strtoll() or strtoull().  Both are provided by
>> the
>> library, not by the compiler.  (And both were introduced in C99, so I'd
>> be at least mildly surprised by an implementation that provides one
>> but not the other.)
>> I know you're tired of people pointing out that the compiler (gcc
>> in this case) does not provide library functions.  The solution is
>> for you to stop making that mistake.  Or should I assume you enjoy
>> these arguments?
>
> gcc/tdm compiles programs using strtoull.
>
> bcc/tcc fail with a link error, unless I include this line:
>
>   #define strtoull _strtoui64
>
> but then gcc will complain about it.
>
> Actually why that is the case, I don't know, don't care, and probably
> no else cares who just installs a 'bundle' without wanting to trace
> and check the provenance of each library function that it comes with.
>
> The above is enough for me to think twice about using strtoull in a project.

It's obvious that you just enjoy the arguments that result when you
pretend to misunderstand the difference between a compiler and an
implementation and are not interested in helping anyone else understand
it.  I'll try to adjust my future responses accordingly.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#164576

On 24/01/2022 01:38, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:

> It's obvious that you just enjoy the arguments that result when you
> pretend to misunderstand the difference between a compiler and an
> implementation and are not interested in helping anyone else understand
> it.  I'll try to adjust my future responses accordingly.

It's not me bringing this up each time. It's you.

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

#164580

Bart <bc@freeuk.com> writes:
>On 23/01/2022 22:26, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 19/01/2022 18:46, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 19/01/2022 17:02, Bonita Montero wrote:
>>>>> Complicated. I used the simpler **C** code below. It's runtime was 10%
>>>>> slower than the C++ (that is, elapsed time of the 10,000 outer loop for
>>>>> both).
>>>> I just use strtoll.  Why reinvent the wheel?
>>>
>>> It needs to be stroull() for this purpose, which is more elusive (gcc
>>> has it on Windows, but the two other compilers I have don't),
>> 
>> gcc does not provide strtoll() or strtoull().  Both are provided by the
>> library, not by the compiler.  (And both were introduced in C99, so I'd
>> be at least mildly surprised by an implementation that provides one
>> but not the other.)
>> 
>> I know you're tired of people pointing out that the compiler (gcc
>> in this case) does not provide library functions.  The solution is
>> for you to stop making that mistake.  Or should I assume you enjoy
>> these arguments?
>
>gcc/tdm compiles programs using strtoull.
>
>bcc/tcc fail with a link error, unless I include this line:

Then they are POS compilers, or you're using them incorrectly,
such as forgetting to include <stdlib.h>.

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

#164596

On 24/01/2022 15:51, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 23/01/2022 22:26, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 19/01/2022 18:46, Scott Lurndal wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>>> On 19/01/2022 17:02, Bonita Montero wrote:
>>>>>> Complicated. I used the simpler **C** code below. It's runtime was 10%
>>>>>> slower than the C++ (that is, elapsed time of the 10,000 outer loop for
>>>>>> both).
>>>>> I just use strtoll.  Why reinvent the wheel?
>>>>
>>>> It needs to be stroull() for this purpose, which is more elusive (gcc
>>>> has it on Windows, but the two other compilers I have don't),
>>>
>>> gcc does not provide strtoll() or strtoull().  Both are provided by the
>>> library, not by the compiler.  (And both were introduced in C99, so I'd
>>> be at least mildly surprised by an implementation that provides one
>>> but not the other.)
>>>
>>> I know you're tired of people pointing out that the compiler (gcc
>>> in this case) does not provide library functions.  The solution is
>>> for you to stop making that mistake.  Or should I assume you enjoy
>>> these arguments?
>>
>> gcc/tdm compiles programs using strtoull.
>>
>> bcc/tcc fail with a link error, unless I include this line:
> 
> Then they are POS compilers, or you're using them incorrectly,
> such as forgetting to include <stdlib.h>.

I said it's a link error. They both depend on the msvcrt.dll library for 
standard C functions, and strtoull is not defined in that library. (It 
is defined inside ucrtbase.dll, but then that's missing stuff like printf.)

As certain people are so fond of reminding me, the library is a 
completely different entity from the compiler, so it is apparently not a 
compiler problem as both provide a proper API entry for that function.

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

#164599

Bart <bc@freeuk.com> writes:
> On 24/01/2022 15:51, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
[...]
>>> bcc/tcc fail with a link error, unless I include this line:
>> Then they are POS compilers, or you're using them incorrectly,
>> such as forgetting to include <stdlib.h>.
>
> I said it's a link error. They both depend on the msvcrt.dll library
> for standard C functions, and strtoull is not defined in that
> library. (It is defined inside ucrtbase.dll, but then that's missing
> stuff like printf.)

An aside: I have three different versions of msvcrt.dll on my Windows
system.  None of them appear to support strtoll or strtoull.

> As certain people are so fond of reminding me, the library is a
> completely different entity from the compiler, so it is apparently not
> a compiler problem as both provide a proper API entry for that
> function.

I think that may be the first time you've actually acknowledged that.

However, it's not necessary for the compiler itself to have a
"proper API entry" for a library function, or to know anything
about it.  Using strtol as an example (since it's supported all the
way back to C89/C90), the compiler knows how to call it because it
sees the declaration in <stdlib.h>.  (For a C90 compiler, if you
don't include the header, the compiler will assume an incorrect
declaration for strtol when it sees a call.)  <stdlib.h>, which provides
the declaration, and whatever file(?) provides the code that actually
implements the function, are typically provided by the same package (or
at least they must be kept closely in synch).

A call to a standard library function is just a function call,
unless the implementation chooses to do something fancy.

Some compilers incorporate some information about some standard
library functions for the purpose of producing better diagnostics
and/or optimizations.  But if, for example, a future standard
added an strtofoo() function, no *compiler* changes would be needed
to support it, as long as the headers and library implementation
supported it correctly.  The same thing happens if you add your own
footobar() function and provide a header that declares it (using
a different name because names starting with "str" are reserved).

Of course if you're using an implementation that doesn't conform to
C99, you're not guaranteed to be able to use strtoll() or strtoull(),
and you'll have to find some workaround.  An implementation that
depends entirely on msvcrt.dll for the C standard library cannot
conform to C99 (unless there's a later version of msvcrt.dll that I'm
not aware of).  I doubt that very many people have to deal with that.
(I presume you'll agree that you are not a typical user.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#164601

On 24/01/2022 23:33, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 24/01/2022 15:51, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
> [...]
>>>> bcc/tcc fail with a link error, unless I include this line:
>>> Then they are POS compilers, or you're using them incorrectly,
>>> such as forgetting to include <stdlib.h>.
>>
>> I said it's a link error. They both depend on the msvcrt.dll library
>> for standard C functions, and strtoull is not defined in that
>> library. (It is defined inside ucrtbase.dll, but then that's missing
>> stuff like printf.)
> 
> An aside: I have three different versions of msvcrt.dll on my Windows
> system.  None of them appear to support strtoll or strtoull.
> 
>> As certain people are so fond of reminding me, the library is a
>> completely different entity from the compiler, so it is apparently not
>> a compiler problem as both provide a proper API entry for that
>> function.
> 
> I think that may be the first time you've actually acknowledged that.
> 
> However, it's not necessary for the compiler itself to have a
> "proper API entry" for a library function, or to know anything
> about it.  Using strtol as an example (since it's supported all the
> way back to C89/C90), the compiler knows how to call it because it
> sees the declaration in <stdlib.h>.

The declaration is what I mean by 'API' entry. I'm using 'API' to mean 
all the information needed by the programmer to write calls to a 
function, and for the compiler to check those calls and generate the 
proper code, usually inside some header file.


> (I presume you'll agree that you are not a typical user.)

I guess not. I make considerably more use of the C standard library from 
outside C than inside it. However msvcrt.dll exports just over 1300 
functions, but I only ever use a few dozen. strtoull is one of the 1250 
or so that I haven't yet needed.

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

#164603

Bart <bc@freeuk.com> writes:
> On 24/01/2022 23:33, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 24/01/2022 15:51, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>> [...]
>>>>> bcc/tcc fail with a link error, unless I include this line:
>>>> Then they are POS compilers, or you're using them incorrectly,
>>>> such as forgetting to include <stdlib.h>.
>>>
>>> I said it's a link error. They both depend on the msvcrt.dll library
>>> for standard C functions, and strtoull is not defined in that
>>> library. (It is defined inside ucrtbase.dll, but then that's missing
>>> stuff like printf.)
>> An aside: I have three different versions of msvcrt.dll on my
>> Windows
>> system.  None of them appear to support strtoll or strtoull.
>> 
>>> As certain people are so fond of reminding me, the library is a
>>> completely different entity from the compiler, so it is apparently not
>>> a compiler problem as both provide a proper API entry for that
>>> function.
>> I think that may be the first time you've actually acknowledged
>> that.
>> However, it's not necessary for the compiler itself to have a
>> "proper API entry" for a library function, or to know anything
>> about it.  Using strtol as an example (since it's supported all the
>> way back to C89/C90), the compiler knows how to call it because it
>> sees the declaration in <stdlib.h>.
>
> The declaration is what I mean by 'API' entry. I'm using 'API' to mean
> all the information needed by the programmer to write calls to a 
> function, and for the compiler to check those calls and generate the
> proper code, usually inside some header file.

You said that "both provide a proper API entry for that function", where
the context indicated that "both" referred to the compiler and the
runtime library.  The compiler needs to *see* a C function declaration
(a clearer description IMHO than "proper API entry"), presumably in a
header file, but that declaration is not provided by the compiler
itself.  (Some headers might be distributed as part of the same package
as the compiler rather than as part of the runtime library; for example
gcc provides <stddef.h>.)

I think we both understand all this.  Please don't obfuscate it further.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#164656

On 1/25/2022 1:09 AM, Bart wrote:
> On 24/01/2022 23:33, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 24/01/2022 15:51, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>> [...]
>>>>> bcc/tcc fail with a link error, unless I include this line:
>>>> Then they are POS compilers, or you're using them incorrectly,
>>>> such as forgetting to include <stdlib.h>.
>>>
>>> I said it's a link error. They both depend on the msvcrt.dll library
>>> for standard C functions, and strtoull is not defined in that
>>> library. (It is defined inside ucrtbase.dll, but then that's missing
>>> stuff like printf.)
>>
>> An aside: I have three different versions of msvcrt.dll on my Windows
>> system.  None of them appear to support strtoll or strtoull.
>>
>>> As certain people are so fond of reminding me, the library is a
>>> completely different entity from the compiler, so it is apparently not
>>> a compiler problem as both provide a proper API entry for that
>>> function.
>>
>> I think that may be the first time you've actually acknowledged that.
>>
>> However, it's not necessary for the compiler itself to have a
>> "proper API entry" for a library function, or to know anything
>> about it.  Using strtol as an example (since it's supported all the
>> way back to C89/C90), the compiler knows how to call it because it
>> sees the declaration in <stdlib.h>.
> 
> The declaration is what I mean by 'API' entry. I'm using 'API' to mean 
> all the information needed by the programmer to write calls to a 
> function, and for the compiler to check those calls and generate the 
> proper code, usually inside some header file.
> 
> 
>> (I presume you'll agree that you are not a typical user.)
> 
> I guess not. I make considerably more use of the C standard library from 
> outside C than inside it. However msvcrt.dll exports just over 1300 
> functions, but I only ever use a few dozen. strtoull is one of the 1250 
> or so that I haven't yet needed.
> 
> 

Most importantly, msvcrt.dll is *not* a C standard library. It is a 
Microsoft library that exports C runtime functions for their own 
products [*].
It is not documented anywhere as a C *standard* library.
To be explicit, this means that you can't complain if it does not export 
a conforming implementation of C, and if you find inconsistencies with 
the standard it is certainly not the fault neither of the language nor 
of the standard.

It is your choice if you want to use it, but it should be no surprise at 
all if some C standard function is not available, or shows a different 
behaviour, or even has a different signature from the ISO standard. It 
is *not* a C standard library. (I guess I already wrote that)

In case the above were not sufficiently clear, not even Microsoft does 
list 'msvcrt.dll' among the redistributables for software developed with 
their development environment for C, which is Visual Studio, and is the 
only product for which they document /some/ conformancy with ISO C.

cfr. some information from Microsoft:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=msvc-170


As for some background, in the '90s 'msvcrt.dll' used to be Microsoft's 
"C runtime library" and it was part of the redistributables for early 
versions of their development product for C, which was called Visual 
C++. In this respect, you might say that /at that time/ it was part of 
Microsoft's implementation of C.
That said, the necessary remark is that, expecially at that time, 
Microsoft's implementation of C was well known for being wildly 
diverging from ISO C.


([*] More specifically, the page I linked above lists 'msvcrt.lib' among 
the "libraries that implement CRT initialization and termination" for C 
programs written with Visual Studio.)

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

#164661

On 26/01/2022 20:01, Manfred wrote:
> On 1/25/2022 1:09 AM, Bart wrote:
>> On 24/01/2022 23:33, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 24/01/2022 15:51, Scott Lurndal wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>>>> bcc/tcc fail with a link error, unless I include this line:
>>>>> Then they are POS compilers, or you're using them incorrectly,
>>>>> such as forgetting to include <stdlib.h>.
>>>>
>>>> I said it's a link error. They both depend on the msvcrt.dll library
>>>> for standard C functions, and strtoull is not defined in that
>>>> library. (It is defined inside ucrtbase.dll, but then that's missing
>>>> stuff like printf.)
>>>
>>> An aside: I have three different versions of msvcrt.dll on my Windows
>>> system.  None of them appear to support strtoll or strtoull.
>>>
>>>> As certain people are so fond of reminding me, the library is a
>>>> completely different entity from the compiler, so it is apparently not
>>>> a compiler problem as both provide a proper API entry for that
>>>> function.
>>>
>>> I think that may be the first time you've actually acknowledged that.
>>>
>>> However, it's not necessary for the compiler itself to have a
>>> "proper API entry" for a library function, or to know anything
>>> about it.  Using strtol as an example (since it's supported all the
>>> way back to C89/C90), the compiler knows how to call it because it
>>> sees the declaration in <stdlib.h>.
>>
>> The declaration is what I mean by 'API' entry. I'm using 'API' to mean 
>> all the information needed by the programmer to write calls to a 
>> function, and for the compiler to check those calls and generate the 
>> proper code, usually inside some header file.
>>
>>
>>> (I presume you'll agree that you are not a typical user.)
>>
>> I guess not. I make considerably more use of the C standard library 
>> from outside C than inside it. However msvcrt.dll exports just over 
>> 1300 functions, but I only ever use a few dozen. strtoull is one of 
>> the 1250 or so that I haven't yet needed.
>>
>>
> 
> Most importantly, msvcrt.dll is *not* a C standard library. It is a 
> Microsoft library that exports C runtime functions for their own 
> products [*].
> It is not documented anywhere as a C *standard* library.
> To be explicit, this means that you can't complain if it does not export 
> a conforming implementation of C, and if you find inconsistencies with 
> the standard it is certainly not the fault neither of the language nor 
> of the standard.
> 
> It is your choice if you want to use it,

I think I first came across this library when I started to work with 
Windows sometime in the 90s.

I didn't really associate with it C (I didn't use it from that 
language); it seemed just another set of WinAPI functions from the docs, 
all of which used C-style declarations.

It seems to be still present on every Windows OS, so I don't think it's 
going anywhere.

msvcrt.dll is also used by gcc/tdm on Windows as well as tcc, for 
building programs. If it suddenly disappeared, then quite a lot of 
programs would stop working...

... including gcc.exe and tcc.exe which themselves both import msvcrt.dll.

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

#164669

On 1/26/2022 9:53 PM, Bart wrote:
> On 26/01/2022 20:01, Manfred wrote:
>> On 1/25/2022 1:09 AM, Bart wrote:
>>> On 24/01/2022 23:33, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 24/01/2022 15:51, Scott Lurndal wrote:
>>>>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>>>>> bcc/tcc fail with a link error, unless I include this line:
>>>>>> Then they are POS compilers, or you're using them incorrectly,
>>>>>> such as forgetting to include <stdlib.h>.
>>>>>
>>>>> I said it's a link error. They both depend on the msvcrt.dll library
>>>>> for standard C functions, and strtoull is not defined in that
>>>>> library. (It is defined inside ucrtbase.dll, but then that's missing
>>>>> stuff like printf.)
>>>>
>>>> An aside: I have three different versions of msvcrt.dll on my Windows
>>>> system.  None of them appear to support strtoll or strtoull.
>>>>
>>>>> As certain people are so fond of reminding me, the library is a
>>>>> completely different entity from the compiler, so it is apparently not
>>>>> a compiler problem as both provide a proper API entry for that
>>>>> function.
>>>>
>>>> I think that may be the first time you've actually acknowledged that.
>>>>
>>>> However, it's not necessary for the compiler itself to have a
>>>> "proper API entry" for a library function, or to know anything
>>>> about it.  Using strtol as an example (since it's supported all the
>>>> way back to C89/C90), the compiler knows how to call it because it
>>>> sees the declaration in <stdlib.h>.
>>>
>>> The declaration is what I mean by 'API' entry. I'm using 'API' to 
>>> mean all the information needed by the programmer to write calls to a 
>>> function, and for the compiler to check those calls and generate the 
>>> proper code, usually inside some header file.
>>>
>>>
>>>> (I presume you'll agree that you are not a typical user.)
>>>
>>> I guess not. I make considerably more use of the C standard library 
>>> from outside C than inside it. However msvcrt.dll exports just over 
>>> 1300 functions, but I only ever use a few dozen. strtoull is one of 
>>> the 1250 or so that I haven't yet needed.
>>>
>>>
>>
>> Most importantly, msvcrt.dll is *not* a C standard library. It is a 
>> Microsoft library that exports C runtime functions for their own 
>> products [*].
>> It is not documented anywhere as a C *standard* library.
>> To be explicit, this means that you can't complain if it does not 
>> export a conforming implementation of C, and if you find 
>> inconsistencies with the standard it is certainly not the fault 
>> neither of the language nor of the standard.
>>
>> It is your choice if you want to use it,
> 
> I think I first came across this library when I started to work with 
> Windows sometime in the 90s.
> 
> I didn't really associate with it C (I didn't use it from that 
> language); it seemed just another set of WinAPI functions from the docs, 
> all of which used C-style declarations.
> 
> It seems to be still present on every Windows OS, so I don't think it's 
> going anywhere.
> 
> msvcrt.dll is also used by gcc/tdm on Windows as well as tcc, for 
> building programs. If it suddenly disappeared, then quite a lot of 
> programs would stop working...
> 
> ... including gcc.exe and tcc.exe which themselves both import msvcrt.dll.
> 

Yes, msvcrt.dll has been part of Windows for a very long time, and most 
probably it will stay this way, although one has to notice that with 
Microsoft this kind of prediction has gotten harder and harder as of 
recent - I believe they have thrown out more stuff out of the window in 
the last five years than in the previous 35, to the point that today it 
is even impossible to get redistributables that were first released in 2010.

But that was not my point.

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

#164499

Meredith Montgomery <mmontgomery@levado.to> writes:

> I've been trying to think of an analogy for the verification
>
>       if( ((UINT64_MAX - c) / 10) >= r)
>         r = r * 10 + c;
>       else return -1; /* doesn't fit */
>
> in the procedure below.  [...]

No analogy needed.  The condition that needs to be
satisfied is

    r * 10 + c <= UINT64_MAX

which is the same as

    r * 10 <= UINT64_MAX - c

which is the same as

    r <= (UINT64_MAX - c) / 10

which is the same as

    (UINT64_MAX - c) / 10 >= r

giving the expression in the if() test.  Done.


> (*) The procedure
>
> uint64_t array_to_uint64(char *s, uint64_t *u)
> {
>   uint64_t pos;
>   uint64_t r;
>   uint64_t c;
>
>   pos = 0; r = 0;
>
>   for ( ;; ) {
>     c = (uint64_t) (unsigned char) (s[pos] - '0');
>     if (c < 10) {
>       if( ((UINT64_MAX - c) / 10) >= r)
>         r = r * 10 + c;
>       else return -1; /* doesn't fit */
>       ++pos; continue;
>     }
>     break;
>   }
>
>   *u = r;
>   return pos;
> }

It's better to write the code so the funny division test
isn't needed:

   uint64_t
   array_to_uint64( char *s0, uint64_t *u ){
      char *s = s0;
      uint64_t r, d, nr;

      for(   r = 0;   d = *s-'0',  nr = r*10+d,  d < 10;   r = nr,  s++   ){
         if(  r > nr  )  return  -1;
      }

      return  *u = r,  s-s0;
   }

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

#164502

Am 21.01.2022 um 04:24 schrieb Tim Rentsch:
> Meredith Montgomery <mmontgomery@levado.to> writes:
> 
>> I've been trying to think of an analogy for the verification
>>
>>        if( ((UINT64_MAX - c) / 10) >= r)
>>          r = r * 10 + c;
>>        else return -1; /* doesn't fit */
>>
>> in the procedure below.  [...]
> 
> No analogy needed.  The condition that needs to be
> satisfied is
> 
>      r * 10 + c <= UINT64_MAX
> 
> which is the same as
> 
>      r * 10 <= UINT64_MAX - c
> 
> which is the same as
> 
>      r <= (UINT64_MAX - c) / 10
> 
> which is the same as
> 
>      (UINT64_MAX - c) / 10 >= r
> 
> giving the expression in the if() test.  Done.
> 

Doesn't help because c isn't a constant.

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

#164506

Bonita Montero <Bonita.Montero@gmail.com> writes:

> Am 21.01.2022 um 04:24 schrieb Tim Rentsch:
>
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>
>>> I've been trying to think of an analogy for the verification
>>>
>>>        if( ((UINT64_MAX - c) / 10) >= r)
>>>          r = r * 10 + c;
>>>        else return -1; /* doesn't fit */
>>>
>>> in the procedure below.  [...]
>>
>> No analogy needed.  The condition that needs to be
>> satisfied is
>>
>>      r * 10 + c <= UINT64_MAX
>>
>> which is the same as
>>
>>      r * 10 <= UINT64_MAX - c
>>
>> which is the same as
>>
>>      r <= (UINT64_MAX - c) / 10
>>
>> which is the same as
>>
>>      (UINT64_MAX - c) / 10 >= r
>>
>> giving the expression in the if() test.  Done.
>
> Doesn't help because c isn't a constant.

It's hard to know what to say to such an obviously
inapplicable comment.

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

#164510

Am 21.01.2022 um 15:01 schrieb Tim Rentsch:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
> 
>> Am 21.01.2022 um 04:24 schrieb Tim Rentsch:
>>
>>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>>
>>>> I've been trying to think of an analogy for the verification
>>>>
>>>>         if( ((UINT64_MAX - c) / 10) >= r)
>>>>           r = r * 10 + c;
>>>>         else return -1; /* doesn't fit */
>>>>
>>>> in the procedure below.  [...]
>>>
>>> No analogy needed.  The condition that needs to be
>>> satisfied is
>>>
>>>       r * 10 + c <= UINT64_MAX
>>>
>>> which is the same as
>>>
>>>       r * 10 <= UINT64_MAX - c
>>>
>>> which is the same as
>>>
>>>       r <= (UINT64_MAX - c) / 10
>>>
>>> which is the same as
>>>
>>>       (UINT64_MAX - c) / 10 >= r
>>>
>>> giving the expression in the if() test.  Done.
>>
>> Doesn't help because c isn't a constant.
> 
> It's hard to know what to say to such an obviously
> inapplicable comment.

If your exchanges would result in a constant instead of a calucaltion
they would be favourable. But the overhead for your swapped calculation
is exactly the same and the code isn't more readable than before.

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

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

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

csiph-web