Em um dado arquivo, os dois primeiros bytes, ordenados em little-endian, identificam o tamanho desse arquivo. Supondo que o primeiro byte tenha o valor 37 na base octal e o segundo byte tenha o valor 10001010 na base 2, o tamanho do arquivo, na base decimal, será
- A)7570.
Errada, porque ignora a ordem little-endian e faz uma combinação numérica que não corresponde aos bytes dados.
- B)35359.
Certa, pois 37(8)=31 e 10001010(2)=138, e em little-endian o valor é 138 x 256 + 31 = 35359.
- C)25718.
Errada, porque o resultado não bate com a conversão correta dos bytes nem com a montagem little-endian.
- D)8074.
Errada, pois parte de uma interpretação inadequada da ordem dos bytes e da conversão das bases.
- E)36224.
Errada, porque não corresponde ao valor formado pelo segundo byte como parte mais significativa e pelo primeiro como menos significativo.
Gabarito: B
Em sistemas de numeração, a primeira chave é converter cada valor para a base pedida. Aqui, o primeiro byte veio em octal: 37(8) = 3 x 8 + 7 = 31(10). O segundo veio em binário: 10001010(2) = 128 + 8 + 2 = 138(10). Em seguida, vem o detalhe que costuma aprontar: como os bytes estão em little-endian, o primeiro byte é o menos significativo, então ele fica nas casas baixas e o segundo byte nas casas altas. Ou seja, o tamanho do arquivo é 138 x 256 + 31. Como 256 representa um deslocamento de 1 byte para a esquerda, isso equivale a 138 x 256 + 31 = 35359. Essa é exatamente a leitura correta do enunciado e por isso o gabarito é a alternativa B. A ideia de little-endian aparece muito em questões de arquitetura e organização de memória. Não é uma regra jurídica nem nada do tipo, mas um padrão técnico de representação de dados: o byte menos significativo vem primeiro na memória ou no arquivo. Em prova, a banca adora misturar isso com conversão de bases para testar se você faz a conta e respeita a ordem dos bytes sem pressa.