On 20/01/2022 17:02, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 20/01/2022 03:49, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>
>>>> * My parseull routine on Windows: 0.28/0.35 seconds (with/without
>>>> length)
>>>
>>> This one probably doesn't do the same job, so it's not a direct
>>> comparison.
>>
>> It was supposed to do the same job as BM's program: take a string
>> containing only digits and convert them while checking for overflows.
>
> Right. But it does not do the same job as the other functions you gave
> timings for /in the post I replied to/.

OK. Maybe you should ask Scott Lurndal why /he/ brought up strtoll().
The implication was they they did the same kind of thing, namely convert
a string of digits to an integer.

I suggested that among several reasons why a custom routine might be
used, was performance, even if they differ in features.

However, I've created a version of my routine which is more in line with
how strtoull etc work (but I don't know the full spec), shown below.

This version is still 50% faster than the fastest stroull routine on my
machine.

(One reason may be that it is hard-coded for base-10. If so, then that
is an argument for creating your own dedicated base-10 version.)

-----------------------------------------------
typedef unsigned long long u64;

u64 parseull(char* s, char** send) {
int length,neg=0;

while (*s==' ' || *s=='\t' ) ++s; // leading spaces
if (*s=='-') {neg=1; ++s;} // optional signs
else if (*s=='+') ++s;
while (*s=='0' && *(s+1)=='0') ++s; // leading zeros

length=0;
*send=s;

while (**send>='0' && **send<='9') ++(*send);
length=*send-s;
if (length==0) return -1; // u64.max on error
if (length>20) return -1;

if (length==20 && strncmp(s, "18446744073709551615",20)>0)
return -1;

u64 a=*s -'0';
while (--length) {a=a*10+*++s-'0';};
if (neg) return -a;
return a;
}

On 20/01/2022 19:20, Bart wrote:

> -----------------------------------------------
>     typedef unsigned long long u64;
>
>     u64 parseull(char* s, char** send) {
>         int length,neg=0;
>
>         while (*s==' ' || *s=='\t' ) ++s;        // leading spaces
>         if (*s=='-') {neg=1; ++s;}               // optional signs
>         else if (*s=='+') ++s;
>         while (*s=='0' && *(s+1)=='0') ++s;      // leading zeros

That's not quite right, as it will leave 1 leading zero; better:

while (*s=='0' && (*(s+1)>='1' && *(s+1)<='9')) ++s;

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;
}

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.

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.

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.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>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.
>

Although the ordering can be significant from a security perspective,
consider this:

if (len > PAGE_SIZE - 2 - size)

vs. this:

if (size + len + 2 > PAGE_SIZE)

Which is better, and why?

Am 21.01.2022 um 18:41 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> 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.
>>
>
> Although the ordering can be significant from a security perspective,
> consider this:
>
> if (len > PAGE_SIZE - 2 - size)
>
> vs. this:
>
> if (size + len + 2 > PAGE_SIZE)
>
> Which is better, and why?

Totally different discussion.

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

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

Apparently you don't understand that your comment has no bearing
on what I was talking about.

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?

[...]

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

On Mon, 24 Jan 2022 00:13:32 +0000, Bart wrote:

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

Countless generations of programmers have found a sensible way to handle such
conflicts by using conditional compilation.

strtoull() has been defined as being part of the C99 standard library, and
before that, part of the POSIX.1-2001 and POSIX.1-2001 Unix standard libraries.
A simple macro test of the value of __STDC_VERSION__, and setting of the appropriate
pre-C99 macros should be all that is necessary to properly access strtoull().

Something like
#if (__STDC_VERSION__ < 199901l)
//do whatever it takes to properly define strtoull() for this platform
#endif

(note, the above "do whatever" might include such things as testing macros
to determine the platform and take appropriate action, as in
#ifdef WIN32
#define strtoull _strtoui64
#endif
or defining macros to force platform-specific libraries, like
#define _SVID_SOURCE

[snip]
> The above is enough for me to think twice about using strtoull in a project.

Your loss, I guess.

--
Lew Pitcher
"In Skills, We Trust"

On 24/01/2022 00:38, Lew Pitcher wrote:
> On Mon, 24 Jan 2022 00:13:32 +0000, Bart wrote:
>
>> 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.
>
> Countless generations of programmers have found a sensible way to handle such
> conflicts by using conditional compilation.
>
> strtoull() has been defined as being part of the C99 standard library, and
> before that, part of the POSIX.1-2001 and POSIX.1-2001 Unix standard libraries.
> A simple macro test of the value of __STDC_VERSION__, and setting of the appropriate
> pre-C99 macros should be all that is necessary to properly access strtoull().
>
> Something like
> #if (__STDC_VERSION__ < 199901l)
> //do whatever it takes to properly define strtoull() for this platform
> #endif
>
> (note, the above "do whatever" might include such things as testing macros
> to determine the platform and take appropriate action, as in
> #ifdef WIN32
> #define strtoull _strtoui64
> #endif
> or defining macros to force platform-specific libraries, like
> #define _SVID_SOURCE

If you're an implementer creating headers for a C compiler, then you
should just declare then properly.

I just have in mine; it took a minute or so (after previously finding
out that MS uses that different naming). But I can't do it for tcc or
any other compiler that might have an issue.

And if you're not an implementer, then that's a lot of clutter to go
into your application's headers just to pander for one or two compilers.

It's the sort of think I absolutely hate when poking arond application
headers, trying to figure why it doesn't work, because it's
special-casing some specific compilers, which will then exclude mine.

You might as well just implement a suitable function, then it'll run
anywhere, might be faster as I found, and could be made with a sweeter
interface.

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.

> The above is enough for me to think twice about using strtoull in a
> project.

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?

--
Ben.

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

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.

c:\c>type c.c
#include <stdio.h>
#include <stdlib.h>

int main(void) {
char* p;
printf("%llu\n", strtoull("1234", &p, 10));
}

c:\c>tcc c.c
tcc: error: undefined symbol 'strtoull'

c:\c>tcc -c c.c

c:\c>tcc -v
tcc version 0.9.27 (x86_64 Windows)

It looks like a link issue with tcc to me. As I said this was on
Windows. tcc appears to use msvcrt.dll, because when I add that define,
and look at the resulting exe, it says:

Name: msvcrt.dll
Import Addr RVA: 2038
Import: 20e3 0 _strtoui64
Import: 20f0 0 printf
Import: 20f9 0 __set_app_type
....

Maybe some people spend at lot of time telling their compilers exactly
which libraries to use for standard functions of C; I just use the
supplied compiler or driver program.

Since all C compilers that I've used will do the whole job of source ->
binary just by invoking that front end.

So, what version of tcc do you have, and what special thing do you have
to do to make it work?

If you're on Linux, that doesn't count as the standard library is
unlikely to use MS's _strtoui64 name for that function.

This is what I originally said:

"...(gcc has it on Windows, but the two other compilers I have don't)"

>> unless I include this line:
>>
>> #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.

For the same reason, I tend not to write shared code that uses '$' in
identifiers, because tcc doesn't support 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.

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.

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

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

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.

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.

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.

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.

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

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.

Did pre-C99 versions of POSIX (optionally?) specify long long and
unsigned long long before ISO C did?

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