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

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

enter image description here

Код компилируется без проблем, но я подозреваю, что я должен явно добавить путь к каталогам 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.