Почему Кодан не может найти size_t

Я только что начал использовать Eclipse Indigo (из Galileo) и получаю маленькие красные жучки в канаве для каждого использования size_t.

enter image description here

Код компилируется без проблем, но я подозреваю, что должен явно добавить путь к каталогам включения. У меня уже есть обычные подозреваемые там. Я выполняю кросс-компиляцию для процессора ColdFire, используя цепочку инструментов Gnu, так что в дополнение к стандартному include из mfg чипа, который у меня есть include под m68k-elf

<code>\include  
\include\c++\4.2.1
\include\c++\4.2.1\include
\include\c++\4.2.1\m68k-elf
</code>
Update

Я заметил, что единственное место, где существует stddef.h для этого набора инструментов, находится вlib каталог

<code>gcc-m68k\lib\gcc\m68k-elf\4.2.1\include
</code>

Я добавил этот путь, родительский путь и\include-fixed от родителя, но проблема все еще существует.

Note on testing

При тестировании, что работает, а что нет, я заметил несколько вещей

Code analysis does not get re-triggered when modifying Code Analysis preference settings, I still need to make an editor change (simply adding a space works) Turning off the Code analysis setting for Symbol is not resolved will not make the error go away. Turning off all Syntax and Semantic Errors, triggering the analysis, going back in and turning them all back on and then turning off Symbol is not resolved keeps the error from reappearing.

Ответы на вопрос(5)

size_t вам следует#include заголовок<cstddef>; тогда это будетstd::size_t, если вы также не положилиusing namespace std илиusing std::size_t.

 Tod10 апр. 2012 г., 21:49
Спасибо, но это не помогло. Я включил cstddef, добавил пространство имен std ::, перекомпилировал и не обнаружил ошибок компилятора, но все еще с ошибкой в красном желобе от Codan.

Если ваш набор инструментов может скомпилировать код только с включенными по умолчанию путями и символами, достаточно просто настроить Eclipse для их использования. Идти кC/C++ Build -> Discovery Options в свойствах проекта и для каждого языка изменитеCompiler invocation command из собственного компилятора (например,g++) к вашему кросс-компилятору (например,C:\nburn\gcc-m68k\bin\g++ возможно?). Затем при следующей сборке автообнаружение запустится и обновит так называемый «встроенный». пути и символы, которые отображаются в проектеC/C++ General -> Paths and Symbols к тому, что сообщал ваш компилятор, и вы можете переиндексировать снова, чтобы убедиться, что все предупреждения для старых «встроенных модулей» пропали.

Решение Вопроса

Проверьте настройки индексатора в разделе «Настройки» - & gt; C / C ++ - & gt; Индексатор.

Там есть поле под названием «Заполнено для индексации заранее». Его содержимое должно быть:

cstdarg, stdarg.h, stddef.h, sys/resource.h, ctime, sys/types.h, signal.h, cstdio

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

(В частности, если то, что у вас есть в этом полеstdarg.h, stddef.h, sys/types.hтогда у меня есть довольно хорошее предположение относительно того, что пошло не так. В Eclipse Ganymede значение этого поля былоstdarg.h, stddef.h, sys/types.h, В более новых версиях (Galileo и Indigo) он был изменен на вышеуказанный. Однако, поскольку это поле является частью «предпочтений», если вы экспортировали свои предпочтения Ganymede и импортировали их в Galileo / Indigo, это поле было перезаписано старым значением Ganymede. Я был сожжен этим некоторое время назад.)

 Tod10 апр. 2012 г., 22:27
Спасибо, но не такая удача. У меня есть вещи, которые вы изначально указали. Я попытался перестроить индекс, но проблема остается. Я добавил в мои пути к каталогам почти каждый путь, который я могу найти с помощью включаемых файлов, но ничего не помогло. Интересно, обманывает ли Codan способ, которым stddef.h определяет его для этого набора инструментов?
 10 апр. 2012 г., 22:46
"Я добавил в свои пути к каталогам почти каждый путь, который я могу найти с включаемыми файлами, но ничего не помогло". - & GT; Возможно, вы добавили слишком много путей включения, которые могут быть столь же вредными, как и слишком мало. Попробуйте запустить командуecho | g++ -v -x c++ -E -, Примерно на полпути внизу вы найдете список включаемых каталогов. Убедитесь, что в eclipse есть именно те (плюс любые дополнительные пути включения, которые вы передаете компилятору в командной строке), не более и не менее.
 Tod14 июл. 2012 г., 23:55
О, как бы мне хотелось, чтобы это было правдой! Сегодня это появилось снова. Вернулась идентичная проблема, с size_t. Мне пришлось открыть файл, который зависел от size_t, но, как только я это сделал, обнаружились десятки, если не сотни, ложных срабатываний ошибок Codan.
 Tod10 апр. 2012 г., 22:52
Хорошо, пока не совсем ответ, он получил меня там! Я нашел мой stddef.h в странном месте, поэтому я просто добавил этот жестко закодированный путьC:\nburn\gcc-m68k\lib\gcc\m68k-elf\4.2.1\include\stddef.h  и проблема ушла. Имея этот путь вC/C++ General->Paths and Symbols Настройки проекта Включать вкладку было недостаточно.
 13 июл. 2012 г., 02:02
@Tod: в Juno - ошибка, из-за которой существовало & quot; файлы для предварительного индексирования & quot; вариант на первом месте (bugs.eclipse.org/bugs/show_bug.cgi?id=197989) было исправлено - так что вам больше не нужно об этом беспокоиться!

У меня на самом деле была такая же проблема. Проблема, похоже, была такой же, как описанная в посте fquinner, расположенном в stddef.h/usr/include/linux/stddef.h тоже был пуст. Как ни странно, правильныйstddef.h был найден по затмению и даже мог быть без проблем.

Если вам просто нужно исправить индексацию по Eclipse, как я (например, при сборке с другим инструментом сборки в любом случае), эту проблему с индексацией можно обойти, определив__SIZE_TYPE__ к ожидаемому типу, напримерlong unsigned int подC/C++ General -> Paths and Symbols.

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

Я запускаю Fedora и, к сожалению, у нее есть файл stddef.h в / usr / include / linux ...., который на самом деле пуст. Таким образом, даже несмотря на то, что у меня был путь компилятора stddef.h в пути включения, индексатор фактически анализировал этот другой пустой файл. Итак, что нужно было сделать было:

Prefix ваш список путей и символов с указанием пути компилятора (в моем случае это был /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/), чтобы избежать анализа другого пустого stddef.h.

Ваш ответ на вопрос