Dangerous bug with #include files

[vlachoudis]

If there is an include under an #ifdef, the file will be included no matter whether the #ifdef is not active or not
e.g.
//#define TEST // <--- commented

ifdef TEST

include "testing.h"

endif

The final code will contain the testing.h, resulting in problematic code.

V.

[chetgray]

ino/commands/preproc.py extracts #include lines, copies them to the beginning of the file, and comments out the original line. This is biting me when headers need things #defined before they're #included to work properly.

[vlachoudis]

Relocating the includes ends up with wrong code and sometimes miss compiling due to order change. Defines should not be changed as well and includes should stay in their position

Cheers
Vasilis

On 9 Jul 2014 06:10, Chet Gray notifications@github.com wrote:

ino/commands/preproc.py extracts #include lines, copies them to the beginning of the file, and comments out the original line. This is biting me when headers need things #defined before they're #included to work properly.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/175#issuecomment-48428083.

[vlachoudis]

Thanks

Vasilis

On 12 Jul 2014 23:11, Chet Gray notifications@github.com wrote:

I have a working fix at chetgray/ino@e896b61chetgray@e896b61 on my issue175-moving-includes branch.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/175#issuecomment-48822718.

[hroncok]

Any chance to get this pulled?

[bonethrown]

Agree pretty important bug fix here

[chetgray]

In my fix, I made the mistake of adapting GPLv2+ code (from Arduino) to an MIT/Expat project (Ino). A while back I e-mailed @damellis, who authored the majority of the preprocessing strategy (arduino/Arduino@249f166) which I adapted—with a few lines by @PaulStoffregen (arduino/Arduino@77ed2f4 and arduino/Arduino@795df1e) and @cmaglie (arduino/Arduino@fa4d058)—to ask about licensing before I submitted a pull request to amperka/ino upstream, but never heard back from him. I don't use Ino much, so I let it slip by the wayside.

Could anybody with a better grasp of code licensing than I chime in?

[PaulStoffregen]

You're welcome to use the few lines I wrote under the MIT license.

[cmaglie]

MIT license is ok for me.

[chetgray]

Thanks, @PaulStoffregen and @cmaglie . I've just e-mailed @damellis again to ask about code licensure, and then hopefully I can publish the commit again and submit a pull request.