Подтвердить что ты не робот

Bash Лимит числа?

Я спросил вопрос ранее, который включал вытягивание больших простых чисел из текстового файла и помещение их в другой файл. Предполагалось, что каждый пробег до и включительно первого числа после 2 ^ 32, и по какой-то причине этот script перестает работать.

#!/bin/bash
n=4294967296
last=0
while read number
    do
    if [ $last -gt $n ]
    then break
    fi
    echo $number
last=$number
done < primes.txt > primes2.txt

Это закончилось тем, что пронеслось через эти 11 чисел:

4232004449  
4232004479  
4232004493  
4232004509  
4232004527  
4232004533  
4232004559  
4232004589  
4232004593  
4232004613  
004437

В исходном файле не было 004437, а мой bash будет обрабатывать числа над 8999999999999999999

Кто-нибудь знает, почему это произошло?

64-разрядная Ubuntu 10.04, 16 ГБ ОЗУ, 8 ядер = 3,60 ГГц
GNU bash, версия 4.1.5 (1) -release (x86_64-pc-linux-gnu)

Update:

После загрузки и компиляции "фиксированного" bash, предоставленного jfgagne и связанного с ним в моем bash script, он был ошибочен в одном и том же месте. Используя значительно более быстрый perl-эквивалент из моего первоначального основного вопроса, я получил некоторые размеры файлов от ls -al:

        11  next_prime (just to make sure this was counting bytes accurately)
2147483659  primes2.txt
2147483670  one_too_many

2147483659 = 2 ^ 31 + 11

Размер следующего простого (4232004631) равен 11 байтам Это содержит все простые числа до 4232004613. Я также понял, что 004437 происходит от конца штриха в нижней части этого цикла ошибки (4232004437). Кажется, что-то пытается продвинуться, но застряло.

4b9b3361

Ответ 1

Нет, он не зависит от битрейта вашей ОС. Это зависит от простой декларации в глубине источников bash.

Это объявление __int64_t с 2002 года. С тех пор bash versions >= 3.00 всегда используют 64-битные целочисленные переменные, и это не зависит от архитектуры! Это зависит только от версии bash.

Предыдущие версии bash всегда использовали 32-битное целое число, даже на 64-битной ОС.