Обнаружил странность. Не понимаю, почему так происходит. Программа заменяет табы на пробелы, количество которых задано именованной константой SPACES. После чего выводит изначальную длину строки, длину после обработки, а так же саму строку.
Первый вариант программы:
#include <stdio.h>
#define MAX_LINE 32
#define SPACES 4
int get_line_length(char line[]);
int detab_line(char line[]);
int main()
{
char line[MAX_LINE] = "\thello\tworld";
printf("[ %d -> %d ]%s\n", get_line_length(line), detab_line(line), line);
return 0;
}
int get_line_length(char line[])
{
for (int i = 0; i < MAX_LINE; i++)
if (line[i] == '\0')
return i;
return -1;
}
int detab_line(char line[])
{
int line_length = get_line_length(line);
int tubs_count = 0;
for (int i = 0; i < line_length; i++)
if (line[i] == '\t')
++tubs_count;
int offset = tubs_count * (SPACES - 1);
if (line_length + offset >= MAX_LINE)
return -1;
for (int i = line_length; i >= 0; --i)
{
if (line[i] == '\t')
{
for (int j = 0; j < SPACES; j++)
{
line[i + offset] = ' ';
--offset;
}
}
else
{
line[i + offset] = line[i];
}
}
return get_line_length(line);
}
Второй вариант программы:
#include <stdio.h>
#define MAX_LINE 32
#define SPACES 4
int get_line_length(char line[]);
int detab_line(char line[]);
int main()
{
char line[MAX_LINE] = "\thello\tworld";
int old_len = get_line_length(line);
printf("[ %d -> %d ]%s\n", old_len, detab_line(line), line);
return 0;
}
int get_line_length(char line[])
{ ... }
int detab_line(char line[])
{ ... }
Первый вариант программы при выполении выдаёт ошибку:
$ gcc test.c -o test; ./test
Ошибка сегментирования (стек памяти сброшен на диск)
Второй вариант работает ожидаемым образом.
На мой взгляд эти два варианта программы эквивалентны. В чём может быть проблема?
P.S.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.4.0-1ubuntu1~20.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-Av3uEd/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)
P.P.S. Я изначально знал, что функция detab_line() работает некорректно - неправильно рассчитывается offset. Но я не ожидал, что это должно было каким-либо образом повлиять на вызов функции get_line_length(). Исправленная версия detab_line():
int detab_line(char line[])
{
int line_length = get_line_length(line);
int tubs_count = 0;
for (int i = 0; i < line_length; i++)
if (line[i] == '\t')
++tubs_count;
int offset = tubs_count * (SPACES - 1);
if (line_length + offset >= MAX_LINE)
return -1;
for (int i = line_length; i >= 0; --i)
{
if (line[i] == '\t')
{
for (int j = 0; j < SPACES; j++)
{
line[i + offset - j] = ' ';
}
offset -= SPACES - 1;
}
else
{
line[i + offset] = line[i];
}
}
return get_line_length(line);
}
Теперь программа работает. Но очень хочется понять, почему же такая проблема возникла?
line[-2]=..из-за вашего просчёта происходит нарушение доступа к памяти и система просто прогу закрывает. Данные переменнойlineнаходятся в самом начале стека и вы выходите из границ разрешаемой области памяти. – AlexGlebe Oct 14 '22 at 20:05