Ce n'est pas le cas.
Le terminateur de chaîne est un octet contenant tous les 0 bits.
L'int entier non signé est de deux ou quatre octets (selon votre environnement) contenant chacun les 0 bits.
Les deux articles sont stockés à des adresses différentes. Votre code compilé effectue des opérations adaptées aux chaînes sur le premier emplacement et des opérations adaptées aux nombres binaires non signés sur le dernier. (Sauf si vous avez soit un bug dans votre code, soit un code dangereusement intelligent!)
Mais tous ces octets sont identiques pour le processeur. Les données en mémoire (dans la plupart des architectures de jeux d'instructions courantes) ne sont associées à aucun type. C'est une abstraction qui n'existe que dans le code source et ne signifie que pour le compilateur.
Édition ajoutée: à titre d'exemple: il est parfaitement possible, même courant, d'effectuer une arithmétique sur les octets qui composent une chaîne. Si vous avez une chaîne de caractères ASCII 8 bits, vous pouvez convertir les lettres de la chaîne entre les majuscules et les minuscules en ajoutant ou en soustrayant 32 (décimal). Ou si vous traduisez vers un autre code de caractère, vous pouvez utiliser leurs valeurs comme indices dans un tableau dont les éléments fournissent le codage binaire équivalent dans l'autre code.
Pour le CPU, les caractères sont vraiment des entiers extra-courts. (huit bits chacun au lieu de 16, 32 ou 64.) Pour nous, les humains, leurs valeurs sont associées à des caractères lisibles, mais le CPU n'en a aucune idée. Il ne sait rien non plus sur la convention "C" de "l'octet nul termine une chaîne" (et comme beaucoup l'ont noté dans d'autres réponses et commentaires, il existe des environnements de programmation dans lesquels cette convention n'est pas utilisée du tout) .
Certes, certaines instructions en x86 / x64 sont généralement utilisées avec des chaînes - le préfixe REP par exemple - mais vous pouvez tout aussi bien les utiliser sur un tableau d'entiers, si elles atteignent le résultat souhaité.