Zoro (06.12.2019 10:42, просмотров: 420) ответил POV_ на Так оно уходит в никуда при пошаговой работе. Соседние строчки с тем же sprintf норм работают.-
- Не, такого что нет. А вот что есть... POV_(228 знак., 06.12.2019 11:39,
)
- default может добавить？ в Винавр помогало。 - Symbions(06.12.2019 13:24)
- бубен эффективнее - SciFi(06.12.2019 13:31)
- Нет, но не помешает попробовать Symbions(35 знак., 06.12.2019 17:47 - 17:49)
- Не нашёл, а спрятал. SciFi(50 знак., 06.12.2019 17:50, ссылка)
- Нет, но не помешает попробовать Symbions(35 знак., 06.12.2019 17:47 - 17:49)
- бубен эффективнее - SciFi(06.12.2019 13:31)
- В дизассемблере по шагам пройдись. Указатель стека проверь. - SciFi(06.12.2019 11:48)
- В общем сам "дурак", дал шанс компилятору при оптимизации повертеть меня на херу... POV_(534 знак., 06.12.2019 15:11, )
- Основной вопрос в этом коде - это где хранится результат внутренних sprintf после возвращения из функции psu_GetField. Ведь переменным bb присваиваются указатели на некий буфер. Если это глобальный буфер, то последовательные вызовы psu_GetField PSP(148 знак., 08.12.2019 20:28)
- Там всё в порядке - POV_(08.12.2019 21:40, )
- Там всё в порядке - POV_(08.12.2019 21:40,
- Проблема при вложенности функций указывает в первую очередь на проблему со стеком. - VLLV(07.12.2019 05:00)
- про вложенность --> - SciFi(07.12.2019 13:44, ссылка)
- Автор пишет черным по черному: "Внутри psu_GetField есть свой sprintf, а то и два" - VLLV(07.12.2019 14:58)
- Предлагаю подумать на тему "как в рамках одного потока осуществить вложенный вызов sprintf?" SciFi(35 знак., 07.12.2019 15:33)
- С одной стороны - торможу, земляные работы отбили разум. А с другой стороны ... ну неужели расход стека не зависит от действий программиста? - VLLV(07.12.2019 16:02)
- Зависит. Он и от настроек оптимизации зависит. Но поциент упорно игнорирует этот факт. Кто ж ему дохтур? - SciFi(07.12.2019 16:35)
- Да ничего я не игнорирую. Я ж не говорю "гцц косячит". Просто крайне редко сталкивался с зависимостью работы компилятора от космических флуктуаций. - POV_(07.12.2019 16:39, )
- Современные оптимизирующие компиляторы -- коварны. Они могут видеть, что ты написал какую-то лажу. Понимать это, по своему, мол код всё равно не работает, и нагенерировать в итоге что-то другое. При этом ни слова не скажут. Видеть могут глубоко, fk0(41 знак., 09.12.2019 23:52)
- Оптимист. Ежели -flto, то видят вообще всё. - SciFi(10.12.2019 00:09)
- Я сталкивался. Потом находил косяки в своём коде. Например, что-то где-то гадит в чужие переменные. Через косячную адресную арифметику или ещё как-то. Всего и не упомню. - SciFi(07.12.2019 16:41)
- Современные оптимизирующие компиляторы -- коварны. Они могут видеть, что ты написал какую-то лажу. Понимать это, по своему, мол код всё равно не работает, и нагенерировать в итоге что-то другое. При этом ни слова не скажут. Видеть могут глубоко, fk0(41 знак., 09.12.2019 23:52)
- Да ничего я не игнорирую. Я ж не говорю "гцц косячит". Просто крайне редко сталкивался с зависимостью работы компилятора от космических флуктуаций. - POV_(07.12.2019 16:39,
- Зависит. Он и от настроек оптимизации зависит. Но поциент упорно игнорирует этот факт. Кто ж ему дохтур? - SciFi(07.12.2019 16:35)
- С одной стороны - торможу, земляные работы отбили разум. А с другой стороны ... ну неужели расход стека не зависит от действий программиста? - VLLV(07.12.2019 16:02)
- Предлагаю подумать на тему "как в рамках одного потока осуществить вложенный вызов sprintf?" SciFi(35 знак., 07.12.2019 15:33)
- Автор пишет черным по черному: "Внутри psu_GetField есть свой sprintf, а то и два" - VLLV(07.12.2019 14:58)
- про вложенность --> - SciFi(07.12.2019 13:44, ссылка)
- А внутри psu_GetField, когда вызывается sprintf, он печатает случайно не в ту же статическую переменную, в которую печать происходит в той функции, где глюки были обнаружены? Тогда чего же ты хочешь? snprintf начинает читать из буфера и fk0(771 знак., 06.12.2019 20:21)
- есть у меня подозрения, что либа со спринтфом настолько "однопоточная", что там даже просто для sprintfa используется какая-нить static переменная, в которой, например, хранится счётчик выведенных байт. в итоге при вложении спринтфов вложеннные Mahagam(128 знак., 07.12.2019 12:36)
- Где там вложенность? sprintf вызывается последовательно жи. Как вообще организовать "вложенный вызов sprintf" в одном потоке? Хочу всё знать. - SciFi(07.12.2019 12:46)
- читайте внимательно что пишет ТС, там как раз есть вложенность - Mahagam(07.12.2019 12:58, ссылка)
- Где там вложенность? sprintf вызывается последовательно жи. Как вообще организовать "вложенный вызов sprintf" в одном потоке? Хочу всё знать. - SciFi(07.12.2019 12:46)
- Нет, там массив "строк". А именно 5 штук. И вызывается не более 3 за раз... POV_(115 знак., 07.12.2019 02:05, )
- Но почему при присваивании возвращаемых psu_GetField значений временным переменным эффект пропал? Хотя вопрос, откуда psu_GetField берёт буфер для sprintf, весьма уместен. - йцукен(06.12.2019 22:07)
- А что буфер? Выполнение последовательное, никто никому не мешает. Выдумки, короче. - SciFi(06.12.2019 22:20)
- Может и выдумки, но поскольку я в чудеса не верю, должно быть материальное объяснение. Вынеся вызовы psu_GetField из вызова sprintf в отдельные строчки, ТС (возможно) изменил порядок, в котором следуют эти вызовы. Поскольку внутренности йцукен(100 знак., 06.12.2019 23:31)
- Содержимое буфера передаётся в printf не по значению, а по ссылке. В итоге когда функция печатает в тот же буфер, который является одним из аргументов -- аргумент рискует стать бесконечным. Там конечно начинаются ньюансы. Считает ли sprintf внутри fk0(394 знак., 06.12.2019 22:34 - 22:38, ссылка)
- А что буфер? Выполнение последовательное, никто никому не мешает. Выдумки, короче. - SciFi(06.12.2019 22:20)
- есть у меня подозрения, что либа со спринтфом настолько "однопоточная", что там даже просто для sprintfa используется какая-нить static переменная, в которой, например, хранится счётчик выведенных байт. в итоге при вложении спринтфов вложеннные Mahagam(128 знак., 07.12.2019 12:36)
- Может и туплю, но как именно это объясняет глюки? - SciFi(06.12.2019 15:19)
- Ну он как-то наоптимизировал одинаковые куски кода... POV_(205 знак., 06.12.2019 15:28, )
- Приговор такой: вменяемое объяснение не найдено, багу удалось временно замести под ковёр, потом вылезет в другом месте. - SciFi(06.12.2019 15:36)
- Ну это да.. - POV_(06.12.2019 17:25, )
- Ну это да.. - POV_(06.12.2019 17:25,
- Приговор такой: вменяемое объяснение не найдено, багу удалось временно замести под ковёр, потом вылезет в другом месте. - SciFi(06.12.2019 15:36)
- Ну он как-то наоптимизировал одинаковые куски кода... POV_(205 знак., 06.12.2019 15:28,
- Основной вопрос в этом коде - это где хранится результат внутренних sprintf после возвращения из функции psu_GetField. Ведь переменным bb присваиваются указатели на некий буфер. Если это глобальный буфер, то последовательные вызовы psu_GetField PSP(148 знак., 08.12.2019 20:28)
- Это уж в понедельник. Пройдусь по асму. - POV_(06.12.2019 13:34, )
- а мне тут говорили, как крут gcc, все предупреждения. Ни фига он не умеет против погроммиста) - VLLV(06.12.2019 11:55)
- Придется, но ассемблер егойный не знаю, читать придется. - POV_(06.12.2019 11:54, )
- Ассемблера испугался. Найди в тырнете чит-лист на одну страницу, повесь перед носом. Ничего особенного там нет. - SciFi(06.12.2019 12:06)
- Да хрен с ним, ассемблером, вначале стек. Дерево вызовов, указатель, локальные переменные... Переместить этот свич в другое место, там работает? - VLLV(06.12.2019 12:00)
- В общем сам "дурак", дал шанс компилятору при оптимизации повертеть меня на херу... POV_(534 знак., 06.12.2019 15:11,
- default может добавить？ в Винавр помогало。 - Symbions(06.12.2019 13:24)
- Это частный случай "неопределённого поведения". В таких случаях gcc временами делает такое, что глаза на лоб лезут. А что? Имеет право. - SciFi(06.12.2019 10:48)
- Не, такого что нет. А вот что есть... POV_(228 знак., 06.12.2019 11:39,