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

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

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

\include  
\include\c++\4.2.1
\include\c++\4.2.1\include
\include\c++\4.2.1\m68k-elf

Update

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

gcc-m68k\lib\gcc\m68k-elf\4.2.1\include

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

Примечание при тестировании

При тестировании того, что работает, а что нет, я заметил пару вещей

Анализ кода не возникает при повторном запуске при изменении настроек предпочтений анализа кода, мне все равно необходимо изменить редактор (просто добавив пробел)
Отключение настройки анализа кода для Symbol is not resolved не приведет к ошибке.
Отключение всех Syntax and Semantic Errors, запуск анализа, возврат и включение всех остальных, а затем выключение Symbol is not resolved приводит к повторному появлению ошибки.

Ответы

Ответ 1

Проверьте настройки индексатора в разделе "Настройки" → C/С++ → Indexer.

Существует поле, которое называется "Подано для индексации вверх". Его содержимое должно быть:

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. был сожжен этим некоторое время назад.)

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

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

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