Сейчас я пишу такой код:

	if( phonebookEntry->index < 0 && phonebookEntry->telNo && !phonebookEntry->name ){
		//только телефон
	}else if( phonebookEntry->index < 0 && phonebookEntry->telNo && phonebookEntry->name ){
		//телефон и имя
	}else if( phonebookEntry->index >= 0 && !phonebookEntry->telNo && !phonebookEntry->name ){
		//только индекс
	}else if( phonebookEntry->index >= 0 && phonebookEntry->telNo && !phonebookEntry->name ){
		//индекс и телефон
	}else if( phonebookEntry->index >= 0 && phonebookEntry->telNo && phonebookEntry->name ){
		//индекс, телефон и имя
	}else{
		//недопустимое сочетание
	}

И я заметил, что в каждом условном операторе сразу проверяется случая и подумал, а что если поступить вот так:

	unsigned int condition = 0;
	
	if( phonebookEntry->index >= 0 ) condition |= 1;
	if( phonebookEntry->telNo      ) condition |= 1 << 1;
	if( phonebookEntry->name       ) condition |= 1 << 2;

И дальше переменную condition запихнуть в switch или вообще использовать в качестве индекса в массиве указателей? Мой случай ещё пограничный, но если добавить ещё один параметр, то вариантов уже будет 16! Короче, степень двойки. Я один такой упоротый или такое где-нибудь применяется?

Не могу добиться от malloc возврата NULL!

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <time.h>

int main()
{
	clock_t tmstmp;

	tmstmp = clock();
	printf("clock = %ld\n", tmstmp);

	size_t gb24 = 24LU*1024*1024*1024;
	volatile unsigned char* pre_mem = malloc(gb24);
	for (size_t i = 0; i < gb24; i += sizeof(clock_t)) {
		*(pre_mem + i) = clock();
	}
	//uint_t offset = 0;
	//explicit_bzero(pre_mem, gb24);
	printf("starting the loop\n");
	tmstmp = clock();
	printf("clock = %ld\n", tmstmp);
	fflush(stdin);

	size_t counter = 0;
	for(;counter < 12345678;++counter) {
		//*(pre_mem + offset) = counter;
		//offset += (sizeof(counter));

		size_t mem_size = 64*1024;
		volatile unsigned char* mem = malloc(mem_size);
		for (size_t i = 0; i < mem_size; i+=sizeof(clock_t)) {
			*(mem+i) = clock();
		}
		if (NULL == mem) {
			printf("iter %lu: NULL\n", counter);
			break;
		} else {
			for (size_t i = 0; i < mem_size; i+=sizeof(clock_t)) {
				*(mem+i) = clock();
			}
			*(mem + counter%(4096)) = counter;
		}
	}

	return counter % 123456789;
}

У меня на машине 16ГБ озу и 32 свопа.

/tmp ❯❯❯ journalctl -k --since "-5 minutes" | grep -i -E 'out of memory|oom-killer|memory cgroup|Killed process'
Nov 16 18:09:49 g16 kernel: nvim invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0
Nov 16 18:09:49 g16 kernel: Out of memory: Killed process 428379 (a.out) total-vm:29233540kB, anon-rss:9961472kB, file-rss:724kB, shmem-rss:0kB, UID:1000 pgtables:57260kB oom_score_adj:0

если не инициализировать всю память, а только «местами», то краш случается, когда виртуальной памяти отдано уже 80-110 гигов.

Помогите получить от malloc NULL!!

А то что это получается, не надо чекать что там вернул malloc?

Кто-нибудь знает, были ли какие-то исправления в vscode/других ide по данной уязвимости? Или ещё какие-то подобные дыры.

Хотел по cve посмотреть было-ли что-то сделано, но cve на это дело не нашёл.

Привет, ЛОР!

В принципе, я считаю, Rust больше не нужен. В Си наконец завезли не только сабж, но и реализацию алгебраических типов да с паттерн матчингом на нём! Ну и там ООП с интерфейсами, вот это вот всё. Примеры кода ниже.

Факториал в функциональном стиле:

#define factorial(n)          ML99_natMatch(n, v(factorial_))
#define factorial_Z_IMPL(...) v(1)
#define factorial_S_IMPL(n)   ML99_mul(ML99_inc(v(n)), factorial(v(n)))

ML99_ASSERT_EQ(factorial(v(4)), v(24));

Алгебраические типы:

#include <datatype99.h>

datatype(
    BinaryTree,
    (Leaf, int),
    (Node, BinaryTree *, int, BinaryTree *)
);

int sum(const BinaryTree *tree) {
    match(*tree) {
        of(Leaf, x) return *x;
        of(Node, lhs, x, rhs) return sum(*lhs) + *x + sum(*rhs);
    }

    return -1;
}

Интерфейсы (почти как трейты в Rust):

#include <interface99.h>

#include <stdio.h>

#define Shape_IFACE                      \
    vfunc( int, perim, const VSelf)      \
    vfunc(void, scale, VSelf, int factor)

interface(Shape);

typedef struct {
    int a, b;
} Rectangle;

int  Rectangle_perim(const VSelf) { /* ... */ }
void Rectangle_scale(VSelf, int factor) { /* ... */ }

impl(Shape, Rectangle);

typedef struct {
    int a, b, c;
} Triangle;

int  Triangle_perim(const VSelf) { /* ... */ }
void Triangle_scale(VSelf, int factor) { /* ... */ }

impl(Shape, Triangle);

void test(Shape shape) {
    printf("perim = %d\n", VCALL(shape, perim));
    VCALL(shape, scale, 5);
    printf("perim = %d\n", VCALL(shape, perim));
}

Я считаю, на этом все попытки убить Сишечку можно закапывать. Ссылка: https://github.com/hirrolot/metalang99

Привет, ЛОР.

Старый добрый std::string, как мы знаем, это по сути char* на стероидах. А во многих случаях надо работать со строками именно как со строками текста.

К примеру, в библиотеке QtCore, входящей во фреймворк Qt, есть класс QString. Её часто ругают за изобретение велосипедов. Но именно благодаря этой «фабрике велосипедов» я могу написать, например, так:

QString s;
QStringList sl;
...
if (sl.contains(s, Qt::CaseInsensitive)) {
    ...
}

И оно мне проверит наличие строки в списке, причём регистронечувствительным (второй параметр) способом. И не только для латинских символов. То есть если в списке есть «Капибара», в строке подойдёт как «Капибара», так и «капибара». Ещё есть split(), join() и дофига полезного.

А как такое сделать без QtCore, на голом STL? В C++20 появился некий std::u8string, он мне поможет, например?

Простейшая шапка для документа, ориентированного на русскую типографику. Проверено на дистрибутиве TeX Live 2025. Кодировка по умолчанию юникодная.

( читать дальше... )

Есть код c++11:

#include <iostream>
#include <vector>

int main()
{
    std::vector<int> a{1,2,3,4,5,6,7,8,9};
    
    for(auto it=a.begin(); it!=a.end();)
    {
        if (*it % 2)
        {
            it=a.erase(it);
        }
        else
        {
            ++it;
        }
    }

    for(auto& i:a)std::cout<<i<<',';
}

Какая сложность алгоритма?)

( читать дальше... )

Тема создана для обсуждения DoubleContact — кроссплатформенного редактора/менеджера контактов для ПК. Программа написана на языке C++ с применением фреймворка Qt (минимальная версия Qt — 4.8, рекомендуемая — 5.10 и выше) и распространяется по лицензии GPLv3+.

Автор также планирует помещать здесь анонсы минорных версий DoubleContact, не заслуживающих новостей на главной.

На данный момент актуальная версия программы имеет номер 0.2.4 и работает с локальными адресными книгами. К ветке 0.4 планируется добавление работы с телефонами (ADB и др.), к ветке 0.5 — работа с сетевыми протоколами.

Github

Русский сайт автора

Архив новостей и форумных тем на ЛОРе

Уже больше 5 лет как использую разные GPU от AMD и сталкиваюсь с разнообразными проблемами, приводящими к его зависанию. К сожалению, в современном линуксовом десктопе, особенно на AMD зависание GPU зачастую не получается обработать прозрачно для софта. В лучшем случае могут попортиться данные, связанные с активными задачами, в худшем - gpu вообще становится неработоспособен до снятия питания (этим грешили некоторые APU на gfx9)

Успешный GPU Reset

Если в случае с неработоспособным GPU другого выхода, кроме как отказ от него нет, дискретные GPU обычно могут успешно пройти сброс.

На моём опыте, с rx580 это приводило к превращению всего содержимого VRAM в шум, на котором слегка можно было различить контуры ранее находившихся там текстур.

На rdna2 же обычно содержимое vram остаётся целым, однако не всегда. С некоторой вероятностью обнаруживается периодический мусор после сброса, обычно в этом случае попытка использовать работающие с GPU приложениями приведёт к повторному зависанию. В общем, никаких гарантий нет и по хорошему все GPU клиенты должны пересоздать все контексты с нуля

( читать дальше... )

Вышла вторая статья посвящённая эволюции развития языка Lua.

Анонс

• https://groups.google.com/g/lua-l/c/vFqmwv7uVCc/m/QG3LvdRODwAJ

Первая часть - 2007

• https://www.lua.org/doc/hopl.pdf

Вторая часть - 2025

• https://www.lua.org/doc/cola.pdf

Я ещё не читал, кому интересно, почитайте :)

---- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
(function(v) local f f = function(v) print(v) return f end return f(v)  end)
----------------------------------------------------------------------------
                                "Lua"
                                "Это"
                               "Весело!"
                              "Полезно!"
                             "Интересно!"
----------------------------------------------------------------------------
                  string.format("%s","hello world!")
---- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Всем бобра. Досвиданья.

Перемещено hobbit из general

19 марта состоялся выпуск C++ библиотеки Lug, реализующей встраиваемый предметно-ориентированный язык для выражения синтаксических анализаторов в виде расширенных грамматик синтаксических выражений, и распространяемой по лицензии MIT.

Возможности библиотеки:

• Естественный синтаксис, напоминающий языки внешних генераторов парсеров, с поддержкой атрибутов и семантических действий.
• Возможность работы с контекстно-зависимыми грамматиками с таблицами символов, условиями и синтаксическими предикатами.
• Сгенерированные парсеры компилируются в байткод и выполняются в виртуальной машине синтаксического анализа.
• Чёткое разделение синтаксических и лексических правил с возможностью настройки неявного пропуска пробельных символов.
• Поддержка прямой и косвенной левой рекурсии, с уровнями старшинства для разграничения подвыражений со смешанными левой и правой рекурсиями.
• Полная поддержка разбора текста в формате UTF-8, включая уровень 1 и частичное соответствие уровню 2 технического стандарта UTS #18 Unicode Regular Expressions.
• Обработка ошибок и восстановление с помощью помеченных сбоев, правил восстановления и обработчиков ошибок.
• Автоматическое отслеживание номеров строк и колонок, настраиваемая ширина и выравнивание табуляции.
• Header-only-библиотека, использующая только стандартную библиотеку и возможности стандарта C++17. Перспективно совместима со стандартами C++20 и C++23.
• Относительно небольшой размер библиотеки, с целью содержания общего количества строк во всех заголовочных файлах на уровне менее 6000 строк лаконичного кода.

( читать дальше... )

>>> Подробности на github.com

Привет, ЛОР!

Компания Galois Inc. представила Grease – программу для статического анализа исполняемых файлов и поиска в них уязвимостей. Grease дизассемблирует исполняемый файл и строит модель его исполнения, после чего анализирует пограничные условия на предмет возможных ошибок. Использовать Grease можно как отдельно, так и плагином к системе обратного инжениринга Ghidra.

Grease поддерживает анализ исполняемых файлов ELF и динамических библиотек, содержащих код ARMv7l, PowerPC или x86_64, а также может анализировать bitcode LLVM.

Код написан на языке Haskell и распространяется под лицензией BSD-3.

>>> Репозитарий на Github

>>> Подробности

Вступление

Данная статья написана с целью концентрации знаний о сжатии данных оперативной памяти.

Я использую gentoo, поэтому имена пакетов будут приводиться в формате этого дистрибутива.

Подразумевается, что читающий имеет желание и возможность (одно из):

• произвести конфигурацию и/или сборку ядра;
• в случае отсутствия искомой функциональности в «ванильном» - найти и использовать ядро, в котором уже всё есть.

( читать дальше... )

У меня есть указатель на uint8_t. Я знаю, что он выровнен по адресу 4. Я хочу быстро читать и писать туда uint32_t значение.

Правильный по стандарту вариант использовать memcpy, но он очень медленный.

Быстрый вариант - кастовать uint8_t * в uint32_t * и полагаться на то, что он выровнен. Это генерирует одну инструкцию, но это UB по стандарту, хотя по факту работать будет…

Как тут можно поступить? Меня интересует конкретный компилятор gcc 9.2. Может быть gcc даёт какие-то дополнительные гарантии сверх стандарта для данного случая?

Код:

#include <stdint.h>
#include <string.h>

void save1(uint8_t *p, uint32_t v) {
    memcpy(p, &v, 4);
}

void save2(uint8_t *p, uint32_t v) {
    uint32_t *p32 = (uint32_t *)p;
    *p = v;
}

uint32_t load1(uint8_t *p) {
    uint32_t v;
    memcpy(&v, p, 4);
    return v;
}

uint32_t load2(uint8_t *p) {
    uint32_t *p32 = (uint32_t *)p;
    return *p32;
}

Во что он компилируется с -Os:

save1:
        push    {r0, r1, r2, lr}
        mov     r2, #4
        str     r1, [sp, #4]
        add     r1, sp, r2
        bl      memcpy
        add     sp, sp, #12
        ldr     lr, [sp], #4
        bx      lr
save2:
        strb    r1, [r0]
        bx      lr
load1:
        push    {r0, r1, r2, lr}
        mov     r2, #4
        mov     r1, r0
        add     r0, sp, r2
        bl      memcpy
        ldr     r0, [sp, #4]
        add     sp, sp, #12
        ldr     lr, [sp], #4
        bx      lr
load2:
        ldr     r0, [r0]
        bx      lr

godbolt

Привет

Как ограничить процент зарядки на моем Asus TUF Gaming A16 Advantage Edition до 80%?

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

24 февраля, после более года разработки, состоялся выпуск 0.11.22 кроссплатформенной библиотеки захвата и воспроизведения звука miniaudio, написанной на языке C и распространяемой, как общественное достояние. miniaudio работает на всех основных настольных и мобильных платформах без сторонних зависимостей.

( читать дальше... )

>>> Список изменений на GitHub

Да, можно взять elasticsearch, postgres, что-то ещё. Но мы тут не про «взять», а про «запилить», development же.

Так вот, я ищу слово «дур». Хочу, чтобы находилось как в телеграме:

дурь
дурью
дури
дуру
дура

Возможно, «дурка», но вряд-ли - корень другой.

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

Вот давайте по-простому на уровне объяснения алгоритма школьнику.

Что можно сделать ДЛЯ НАЧАЛА? При индексации, когда мы смотрим на документ 12345 и встречаем слово «придурью» то мы берём корень и само слово. Далее пишем в индекс 2 такие записи и казалось бы достаточно.

придурью -> 12345,position
дур -> 12345,position

Идеи, возражения, уточнения? Пасиба. Просьба воздержаться от росказней о том как это сложно, страшно, какая это величайшая задача и кто такой автор сфинкса и как он классно травит байки со сцены на хайлоаде, давайте более приземлённо и по делу покритикуем мой минималистичный алгоритм, основной жопой которого будет вопрос о том, где взять корень слова по слову - это само по себе уже страшно без ваших страданий. Стеммеры там всякие, ага.

В С аргументы функции приводятся к типу указанному при объявлении т.е. если функция ожидает в качестве аргумента int, а передали, к примеру char, то произойдет неявное приведение char -> int

В С++ такой вариант уже не пройдет и компилятор выдаст ошибку.

Вопрос в следующем - существуют ли какие-то «стандартные» инструменты для С, запретить приведение, как в С++?

6 января состоялся выпуск 1.7.4 высокопроизводительной системы автоматического распознавания речи whisper.cpp, реализующей модель Whisper от OpenAI, написанной на языках C и C++ и распространяемой по лицензии MIT.

( читать дальше... )

>>> Список изменений версии 1.7.4 на GitHub

После более года разработки состоялся выпуск 0.8.3 библиотеки xxHash, реализующей высокопроизводительные некриптографические хэш-алгоритмы xxHash. Библиотека и консольная утилита написаны на языке C и распространяются по лицензии BSD 2.

Что нового:

• Исправлена ошибка в функции XXH3_128bits_withSecretandSeed(), приводящая к некорректным результатам в некоторых случаях.
• Добавлена оптимизированная реализация для LoongArch SX.
• Теперь консольная утилита xxhsum автоматически определяет и использует лучшее из доступных векторных расширений (SSE, AVX и т. д.). Ранее для этого требовалась явная опция сборки, но теперь она включена по умолчанию (отключается заданием DISPATCH=0).
• Также в утилиту xxhsum добавлен ключ --filelist / --files-from, принимающего имена файлов из текстового файла или stdin, упрощая массовое хеширование.
• Новый режим -H3 генерирует 64-битные хэши XXH3 с префиксом XXH3_, для отличия их от безпрефиксного XXH64. Симлинк xxh3sum по умолчанию использует этот режим.
• Проверка сборки для AIX и процессоров SPARC.

>>> Подробности для версии 0.8.3 на GitHub