# Why use "strlen30()" instead of "strlen()"?

The commit message that went in with this change states:

[793aaebd8024896c] part of check-in [c872d55493] Never use strlen(). Use our own internal sqlite3Strlen30() which is guaranteed to never overflow an integer. Additional explicit casts to avoid nuisance warning messages. (CVS 6007) (user: drh branch: trunk)

*(this is my answer from Why reimplement strlen as loop+subtraction? , but it was closed)*

I can't tell you the reason why they had to re-implement it, and why they chose `int`

instead if `size_t`

as the return type. But about the function:

```
/*
** Compute a string length that is limited to what can be stored in
** lower 30 bits of a 32-bit signed integer.
*/
static int strlen30(const char *z){
const char *z2 = z;
while( *z2 ){ z2++; }
return 0x3fffffff & (int)(z2 - z);
}
```

## Standard References

The standard says in (ISO/IEC 14882:2003(E)) *3.9.1 Fundamental Types*, 4.:

Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2

^{n}where n is the number of bits in the value representation of that particular size of integer.^{}41)...

^{41)}: This implies that unsigned arithmetic does not overflow because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting unsigned integer type

That part of the standard does not define overflow-behaviour for signed integers. If we look at *5. Expressions*, 5.:

If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined, unless such an expression is a constant expression (5.19), in which case the program is ill-formed. [Note: most existing implementations of C + + ignore integer overflows. Treatment of division by zero, forming a remainder using a zero divisor, and all floating point exceptions vary among machines, and is usually adjustable by a library function. ]

So far for overflow.

As for subtracting two pointers to array elements, *5.7 Additive operators*, 6.:

When two pointers to elements of the same array object are subtracted, the result is the difference of the subscripts of the two array elements. The type of the result is an implementation-defined signed integral type; this type shall be the same type that is defined as ptrdiff_t in the

cstddefheader (18.1). [...]

Looking at *18.1*:

The contents are the same as the Standard C library header

stddef.h

So let's look at the C standard (I only have a copy of C99, though), *7.17 Common Definitions *:

- The types used for size_t and ptrdiff_t should not have an integer conversion rank greater than that of signed long int unless the implementation supports objects large enough to make this necessary.

No further guarantee made about `ptrdiff_t`

. Then, Annex E (still in ISO/IEC 9899:TC2) gives the *minimum magnitude* for signed long int, but not a maximum:

```
#define LONG_MAX +2147483647
```

Now what are the maxima for `int`

, the return type for `sqlite - strlen30()`

? Let's skip the C++ quotation that forwards us to the C-standard once again, and we'll see in C99, Annex E, the minimum maximum for `int`

:

```
#define INT_MAX +32767
```

## Summary

- Usually,
`ptrdiff_t`

is not bigger than`signed long`

, which is not smaller than 32bits. `int`

is just defined to be at least 16bits long.- Therefore, subtracting two pointers may give a result that does not fit into the
`int`

of your platform. - We remember from above that for signed types, a result that does not fit yields undefined behaviour.
`strlen30`

does applies a bitwise or upon the pointer-subtract-result:

```
| 32 bit |
ptr_diff |10111101111110011110111110011111| // could be even larger
& |00111111111111111111111111111111| // == 3FFFFFFF<sub>16</sub>
----------------------------------
= |00111101111110011110111110011111| // truncated
```

That prevents undefiend behaviour by truncation of the pointer-subtraction result to a maximum value of 3FFFFFFF_{16} = 1073741823_{10}.

I am not sure about why they chose exactly that value, because on most machines, only the most significant bit tells the signedness. It could have made sense versus the standard to choose the minimum `INT_MAX`

, but 1073741823 is indeed slightly strange without knowing more details (though it of course perfectly does what the comment above their function says: truncate to 30bits and prevent overflow).