The compiler reports error with any one Macro more than one line, for
example #define RIGHT_CHECK(X,Y) ((((int)(X)->centre_right - (int)(Y)->centre_right)
<< \
The compiler reports error with any one Macro more than one line, for
example #define RIGHT_CHECK(X,Y) ((((int)(X)->centre_right - (int)(Y)->centre_right) > \
((int)(X)->right - (int)(Y)->right))
Hello Yiwen,
Iâve had similar experiences with another compiler in a source-tree
with mixed-up windows and unix lineendings. If the unix compiler
expects the unix lf, but thereâs an extra cr it canât interpret, the
trouble beginsâŚ
So check that all source files are stored in unix format. Hope this
helps.
The compiler reports error with any one Macro more than one line, for
example #define RIGHT_CHECK(X,Y) ((((int)(X)->centre_right -
(int)(Y)->centre_right) > \
((int)(X)->right - (int)(Y)->right))
Hello Yiwen,
Iâve had similar experiences with another compiler in a source-tree
with mixed-up windows and unix lineendings. If the unix compiler
expects the unix lf, but thereâs an extra cr it canât interpret, the
trouble beginsâŚ
So check that all source files are stored in unix format. Hope this
helps.
I agree with you if I develop on a Unix/Linux machine. But âŚ
(1) I develop the software on Win2000.
(2) I edit files in QNX Momentics IDE editor. Source code edited by the IDE
itself (not the outside editor) gives the compiling error. It means
non-consistent between IDE and compiler.
I agree with you if I develop on a Unix/Linux machine. But âŚ
(1) I develop the software on Win2000.
(2) I edit files in QNX Momentics IDE editor. Source code edited by the IDE
itself (not the outside editor) gives the compiling error. It means
non-consistent between IDE and compiler.
So I think it is a bug.
The GNU compiler expects lines to end with â\nâ. The macro preprocessor
requires the ââ character to be the at the end of the line to
escape (kinf of) the line feed character.
I.E. ââ, â\nâ, not ââ, â\râ, â\nâ.
Does your editor have an option to use UNIX style new-lines? Many do.
I agree with you if I develop on a Unix/Linux machine. But âŚ
(1) I develop the software on Win2000.
(2) I edit files in QNX Momentics IDE editor. Source code edited by the
IDE
itself (not the outside editor) gives the compiling error. It means
non-consistent between IDE and compiler.
So I think it is a bug.
Yiwen
No, it is not a bug
If I were developing on an EBCDIC machine, I couldnât rightly
expect my text files to work properly under an ASCII system.
This is the same effect.
I, too, develop under Windows.
I use a text editor (CodeWright) thatâs smart enough to deal
with different line endings and adjust properly. Iâd suggest
you get such an editor (e.g., UltraEdit32, CodeWright,
dozens of others). At some point or another, youâre going
to have a file that contains carriage returns in it; fortunately,
most of these editors contain functions to do the conversion
from one format to another (or you can use TEXTTO under
QNX). Thatâs just part of life.
If it makes you feel any better, UNIX was using linefeeds
for EOLN well before CP/M-80 came along and used
the two-character sequence . DOS and
Windows, of course, got that sequence from CP/M-80
(whether CP/M-80 inherited it from RSTS or RT-11
is a good question, I donât remember).
The bottom line is that Windows has a similar âbugâ.
Try loading a UNIX text file into notepad.exe and
watch what happens.
To make matters worse, the Macintosh uses single
carriage returns as EOLN markers. So thereâs yet
a third type of text data file youâve got to deal with.
(AFAIK, TEXTTO under QNX doesnât handle Mac
files, but Iâve got my own version of TEXTTO running
under Windows that deals with all three text file formats).
Randy Hyde
If it makes you feel any better, UNIX was using linefeeds
for EOLN well before CP/M-80 came along and used
the two-character sequence . DOS and
Windows, of course, got that sequence from CP/M-80
(whether CP/M-80 inherited it from RSTS or RT-11
is a good question, I donât remember).
Iâm pretty sure that this pre-dates any modern OS. It is simply what
is required for older mechanical printers. One character forced the
print head (carrage) to the left hand column and one scrolled the paper
up one line.
Incidenly, it was and not because the carrage return
could be a lengthy operation. So the printer could line feed while
it was still returning the carrage. Many old timers will remember when
software would have to pad tralling s to the because
of the length of time it took to return the carrage.
The bottom line is that Windows has a similar âbugâ.
Try loading a UNIX text file into notepad.exe and
watch what happens.
To make matters worse, the Macintosh uses single
carriage returns as EOLN markers. So thereâs yet
a third type of text data file youâve got to deal with.
(AFAIK, TEXTTO under QNX doesnât handle Mac
files, but Iâve got my own version of TEXTTO running
under Windows that deals with all three text file formats).
Randy Hyde
And hey, QNX 2 used the (Unit Seperator) character for EOL.
â
Bill Caroselli â Q-TPS Consulting
1-(626) 824-7983 qtps@earthlink.net
Randall Hyde <> randall.nospam.hyde@ustraffic.net> > wrote:
(hint: youâll get this same problem using GNU tools under
Linux and other variations on UNIX, as well).
Not true. I just tried the following example:
#define foo^M
bar^M
Then this is something theyâve corrected recentlyâŚ
\