LINUX.ORG.RU

динамические строки Си. Реинкарнация

 


0

2

Сегодня залил в реп первую версию библиотеки для работы с динамическими строками на Си: https://github.com/maksspace/dynamic-string

Товарищи, посмотрите это творение и выскажете свое мнение об этом) Буду очень признателен за конструктивную критику.)

Ответ на: комментарий от monk
unsigned long test(void)
{
  struct timeval tv;
  unsigned long junk;
 	
  gettimeofday(&tv, NULL);
  getpid();
  return junk;
}

Тут дело не в (getpid() << 16) ^ tv.tv_sec ^ tv.tv_usec ^ junk; - у меня было больше кода, поэтому так вышло.

Тут рандомное значение, которое случайно вышло 0, потому-что где-то выше у тебя был аргумент 0. Тут нет ничего удивительного.

PotentialCppTsar
()
Ответ на: комментарий от anonymous

о! Опять этот шизик, обиженный на весь мир, прибежал.

Да не обижен я на мир - просто мне понятно почему пацаны не осиливают сделать вывод из своих доводов.

Ну показал ты мне уб - что дальше? Что из этого следует? Да ничего. При этом я уже показал почему и как это уб происходит и почему к рантайму отношения не имеет.

В школе все еще продолжают пиздить и сувать писюны тебе в рот?

В школе я не был - ты уже должен был знать мою биографию.

Лол. Ты настолько соответствуешь описалову комплекса неполноценности, что с тебя хоть очередной учебник пиши.

Не комплексу «неполноценности» а комплексу «антито, что убогая посредственность считает за норму».

Хочешь показать, что ты из себя что-то представляешь - вперёд.

Я вон не могу понять - какая разница. Вот ты тотальная некомпетентность несёшь херню, а я просто большой шизик который на всех аргится. Не мы такие - жизнь такая. Я же пытаюсь с тобою разговаривать - и ты попытайся со мною.

PotentialCppTsar
()
Ответ на: комментарий от PotentialCppTsar

Диагноз подтверждается. Поциент находится в стадии отрицания.

Не мы такие - жизнь такая

ага-ага. типичные отмазки типичного дегенерата. не могущего нивочто, кроме повышения своего ЧСВ через «говно», «балаболки», «нулины». лол.

anonymous
()
Ответ на: комментарий от PotentialCppTsar

Поведение реализации имеет больший приоритет, чем описание, по которому эта реализация делалась

То есть, ты пишешь не на Си, а на языке, который компилируется gcc-5.2.1 при -O0, например? Ведь даже разные версии gcc ведут себя по-разному. И при разном уровне оптимизации по-разному.

Зная поведение реализации я знаю поведение и описание, которому она соответствует.

Ты знаешь поведение конкретного компилятора конкретной версии на конкретной платформе с определённой комбинацией флагов компиляции. Впрочем, если тебя принципиально не интересует переносимость...

Ты типа мне пытаешься открыть глаза или что?

Я тебе пытаюсь объяснить, что на поведение конкретной реализации когда в стандарте явно указан UB полагаются только говнокодеры, которые пишут программы для себя или пишут проприетарное говно, которое кроме них никто нигде компилировать не будет.

банальным доводом «твой код не имеет смысла»

Я тебе пример из ядра FreeBSD приводил. Про realloc с хабра просто пример был для иллюстрации того, что поведение при UB не обязано быть логичным. Зачем ты к нему прицепился?

monk ★★★★★
()
Ответ на: комментарий от PotentialCppTsar

Стандарт допускает эквивалентность входящего и исходящего значения указателя. Поэтому тут noalias обделался и не соответствует стандарту.

Хм. Тут юридическая неопределённость. Примерно как в коде

int *q, *p;
p = malloc(sizeof(int));
free(p);
q = malloc(sizeof(int));
*q = 1;
*p = 2;  // здесь UB или нет?
printf("%i %i\n", *p, *q);

Теоретически, malloc может вернуть только что освобождённый адрес (который совпадёт с p), но на практике обращение к p после free всё равно всегда является UB.

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от PotentialCppTsar

return (getpid() << 16) ^ tv.tv_sec ^ tv.tv_usec ^ junk;

Тут рандомное значение, которое случайно вышло 0

Чтобы тут «случайно» вышло 0, junk должен быть равен (getpid() << 16) ^ tv.tv_sec ^ tv.tv_usec. Причём заметь, там два вызова, но junk всегда магически подбирается под tv.tv_usec так, чтобы всё равно был 0.

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

То есть, ты пишешь не на Си, а на языке, который компилируется gcc-5.2.1 при -O0, например?

Уважаемый балабол - я пишу код, который компилируется нормальным конпилятором в то, что решил я.

Твои -O0 меня не интересуют.

Ты знаешь поведение конкретного компилятора

Существует только один конпелятор.

конкретной версии

Версии конпеляторов ничем не отличчаются. Опять балабол рассуждает о том, в чём нихрена не понимает.

на конкретной платформе

Поведение конпелятора и сишка никакого отношения к платформе не имеет.

В этом мире существует только одна софтварная и одна аппаратная платформа, которая позволяет писать качественный код. Мусор меня не интересует.

с определённой комбинацией флагов компиляции.

Опять эти ламерский мифы и легенды. Какие комбинации - что ты несёшь.

Никакие комбинации на ни что не влияют. Есть сеты, которые везде едины, изменения в которых внятно описываются в чейнжлогах.

Мой код собирается так, как я сказал. Мнения нулей и их желания меня не интересует.

Впрочем, если тебя принципиально не интересует переносимость...

Переносимость - миф для ламерков. То дерьмо, что пишут балаболы - убогое и дырявое дерьмище, которое к переносимости не имеет никакого отношения.

Она переносимо и безопасно только в мифах и легендах - реально же это дерьмище просто не работает никогда и никак.

Это дерьмо, которая работает дерьмово за счёт готового переносимого рантайма и просто неиспользования ничего, кроме 386-го. И не пускается ни на чем, кроме 386-го.

Я тебе пытаюсь объяснить, что на поведение конкретной реализации когда в стандарте явно указан UB полагаются только говнокодеры, которые пишут программы для себя или пишут проприетарное говно, которое кроме них никто нигде компилировать не будет.

Уважаемый балабол - я знаю поведение матчасти и логику. Я могу предсказать поведение вменяемого конпелятора в 95% случаев, а там, где я не могу - я узнаю руками.

В этом и отличие между нами. Все твои проблемы меня не интересуют ибо у меня они не работают. Я работаю на уровне, в котором не бывает уб. Я не прячусь за абстрактным мусором - мне этого не надо. Я не покрываю проблемы в своих знаниях мифическими постулатами.

Я пишу код так, что я точно знаю во что он превратится. Мне не нужны ни твои убогие оптимизации, ни твои убогие конпеляторы и прочий мусор типа стандарта.

Я не пишу на на си - я пишу на гнуц и твои убогие стандарты для нулей - меня не волнуют. На ansi c ничего, кроме убогой лабы и дерявого дерьма не написать - ну никак.

Я тебе пример из ядра FreeBSD приводил.

Фрибзд пишут убогие ламерки, которые следуют твоим постулатам, но почему-то дерьмо у них в каждом их высере.

Ни один вменяемый человек на голой сишке писать не будет, а тот кто пишет - это его проблема.

Этот код написал убогий ламерюга, который нихрена в этом мире не понимает и такое дерьмо просто не котируется за внятный пример.

А уж либц от ламерков - просто смешно. Этим убожеством они могут только подтереться.

Про realloc с хабра просто пример был для иллюстрации того, что поведение при UB не обязано быть логичным. Зачем ты к нему прицепился?

Уб, вернее его поведение, с реллоком с хабра является абсолютно логичным, как и уб, которые описал ты.

Не логичным является поведение с циклом по статическому массиву. Тут я не смог предсказать его поведение. Только вот одна проблема - этот пример не имеет смысла, ибо код не имеет смысла.

Во вменяемом коде, который даже кладёт на уб - НИКОГДА не будет не логичного поведения, даже если там есть уб.

Любая вещь в этом мире работает на КОНКРЕТНОЙ логики - она не может быть неопределённой. Если логика есть - конпелятор будет ей следовать, а если знаю её я -для меня это будет ОПРЕДЕЛЁННОЕ поведение.

Все твои примеры с УБ являются дерьмом. Это изначально код, который не имеет смысла. Я почти не встречал влияние уб в НОРМАЛЬНОМ КОДЕ, который писался человеком и делал что-то осмысленное.

Все уб, которые могут встретиться в реальном коде - это уб вида «на откуп реализации», которая транслируется в «на откуп платформы». Я знаю как работает моя платформа - я знаю как работают все эти уб.

Второй тип уб - это трансформация выражений. Встречаются они в реальном коде редко, ибо все они следствие нарушения логики в коде, при этом нарушает его не уб.

PotentialCppTsar
()
Ответ на: комментарий от monk

Чтобы тут «случайно» вышло 0, junk должен быть равен (getpid() << 16) ^ tv.tv_sec ^ tv.tv_usec. Причём заметь, там два вызова, но junk всегда магически подбирается под tv.tv_usec так, чтобы всё равно был 0.

Ты нихрена не понимаешь. О божечки. Яж тебе уже показал, что нули там будут, даже если ты тупо уберёшь ретурн и junk и все tv и хоры. Они тут непричём.

Давай я тебе поясню:

//call abi rdi, rsi, rdx, rcx + return rax
	leaq	8(%rsp), %rdi//первый аргумент
	xorl	%esi, %esi//второй аргумент - ноль.
	callq	gettimeofday//вызов 2 аргумента, возврат не используется
	callq	getpid//вызов 0 аргументов
	leaq	8(%rsp), %rdi//аргумент первый
	xorl	%esi, %esi//второй ноль
	callq	gettimeofday//вызов
	callq	getpid//вызов
	movl	$.L.str, %edi//первый рагумент
	xorl	%eax, %eax
	callq	printf//вызов rsi(это второй аргумент gettimeofday, который быз занулён) + rdx(ноль потому что кто-то его занулил)
	xorl	%eax, %eax
	addq	$24, %rsp
	retq

Т.е. ноль во втором случая потому, что тут в первом ноль потому, что у тебя в gettimeofday второй аргумент ноль, а второй вызов ноль потому, что у тебя что-то зануляет rdx.

unsigned long test(void) {
  struct timeval tv;
  unsigned long junk;
 	
  gettimeofday(&tv, &tv);
  uint64_t r = (getpid() << 16) ^ tv.tv_sec ^ tv.tv_usec ^ junk;
  asm("movq $123, %rdx");//её зануляет getpid().
  return r;
}

Мы видим, что писал это типичный ламерок, который наслушался такой же убогой брехни, что и ты. Это днище решило, что в неинициализированной переменной какой-то мусор или рандом и решило это заюзать.

Но в шлангле баг/фича и он просто гинерит мусор, когда что-то зависит от неинициализированной переменной. Тут может быть всё, что угодно - даже форматц.

Квалификация этого адепта в районе помойки - его удел мести улицу.

PotentialCppTsar
()
Ответ на: комментарий от monk

чем отличаются dstr_prepend(str, val) и dst_insert(str, val, 0)?

тем что prepend вставляет в начало, append с конца, а insert после енного символа строки.

typedef struct dstring dstring_t;
Почему не «typedef struct dstring dstring;» ? А ещё лучше сразу > > «typedef struct { ... } dstring».

потому что это не я все в один файл засунул. раньше имплементация функций и сама структура была в .c, по этому я ее в .h тайпдефом переопределял.

maksspaces
() автор топика
Ответ на: комментарий от PotentialCppTsar

Но в шлангле баг/фича и он просто гинерит мусор, когда что-то зависит от неинициализированной переменной. Тут может быть всё, что угодно - даже форматц.

Вот! Это и есть UB по стандарту. И при доступе за пределы массива также генерируется мусор. И при разыменовании указателя, который был параметром у free.

monk ★★★★★
()
Ответ на: комментарий от PotentialCppTsar

Существует только один конпелятор.

И какой же? GCC? Тогда какой версии?

В этом мире существует только одна софтварная и одна аппаратная платформа, которая позволяет писать качественный код.

С учётом того, что мы на ЛОР, предполагаю, что софтварная — Linux. А аппаратная какая? Неужели Intel?

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от maksspaces

prepend вставляет в начало ..., а insert после енного символа строки

При наличии insert не нужен prepend. В принципе, при наличии insert и быстрого get_length и append не нужен. А вот вставить одну динамическую строку в другую у тебя вообще не предусмотрено. И получить обычную строку из динамической тоже.

monk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.