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 */

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.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Bart <bc@freeuk.com> writes:
>>
>>> c:\c>tcc c.c
>>> tcc: error: undefined symbol 'strtoull'
>>
>> strtoull is a POSIX symbol. If the tcc implementation you
>> are using supports POSIX, then you've likely misconfigured tcc,
>> otherwise you're tilting at windmills.
>
>I'm not sure what you mean by POSIX symbol. In C99 and later, strtoll
>and strtoull are both defined by ISO C, and will be supported by any
>conforming (hosted) implementation. Neither was defined by C90. I
>suppose earlier editions of POSIX may have defined strtoll and strtoull
>for pre-C99 compilers, but they depend on the long long and unsigned
>long long types.

POSIX generally incorporates a C standard by reference, and we
had implemented (circa 1989) the strto[u]ll functions in our versions
of Unix for the Motorla 88100. My early specs are in storage,
so I can't refer back to them to see when 1003.4 or X/Open adopted
them.

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 */

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.

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 */

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

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.

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.

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

> Meredith Montgomery <mmontgomery@levado.to> writes:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> On 16/01/2022 02:27, Meredith Montgomery wrote:
>>>> 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)
>>>
>>> Dividing by 10 each time is unnecessary (even if usually optimised to
>>> shifts and multiplies).
>>>
>>> You only need to make this check after you've already processed 19
>>> characters, as it could overflow on the 20th, but not before.
>>>
>>> I think when pos >= 18.
>>
>> I suppose you're right, but imagine putting such check there. It would
>> take even more paragraphs to explain it to myself some time later when
>> I'm trying to figure out what I wrote a while back.
>
> You could just check that the array contains a string of digits
> lexicographically less than or equal to 18446744073709551615. If there
> are fewer digits than this, or, at every position, the digit you have is
> no greater than the corresponding digit of that number, you are ok.

That seems correct, but if I change the size of my register, then I must
replace the number too. :-)

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

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

That's a brilliant explanation!

Meredith Montgomery <mmontgomery@levado.to> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 16/01/2022 02:27, Meredith Montgomery wrote:
>>>>> 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)
>>>>
>>>> Dividing by 10 each time is unnecessary (even if usually optimised to
>>>> shifts and multiplies).
>>>>
>>>> You only need to make this check after you've already processed 19
>>>> characters, as it could overflow on the 20th, but not before.
>>>>
>>>> I think when pos >= 18.
>>>
>>> I suppose you're right, but imagine putting such check there. It would
>>> take even more paragraphs to explain it to myself some time later when
>>> I'm trying to figure out what I wrote a while back.
>>
>> You could just check that the array contains a string of digits
>> lexicographically less than or equal to 18446744073709551615. If there
>> are fewer digits than this, or, at every position, the digit you have is
>> no greater than the corresponding digit of that number, you are ok.
>
> That seems correct, but if I change the size of my register, then I must
> replace the number too. :-)

Sure. Just as you'd have to replace UINT64_MAX and so on. Remember you
don't have to write 18446744073709551615. You could use snprintf to put
UINT64_MAX into a static buffer.

--
Ben.

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

> Meredith Montgomery <mmontgomery@levado.to> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>>
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 16/01/2022 02:27, Meredith Montgomery wrote:
>>>>>> 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)
>>>>>
>>>>> Dividing by 10 each time is unnecessary (even if usually optimised to
>>>>> shifts and multiplies).
>>>>>
>>>>> You only need to make this check after you've already processed 19
>>>>> characters, as it could overflow on the 20th, but not before.
>>>>>
>>>>> I think when pos >= 18.
>>>>
>>>> I suppose you're right, but imagine putting such check there. It would
>>>> take even more paragraphs to explain it to myself some time later when
>>>> I'm trying to figure out what I wrote a while back.
>>>
>>> You could just check that the array contains a string of digits
>>> lexicographically less than or equal to 18446744073709551615. If there
>>> are fewer digits than this, or, at every position, the digit you have is
>>> no greater than the corresponding digit of that number, you are ok.
>>
>> That seems correct, but if I change the size of my register, then I must
>> replace the number too. :-)
>
> Sure. Just as you'd have to replace UINT64_MAX and so on. Remember you
> don't have to write 18446744073709551615. You could use snprintf to put
> UINT64_MAX into a static buffer.

Lol. You're totally right. It's totally trivial to solve this problem.
Good to know. I will take notice of this. I value trivial solutions
quite a lot: I had to think hard about that verification and there was
this easy solution on my face all along.

Meredith Montgomery <mmontgomery@levado.to> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>>>
>>>>> Bart <bc@freeuk.com> writes:
>>>>>
>>>>>> On 16/01/2022 02:27, Meredith Montgomery wrote:
>>>>>>> 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)
>>>>>>
>>>>>> Dividing by 10 each time is unnecessary (even if usually optimised to
>>>>>> shifts and multiplies).
>>>>>>
>>>>>> You only need to make this check after you've already processed 19
>>>>>> characters, as it could overflow on the 20th, but not before.
>>>>>>
>>>>>> I think when pos >= 18.
>>>>>
>>>>> I suppose you're right, but imagine putting such check there. It would
>>>>> take even more paragraphs to explain it to myself some time later when
>>>>> I'm trying to figure out what I wrote a while back.
>>>>
>>>> You could just check that the array contains a string of digits
>>>> lexicographically less than or equal to 18446744073709551615. If there
>>>> are fewer digits than this, or, at every position, the digit you have is
>>>> no greater than the corresponding digit of that number, you are ok.
>>>
>>> That seems correct, but if I change the size of my register, then I must
>>> replace the number too. :-)
>>
>> Sure. Just as you'd have to replace UINT64_MAX and so on. Remember you
>> don't have to write 18446744073709551615. You could use snprintf to put
>> UINT64_MAX into a static buffer.
>
> Lol. You're totally right. It's totally trivial to solve this problem.
> Good to know. I will take notice of this. I value trivial solutions
> quite a lot: I had to think hard about that verification and there was
> this easy solution on my face all along.

There may be pitfalls I've not spotted because I've never seen this done
in anyone else's code.

--
Ben.