[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] preprocessor and carriage returns
|
Hi Mike,
the '\r' should certainly not count towards the length of the macro
definition.
If it does, it's a bug.
Markus.
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mike Kucera
> Sent: Donnerstag, 26. April 2007 16:54
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] preprocessor and carriage returns
>
>
> Hi, this is a bit of a low level technical issue, but I'm
> hoping someone
> can shed some light on the situation.
>
> I'm reusing several of the existing parser test suites against the C99
> parser. In particular,
> DOMLocationInclusionTests.testMacrosInIncludeFile()
> keeps failing. This test involves parsing code that contains '\r'. The
> problem I'm having is with this line of code in the test:
>
>
> assertSoleFileLocation(
> macroDefinitions[1],
> "blarg.h", h_file_code.indexOf("#define
> _BLARG_H_"),
> "#define _BLARG_H_\r".length());
>
>
> Why is the '\r' counted towards the length of the object
> macro definition?
> Shouldn't it be considered whitespace? The C99 lexer ignores
> the '\r' as
> whitespace and the test fails because the length is off by one.
>
> I've been spending some time trying to get this test case to
> pass but now
> its starting to feel like I'm trying to emulate a bug.
>
> How are carriage returns supposed to be handled? Am I wrong
> in assuming
> that they are treated just like regular whitespace?
>
>
> Mike Kucera
> IBM CDT Team
> IBM Toronto Lab
> 905-413-3657
> mkucera@xxxxxxxxxx
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
