Я ничего не помню, но это нормально, что string - массив char, а out - указатель на char? То есть нормально ли при этом отрабатывает strcpy?

Вот код где выводится строка gl_rendrer, дальше уже найти не могу.

static char *dup() { char string[5000] = {‘S’,‘o’,‘u’,‘r’,‘c’,‘e’,‘\0’};

char *out = malloc(strlen(string) + 1);

strcpy(out, string);

out[strlen(string)] = ‘\0’;

return out; }

static const char *get_vendor(struct pipe_screen *screen) { return dup(); }

static const char *get_name(struct pipe_screen *screen) { static char buf[100];

snprintf(buf, sizeof(buf), «%s %u.%u, %u %s», dup(),

        8, 0,

        128,

        dup());

return buf; }

strcpy всё равно на эти нули в конце. Он просто копирует до первого встречного нуля и ставит нуль в dst. Всё, не больше, не меньше.

А гредл просто тупой как одноименная билдсистема.

Он копирует string в out. В out - мусор. Копирует по длине string, которая = 7

string : 'lalala0'
out : 'xxxxxxxxxxxxxxx'
после strcpy получается
out : 'lalala0xxxxxxxx'
Предполагаю, что его конвертор съедает '0x' и получается говно.

Да нет блин здесь никакого конвертера, я же сказал, убрал его, посмотри на полный код выше

gl_rendrerer выводится в glxinfo нормально, а в wined3d в логах с лишними буквами в конце. gl_vendor проверить не могу, он нигде там не выводится

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

Wined3d:

(using GL_RENDERER «Source 8.0, 128 SourceX\x06»).

glxinfo:

OpenGL renderer string: Source 8.0, 128 Source

И ещё 4990 нулей. Наверняка - так наверняка.

Да, это нормально. string одновременно массив и указатель так сказать...

баг проявляется только в проприетарной программе в wine

Ну то есть косяк почти однозначно сделан ЗА ПРЕДЕЛАМИ изначально приведённого куска кода, как тебе три человека почти сразу и сказали.

Кто-то что-то не туда пишет. А последствия косяка могут проявляться, а могут и не проявляться. Закомментировал одну строку (ни в чём не виноватую) — память сдвинулась, и ошибка перестала быть фатальной.

Я бы порекомендовал погонять программу под valgrind, но если у тебя wine, а под ним ещё и нечто без исходников — то не знаю.

А зачем все эти танцы с бубном вокруг копирования если тебе просто надо вывести строку?

static const char* dup() { 
    return "Source"; 
}

static const char *get_vendor(struct pipe_screen *screen) {
    return dup(); 
}

static const char *get_name(struct pipe_screen *screen) { 
    static char buf[100];
    snprintf(buf, sizeof(buf), «%s %u.%u, %u %s», dup(), 8, 0, 128, dup());
    return buf; 
}

Мне надо массив преобразовать в char* а потом вернуть, я же декодировать буду

Source это заглушка, там должна строка генерироваться.

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

strdup – он делает тоже самое, то без этого косячества.

Я с него и начал, было тоже самое

При том что если я просто возвращаю «Source» без strdup/strcpy, такой проблемы нет.

Значит у тебя ошибка где-то совсем в другом месте.

Нет и точка, ошибок нигде больше нет, я объяснил почему

У тебя в dup() динамически память выделяется и нигде не освобождается.

Проверь кодировку исходника. Может ты копипастом вставил невидимые юникод символы в исходник? В твоём сообщении кавычки странные. Перепиши руками.

На глаз никаких проблем. Ещё можешь проверить код возврата функции snprintf должен быть больше нуля и содержать количество записанных байт.

Нет, с кавычками и невидимыми символами всё в порядке

//тут после символов лежит мусор, не забывай
char string[5000] = {‘S’,‘o’,‘u’,‘r’,‘c’,‘e’,‘\0’};


char *out = malloc(strlen(string) + 1);
memset(out,'\0',strlen(string)+1);// заполни весь кусок нулями потом копируй
strcpy(out, string);

Для выделения можно использовать calloc() он инициализирует выделенную память нулями, но без гарантий.

Ради скорости порой можно не очищать буферы памяти, но только тогда когда ты точно знаешь что делаешь. В случае неопределённости, разная используемая длинна и тому подобное любую память, от malloc/calloc после получения заполняй одним значением, в случае букавок заполняй нулями дабы получать везде где данные не используются конец строки. В случае неожиданностей (ты напутал индексы или ещё что) ты можешь ради теста заполнить данные например символом ‘A’ и выявить то где ты не прав и на косячил.

Помни в си ты оперируешь просто блоками памяти.

1 - Получил/зарезервировал память, сохранил размер памяти

2 - Заполнил(очистил) память определённым значением

3 - Можно использовать память при этом всегда контролируй размер обращения к ней

Ну если ты так уверен, то о чём тред тогда? Ошибки нет, расходимся.

Именно в куске начала треда ошибок нету. Совсем. Этот код должен работать правильно. Что то происходит в другом месте, запускай анализаторы, смотри что происходит с твоими данными итд. Можешь попробовать собирать либу без оптимизаций.

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

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

X\x06 как это вообще расшифровывается?

Это мусор, ты читаешь больше данных чем хочешь прочесть, не проставлен \0 в конце данных для функций работающих с символами или ты явно читаешь по идексу который больше чем нужен. Но раз ты говоришь что у тебя ошибок нет и точка то про что разговор? Значит баг компилятора/процессора… Ой ли? Ищи свою ошибку усерднее.

Я говорил про wined3d

Пропустил, ща перечитаю

Вот код где выводится строка gl_rendrer, дальше уже найти не могу.

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

Тебе уже писали — оформляй код как положено. Если у тебя форматирование через лоркод, заключай его в [code], если маркдаун — в пару из трёх апострофов.

Ни разу fail не выведет

не в дебаг режиме хоть собрал? в нем действительно везде нули будут

У меня лоркод недоступен

Подскажи хотя бы, как вывести в printf строку с мусором? Она в моей тестовой программе выводится без мусора, в glxinfo тоже, а в wined3d с мусором. В норме wined3d выводит нормальную строку, если я ничего не преобразовывал.

Мне надо повторить такую же ситуацию как в wined3d в моём printf, иначе нет смысла что-то искать, когда библиотека компилится 10 минут.

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

Странно

А у меня доступен, даже под анонимусом:

int main()
{
    return 0;
}

Видишь, при добавлении комментария над редактором комментария есть комбмбокс «Разметка»? Вот в нём выбираешь один из вариантов, под комментарием есть ссылки на инструкции по их применению.

// Разлогинившийся hobbit

P.S. Запомните, твари --- Я НЕ РОБОТ!!! (ТС, это не тебе, если что...)

memset(out,'\0',strlen(string)+1);// заполни весь кусок нулями потом копируй
strcpy...

Не надо с умным видом генерить длинный бред. Не нужен тут memset, о чём тут в треде уже даже проговорено.

Не надо с умным видом генерить длинный бред.

Не надо с умным видом пологать что ТС делает всё именно так как говорит, сейчас он сделает запись в буфер строки размером в половину буфера и там не будет на конце ‘\0’ и снова траблы.

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

Я говорю не с умным видом, а с синяками. Очищать надо, всегда и всё по возможности чтобы потом не «Ой а mingw под wine делает не совсем так как gcc под linux! Вот внезапность!»

Если ты не можешь контролить то где поставить ноль, то скорее всего и размер тоже отконтролить не можешь. Чет в стиле заметывания мусора под ковер.

Если ты не можешь контролить то где поставить ноль

wine

Привет

 len = vsnprintf(NULL,0,fmt,args);
 ...
 buff[len+1]='\0';

Который в linux gcc вернёт размер построенной строки из аргумертов, а в wine mingw, mingw cross на linux или SDL_vsnprinf() вернёт нуль. Вот и кек, лол. Как так и куда копать. Новичок на подобном просто сломается. Это только один пример, подобного тонна.

Я выше написал если всё однозначно то не надо ничего занулять, но если есть непонятки и уж тем более где-то явно вылез мусор, то занули и глянь явно где косяк. Никакие gdb не впёрлись залил в буфер явно и всё сразу видно. А если не видно то сразу понятно что дело в чём то другом.

Сехмент фаулт не волнует? Или у тебя буфер бесконечный?

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

int len = 0;
char *  buffer = malloc(sizeof(char) * (len = vsnprintf(NULL,0,fmt,args)+1)  );
vsnprintf(buffer,len,fmt,args);
buffer[len]='\0';

Конечно и тут проверки нужны, но всё же.

Я к тому что зануление лишь маскировка проблемы. Пусть лучше все кряхтит и падает сразу, что бы потом не искать.

Я к тому что зануление лишь маскировка проблемы

Салютую, да.

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

Да, пусть падает, но когда я вижу в выхлопе «!!!!!+asdf/as+df/5» я хоть догадаюсь где у меня буфер заполненный ! я во про это.

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

Дык стектрейс же все покажет.

Частично помогло, только в memset я удалил +1 на всякий случай (в dup), get_name оставил как у тебя было.

Теперь наоборот:

wined3d:

(using GL_RENDERER «Source 8.0, 128 Source»)

glxinfo:

OpenGL renderer string: Source 8.0, 128 SourceX

Что за икс появился понятия не имею, зато в wined3d он исчез.

Мы про ТС говорим, он ничего трассировать и отлаживать не будет.

Опять же, отстань я эстет и свои буфера держ чистыми! А твои буфра чистые? :D Всё, я чай пить пошёл с печеньками, тут уже скучно.

К слову. Помнишь я демку обещал? Уведомляю техно демка будет в виде крайтековской sponza https://www.youtube.com/watch?v=14rV1JkpC2M как основы ^.^ Там и освещение удобно бенчить, проверять и физику и анимации и партиклы и прочее.

Я говорю не с умным видом, а с синяками.

Дык, опять понаписали длинный бред. Если я хочу, чтобы строка скопировалась, то я и пишу strcpy, если я хочу сформировать строку по формату, то sprintf. Не появиться нулю на конце да еще «а завтра» равнозначно высказыванию, что давайте на каждом шаге проверять, а не сбойнула ли ячейка памяти от пролетевшего мимо нейтрона и стало 2+2=5. Так вам понятнее? Я честно старался вам подражать.