typedef void (* B)(C *);
typedef struct
{
[..]
B b;
} A;
typedef struct
{
[..]
A * a;
} C;
Уже битый час бьюсь, не могу понять, можно ли решить это нормальным способом. В C всего лишь указатель на A, поэтому скорее всего можно как-то задекларить.
Привет!
Такой вопрос: есть такая вещь как __attribute__ ((constructor)). Предположим я использую его в инициализации библиотеки. Потом использую его в приложении, которое использует эту библиотеку. Я правильно понимаю, что библиотечный ((constructor)) будет вызван раньше приложенческого? Отвечаю на вопрос, зачем мне это нужно - мне надо вызвать функцию библиотеки в инициализаторе приложения, а эта функция работать без инициализатора библиотеки не будет.
Нужен официальный пруф.
Вопрос номер два. А будет это работать в более сложной цепочке? A.so (init A) <- B.so (init B, related on A) <- C.elf (init C, related on B)
Minimal Code Example:
mkdir -p /tmp/libtest && echo -e "#include <stdio.h>\n\nint target = 10;\n\nstatic void target_init(void) __attribute__ ((constructor));\n\nstatic void target_init(void)\n{\n target = 50;\n}\n\nint target_return(void)\n{\n\n return target;\n}\n" > /tmp/libtest/lib.c && echo -e "#include <stdio.h>\n\nextern int target_return(void);\n\nstatic void main_init(void) __attribute__ ((constructor));\n\nstatic void main_init(void)\n{\n printf(\"main_init: %d\\\\n\", target_return())\n}\n\nint main(void)\n{\n printf(\"main: %d\\\\n\", target_return());\n return 0;\n}\n" > /tmp/libtest/main.c && gcc -fPIC -shared /tmp/libtest/lib.c -o /tmp/libtest/liblib.so && gcc main.c -o /tmp/libtest/main.elf -L. -llib && LD_LIBRARY_PATH=/tmp/libtest/ /tmp/libtest/main.elfНа текущей Intel® HD Graphics 520 можно нормально играть в Saints Row IV. Ну, думаю, со Starbound под онтопик проблем не будет. А фиг там:
Доходит до главного меню, потом зависание и вылет.
intel_do_flush_locked failed: Input/output error
Нагуглил что предлагают выставить хардкорный запрет аппаратного ускорения. Понятно, что современная игруля, какой бы примитивной графикой не обладала чисто на проце будет нещадно лагать даже в главном меню.
А адекватные методы решения есть?
Каждый раз при подключении нового монитора мы не создаем новый screen (:0.1), а расширяем нулевой до размеров nx(m1+m2), все равно имея при этом ровно один скрин :0.0.
Так что, ScreenCount не имеет смысла? Всегда будет 1?
Или все-таки имеет смысл обрабатывать мультискрин кейсы на случай если кто-то все таки починит Xы, чтобы они третировали все мониторы как разные скрины для корректной обработки dpi?
When you have two monitors, X treats them as one display with (DISPLAY=:0.0) with a big resolution
Wayland ловеры лесом.
i32 xxxx(const void * p1, const void * p2)
{
const u8 * p1_u8 = p1;
const u8 * p2_u8 = p2;
if (p1_u8 == p2_u8)
return 0;
if (p1_u8 == NULL)
return *p2_u8; // 403
if (p2_u8 == NULL) // 404
return *p1_u8;
V595 The 'p2_u8' pointer was utilized before it was verified against nullptr. Check lines: 403, 404.
Короче эта хреновина не в состоянии элементарно попеременно подставить NULL/val во входных данных как это делает cppcheck/clang-tidy.
Такие дела.
2018й, ракеты летают на Марс, виртуальная реальность уходит в массы, умные дома, киборги и пр..
Тем временем можно ли в линуксе узнать сколько в данный момент потребляет каждый конкретный блок? Например, насколько я уменьшу энергопотребление если прямо сейчас выключу Wi-Fi или экран.
xU16.04, в консоли ничего нет при этом (пробовал запускать его оттуда). Может не туда смотрю? Виснет напрочь, может простоять час, потом зависнуть, может через пять минут.
Делаю в скрипте
# Скрипт запущен от рута\sudo. Надо дать пользователю его шелл
su $user -c /bin/shПолучаю шелл и в прибавку к нему: «/bin/sh: 0: can't access tty; job control turned off».
Если запустить что-то и сделать ^C, то все поломается нафиг:
/bin/sh: 0: can't access tty; job control turned off
$ ping ya.ru
PING ya.ru (87.250.250.242) 56(84) bytes of data.
64 bytes from ya.ru (87.250.250.242): icmp_seq=1 ttl=54 time=27.1 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=2 ttl=54 time=28.6 ms
^C
Сеанс завершён, выполняется завершение оболочки…
--- ya.ru ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 27.149/27.897/28.646/0.766 ms
$ exit
… ожидает завершения потомка.
Так что не работает.
В инете такую штуку нашел только если ОСь не грузится или когда делают sh /dev/console. Тут просто sh. Как лечить?
Xubuntu 16.04
Почему функции
char *strpbrk(const char *s, const char *accept);
char *strstr(const char *haystack, const char *needle);
char *strcasestr(const char *haystack, const char *needle); // GNU
char *strchr(const char *s, int c);
char *strrchr(const char *s, int c);
Что теперь делать, куда бечь? Сбежал с adblock+ из-за того, что он не блочил vk-related рекламу, теперь все вернулось взад.
./code/test/utils/bximemutils.c
defines:
defined: BX_MEM_NONE: 0x000000
defined: BX_MEM_ZERO: 0x000001
functions:
checking: bxi_memopt_set
checking: bxi_memerr_set
checking: bxi_malloc_set
checking: bxi_malloc
checking: bxi_realloc_set
checking: bxi_realloc
checking: bxi_free_set
checking: bxi_free
checking: bxi_memset
speedtest: memset : 0.01649
speedtest: bxi_memset : 0.04130
checking: bxi_memcpy
speedtest: memcpy : 0.01038
speedtest: bxi_memcpy : 0.04120
checking: bxi_memmove
speedtest: memmove : 0.01202
speedtest: bxi_memmove : 0.04034
checking: bxi_memcmp
speedtest: memcmp : 1.63799
speedtest: bxi_memcmp : 0.58350
checking: bxi_memfrob
speedtest: memfrob : 0.07995
speedtest: bxi_memfrob : 0.08031
checking: bxi_memchr
checking: bxi_memrchr
PASSED
tk@pro7:/tmp/git/codemeow/bixi/bin
$ head -10 /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz
stepping : 9
microcode : 0x12
cpu MHz : 3300.000
cache size : 8192 KB
physical id : 0
tk@pro7:/tmp/git/codemeow/bixi/bin
$ uname -a
Linux pro7 3.8.5 #4 SMP Mon Oct 9 18:48:32 MSK 2017 i686 Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz GenuineIntel GNU/Linux
$ ls -l /lib/libc-2.11.1.so
-rwxr-xr-x 1 root root 1649149 2010-05-13 10:55 /lib/libc-2.11.1.so*
Реп: https://github.com/codemeow/bixi (сборка ./scripts/build.sh release, бинари будут в bin)
Как это можно объяснить?
Образ с офсайта, dfly-x86_64-5.0.1_REL.iso
Виртуалка из реп Ubuntu 16.04 - 5.0.40_Ubuntu r115130
Камень Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, виртуализация в бивисе включена (без нее вообще сразу после запуска виртуалки Guru Meditation
В простом режиме (Boot kernel) оно не грузится совсем, виснет на kbd0 at atkbd0.
Пытается грузиться дальше только если грузить в safe mode или без дров ACPI/AHCI.
Однако через пару секунд
Mounting devfs
DOUBLE FAULT
<..>
panic: lockmgr vm_maplk from 0: called from interrupt, ipi, or hard code sectionСкрин гугла по проблеме: https://s1.postimg.org/9frgq6pupb/2017-11-08_14-31-44.png
Чем лечить? Хочу ее потыкать.
Из-за -Werror он стопорит компиляцию. Прописал -Wno-error=unused-command-line-argument, но это не выход, так как все равно срет в stderr и внешняя система воспринимает это как ошибку. Обращу внимание, что это не на необработанный аргумент функции, а «лишний» по мнению кланга аргумент строки компиляции, конкретно тот, который задает место где надо искать библиотеки: -Lxxx. https://ibb.co/bYioHb . Вообще зачем нужно было это (предупреждение) делать, ни один другой компилятор не говорит о «лишних» параметрах.
На новых linux системах по умолчанию grep по умолчанию --color=auto
На новых маках grep по умолчанию --color=always
Ну ок, смирился, ставлю в скрипте принудительно --color=never, все работает.
Включаем старую систему:
grep: unknown option -- color=neverUPD
Разрулил через
grep-flag-available() {
echo | grep $1 "" >/dev/null 2>&1
}
GREP_OPTIONS=""
if grep-flag-available --color=auto; then
GREP_OPTIONS+=" --color=auto"
fi
Перемещено tailgunner из development
Как наиболее переносимым образом проверить, установлена ли нужная утилита?
Ну то есть:
Md5Calc()
{
# Minix : md5 -n $1
md5sum $1
}
P.S. Вопрос на засыпку, реально ли похожий fallback устроить в шебанге? /bin/bash vs /usr/pkg/bin/bash
MWE:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
typedef unsigned char u8;
typedef unsigned int u32;
#define GB (1024ul * 1024ul * 1024ul)
#define TEST_SIZE (10)
int zerofy = 1;
static u8 * alloc(u32 size)
{
u8 * res = calloc(size, 1);
if (!res)
{
printf(" * Cannot alloc %u bytes\n", size);
return NULL;
}
else
{
printf(" * Allocated %u bytes [%p]\n", size, res);
}
if (zerofy)
memset(res, 0, size);
return res;
}
static void rapemem(u32 zero)
{
u32 i;
u8 * p[TEST_SIZE];
printf("Switching zerofy to %u\n", zero);
zerofy = zero;
for (i = 0; i < TEST_SIZE; i++)
p[i] = alloc(GB);
for (i = 0; i < TEST_SIZE; i++)
free(p[i]);
}
int main(void)
{
system("free -mh");
printf("\n\n");
rapemem(0);
rapemem(1);
rapemem(0);
return 0;
}
Выхлоп:
alex@alex-thinkpad-l560:~/Разработка/C/Tests/calloc$ gcc -std=c89 poc.c
alex@alex-thinkpad-l560:~/Разработка/C/Tests/calloc$ ./a.out
total used free shared buff/cache available
Память: 7,6G 2,1G 4,2G 396M 1,2G 4,8G
Подкачка: 0B 0B 0B
Switching zerofy to 0
* Allocated 1073741824 bytes [0x7fe248a9b010]
* Allocated 1073741824 bytes [0x7fe208a9a010]
* Allocated 1073741824 bytes [0x7fe1c8a99010]
* Allocated 1073741824 bytes [0x7fe188a98010]
* Allocated 1073741824 bytes [0x7fe148a97010]
* Allocated 1073741824 bytes [0x7fe108a96010]
* Allocated 1073741824 bytes [0x7fe0c8a95010]
* Allocated 1073741824 bytes [0x7fe088a94010]
* Allocated 1073741824 bytes [0x7fe048a93010]
* Allocated 1073741824 bytes [0x7fe008a92010]
Switching zerofy to 1
* Allocated 1073741824 bytes [0x7fe248a9b010]
* Allocated 1073741824 bytes [0x7fe208a9a010]
* Allocated 1073741824 bytes [0x7fe1c8a99010]
* Allocated 1073741824 bytes [0x7fe188a98010]
* Cannot alloc 1073741824 bytes
* Cannot alloc 1073741824 bytes
* Cannot alloc 1073741824 bytes
* Cannot alloc 1073741824 bytes
* Cannot alloc 1073741824 bytes
* Cannot alloc 1073741824 bytes
Switching zerofy to 0
* Allocated 1073741824 bytes [0x7fe248a9b010]
* Allocated 1073741824 bytes [0x7fe208a9a010]
* Allocated 1073741824 bytes [0x7fe1c8a99010]
* Allocated 1073741824 bytes [0x7fe188a98010]
* Allocated 1073741824 bytes [0x7fe143fff010]
* Allocated 1073741824 bytes [0x7fe103ffe010]
* Allocated 1073741824 bytes [0x7fe0c3ffd010]
* Allocated 1073741824 bytes [0x7fe083ffc010]
* Allocated 1073741824 bytes [0x7fe043ffb010]
* Allocated 1073741824 bytes [0x7fe003ffa010]
WTF вообще? Теперь и calloc выделению доверять нельзя? Да здравствуют SIGSEGV без вариантов проверить выделение?
Я знаю про оптимистичное выделение, но всю жизнь эта ботва была только с malloc, calloc от этой херни был свободен так как занулял память.
Есть некий скрипт, который нужно дернуть из Си-кода. Проблема в том, что скрипт принимает 4 параметра:
script.pl 5 "text 1" 20 "text 2"В си коде выглядит как-то так (выхлоп скрипта не нужен в принципе):
void ticket_create(u32 code, const char * text, i32 len, const char * file)
{
char buffer[32768];
sprintf(buffer,
"script.pl %d \"%s\" %d \"%s\"",
code, text, len, file);
PrintInfo(0, "Going to create ticket: \"%s\"", buffer);
system(buffer);
}
/// 1
char buffer1[1000];
char buffer2[1000];
sprintf(buffer1, "Spl rewind failed in hall %d as SPL \"%s\" in CPL \"%s\".<br>",
Hall(devindex), target_splid, target_cplid);
sprintf(buffer2, "/tk/dd24/log/ctms/hall_%d.log", Hall(devindex));
ticket_create(TICKET_REWIND_FAILED, buffer1, 10, buffer2);
/// 2
char buffer1[1000];
char buffer2[1000];
sprintf(buffer1, "Can't find 'ShowPlaylist.Id' in SPL. SPL's splid is %s in hall %d.",
splid, Hall(devindex));
sprintf(buffer2, "/tk/dd24/log/ctms/spls/%d/%s/%s.xml", Hall(devindex), hr_time(10), splid);
ticket_create(TICKET_SPL_NOID, buffer1, -1, buffer2);
/// 3
char buffer1[1000];
char buffer2[1000];
sprintf(buffer1, "Serials mismatch in hall %d: \'%s\' (db) and \'%s\' (device).",
devicesdb.devices[devindex].hallid,
devicesdb.devices[devindex].serial, serial);
sprintf(buffer2, "/tk/dd24/log/ctms/protocol-%d.log",
devicesdb.devices[devindex].hallid);
ticket_create(TICKET_SERIAL_WRONG, buffer1, 50, buffer2);
Есть идеи?
Скажем у вас есть проект А, в которым вы юзаете в разное время написанные B и C, а потом еще подключаете стороннюю библиотеку D.
По историческим причинам у них у всех разные коды возврата ошибки (например A_init_convo(type_t type) возвращает 342 в случае если сокет недоступен, или B_send_transmission(u8 * data, u32 size) вернет 24 если data = NULL).
Делаете ли какие-либо обертки? У нас, например, есть проект (который пока что без внешних зависимостей, только наши либы, у которого особым образом регистрируются коды ошибок с описанием (связка функций error_register + XMACRO).
Использовал case X ... Z: https://s26.postimg.org/o78wqrs8p/2017-09-24_12-41-54.png
Переписал на case X : case Y: case Z: https://s26.postimg.org/t76cypxvd/2017-09-24_12-49-08.png
Отчего все так плохо? Я думал что он тупо при компиляции виртуально раскроет X ... Z в case X: case Y: case Z, а он просто судя по всему там вместо switch/case if'ы мутит.
Еще конструкция:
case C_MOVE_LT : command_move(ant, command); break;
case C_MOVE_T : command_move(ant, command); break;
case C_MOVE_RT : command_move(ant, command); break;
case C_MOVE_L : command_move(ant, command); break;
case C_MOVE_R : command_move(ant, command); break;
case C_MOVE_LB : command_move(ant, command); break;
case C_MOVE_B : command_move(ant, command); break;
case C_MOVE_RB : command_move(ant, command); break;
case C_PICK_LT : command_pick(ant, command); break;
case C_PICK_T : command_pick(ant, command); break;
case C_PICK_RT : command_pick(ant, command); break;
case C_PICK_L : command_pick(ant, command); break;
case C_PICK_R : command_pick(ant, command); break;
case C_PICK_LB : command_pick(ant, command); break;
case C_PICK_B : command_pick(ant, command); break;
case C_PICK_RB : command_pick(ant, command); break;
Выполняется в два раза быстрее чем
case C_MOVE_LT :
case C_MOVE_T :
case C_MOVE_RT :
case C_MOVE_L :
case C_MOVE_R :
case C_MOVE_LB :
case C_MOVE_B :
case C_MOVE_RB : command_move(ant, command); break;
case C_PICK_LT :
case C_PICK_T :
case C_PICK_RT :
case C_PICK_L :
case C_PICK_R :
case C_PICK_LB :
case C_PICK_B :
case C_PICK_RB : command_pick(ant, command); break;
Так, как делают некоторые системные функции. Чтобы внутри есть статический буфер, куда какая-нибудь функция складывает свой результат, но чтобы если ее вызвали из другого потока она не перекрыла результат первого.
В голову идет только динамический массив структур, каждая из которых содержит буфер и thread_id. И каждый раз при обращении проверять, если такой тред и если нет - расширять массив, и выдавать новый буфер. Минусы - не почистится буфер при выходе и анализаторы будут гудеть. Еще время поиска, когда много тредов оно в теории может быть менее выгодно чем malloc/free.
Как это реализуют нормальные люди? Количество тредов не определено, может быть 5, может быть 50, может быть 500.
| ← назад | следующие → |