I have many makefiles that include a usemsg command.
If usemsg can not find a usage message it returns an error.
This is a good thing. BUT, it doesn’t display anything
indicating what caused the error to be returned.
This might be a worthwhile enhancement.
OK. This one is silly.
In a C program I am writing a __USAGE message.
I want to use the word it’s.
With a single single-quote mark the compiler complains about an
unterminated string. With two single-quote marks, I get no compiler
errors, but the usage message displays with two single-quote marks.
I also tried escaping the quote with a backslash.The compiler didn’t
like that either.
What is the proper way to display a single-quote mark in a usage message?
Also, since I have not defined __USAGE anywhere, why is the compiler
even seeing what’s inside of that #ifdef block?
Shouldn’t the preprocessor be removing those lines?
Bill Caroselli <qtps@earthlink.net> wrote:
OK. This one is silly.
In a C program I am writing a __USAGE message.
I want to use the word it’s.
With a single single-quote mark the compiler complains about an
unterminated string. With two single-quote marks, I get no compiler
errors, but the usage message displays with two single-quote marks.
I also tried escaping the quote with a backslash.The compiler didn’t
like that either.What is the proper way to display a single-quote mark in a usage message?
Also, since I have not defined __USAGE anywhere, why is the compiler
even seeing what’s inside of that #ifdef block?Shouldn’t the preprocessor be removing those lines?
I would have thought it should, but you’ve already complained about GCC 
Here’s a clever hack I saw:
/*
#ifdef __USAGE
it’s
double quote (")
#endif
*/
The other thing, which is what I do now, is to keep the usage in “main.use”.
Ugly, IMHO, because keeping it in main.c keeps me honest w.r.t. the command
line processing
Cheers,
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Robert Krten <nospam84@parse.com> wrote:
/*
#ifdef __USAGE
it’s
double quote (")
#endif
*/The other thing, which is what I do now, is to keep the usage in “main.use”.
Ugly, IMHO, because keeping it in main.c keeps me honest w.r.t. the command
line processing >
COOL! It worked. Thanks.
In larger projects that are multi-file I do have a seperate *.usasge file
but in smaller ones like this, I try to keep it all in one file.
Robert Krten <nospam84@parse.com> wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
With a single single-quote mark the compiler complains about an
unterminated string. With two single-quote marks, I get no compiler
errors, but the usage message displays with two single-quote marks.
I also tried escaping the quote with a backslash.The compiler didn’t
like that either.
…
Also, since I have not defined __USAGE anywhere, why is the compiler
even seeing what’s inside of that #ifdef block?Shouldn’t the preprocessor be removing those lines?
I would have thought it should, but you’ve already complained about GCC >
Phases of translation, man. Phases of translation.
According to the standard, breaking the source file into a stream of tokens
occurs before preprocessing. Having a single quote hanging out by itself
is a lexical error, so it will still get reported even if in a #if’d out
block. Putting everything in a comment is the ‘proper’ way to do it.
–
Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8
Brian Stecher <bstecher@qnx.com> wrote:
Robert Krten <> nospam84@parse.com> > wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
With a single single-quote mark the compiler complains about an
unterminated string. With two single-quote marks, I get no compiler
errors, but the usage message displays with two single-quote marks.
I also tried escaping the quote with a backslash.The compiler didn’t
like that either.
…
Also, since I have not defined __USAGE anywhere, why is the compiler
even seeing what’s inside of that #ifdef block?Shouldn’t the preprocessor be removing those lines?
I would have thought it should, but you’ve already complained about GCC >
Phases of translation, man. Phases of translation.
And if you acronym-ize that, it’s “POT man, POT!” You’re saying I’m smoking POT?
According to the standard, breaking the source file into a stream of tokens
occurs before preprocessing. Having a single quote hanging out by itself
is a lexical error, so it will still get reported even if in a #if’d out
block. Putting everything in a comment is the ‘proper’ way to do it.
Huh. I always interpreted the “pre” part as meaning “before”
Nice of the C standards committee to help themselves to liberal interpretations
of the English language while standardizing the C one
Cheers,
-RK
–
Brian Stecher (> bstecher@qnx.com> ) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Robert Krten <nospam84@parse.com> wrote:
Brian Stecher <> bstecher@qnx.com> > wrote:
Phases of translation, man. Phases of translation.And if you acronym-ize that, it’s “POT man, POT!” You’re saying I’m smoking POT? >
…
Huh. I always interpreted the “pre” part as meaning “before” >
Even a preprocessor has to take a ‘toke’ now and then .
–
Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8
Brian Stecher <bstecher@qnx.com> wrote:
Robert Krten <> nospam84@parse.com> > wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
With a single single-quote mark the compiler complains about an
unterminated string. With two single-quote marks, I get no compiler
errors, but the usage message displays with two single-quote marks.
I also tried escaping the quote with a backslash.The compiler didn’t
like that either.
…
Also, since I have not defined __USAGE anywhere, why is the compiler
even seeing what’s inside of that #ifdef block?Shouldn’t the preprocessor be removing those lines?
I would have thought it should, but you’ve already complained about GCC >
Phases of translation, man. Phases of translation.
According to the standard, breaking the source file into a stream of tokens
occurs before preprocessing. Having a single quote hanging out by itself
is a lexical error, so it will still get reported even if in a #if’d out
block. Putting everything in a comment is the ‘proper’ way to do it.
Thanks Brian. The facts dictate that you are absolutely correct. (See
Roberts port and my comment to it.) Silly me. To think that PRE
processing actually occured before something else!
“Robert Krten” <nospam84@parse.com> wrote in message
news:b2gad6$94i$1@inn.qnx.com…
Brian Stecher <> bstecher@qnx.com> > wrote:
According to the standard, breaking the source file into a stream of
tokens
occurs before preprocessing. Having a single quote hanging out by itself
is a lexical error, so it will still get reported even if in a #if’d out
block. Putting everything in a comment is the ‘proper’ way to do it.Huh. I always interpreted the “pre” part as meaning “before” >
You’d think that something called a “preprocessor” shouldn’t do any
processing, eh?
Nice of the C standards committee to help themselves to liberal
interpretations
of the English language while standardizing the C one >
C had a “preprocessor” long before the C committee existed. And the order
where it looks for quotes before comments before directives is quite old,
too.
In short, the preprocessor has to pay attention to quotes because you don’t
want something like
puts( “/*” );
to start a comment. And it needs to keep track of comments because you
expect things like this to work:
/* We don’t need these headers:
#include <foo.h>
#include <bar.h>
*/
Wojtek Lerch <wojtek_l@ottawa.com> wrote:
You’d think that something called a “preprocessor” shouldn’t do any
processing, eh? >C had a “preprocessor” long before the C committee existed. And the order
where it looks for quotes before comments before directives is quite old,
too.In short, the preprocessor has to pay attention to quotes because you don’t
want something likeputs( “/*” );
to start a comment. And it needs to keep track of comments because you
expect things like this to work:/* We don’t need these headers:
#include <foo.h
#include <bar.h
*/
Good points, but . . .
I thought that preprocessor directives:
So that I would have coded the above as:
//#include <foo.h>
//#include <bar.h>
or, before ‘//’ was a recognized comment I’d remove the ‘#’.
/*
include <foo.h>
include <bar.h>
Again, testing shows that I was wrong. But I still think that that is
how it should be.
Is there a current ANSI spec that mandates the order of pre-processing
vs. comment interpreting?
Brian Stecher <bstecher@qnx.com> wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
I thought that preprocessor directives:
- had to appear on a line by themselves (without any standard C code)
- had to start with a ‘#’
- got parsed before comments
So that I would have coded the above as:
//#include <foo.h
//#include <bar.hor, before ‘//’ was a recognized comment I’d remove the ‘#’.
/*
include <foo.h
include <bar.hAgain, testing shows that I was wrong. But I still think that that is
how it should be.Is there a current ANSI spec that mandates the order of pre-processing
vs. comment interpreting?The order is described by standard C phases of translation.
Go to google and search for “ANSI C translation phases” for details.In terms of pre-processing vs comments, standard C considers both
to be preprocessing operations that happen at the same time (phase 4
according to the spec). Since they happen ‘at the same time’ a
“#” directive won’t be recognized in a comment. I’ve never heard of
a compiler that would do it the other way around.
Then you are absolutely right. The entire file must be tokenized before
preprocessing begins. (as shown by the printf() example)
Bill Caroselli <qtps@earthlink.net> wrote:
I thought that preprocessor directives:
- had to appear on a line by themselves (without any standard C code)
- had to start with a ‘#’
- got parsed before comments
So that I would have coded the above as:
//#include <foo.h
//#include <bar.hor, before ‘//’ was a recognized comment I’d remove the ‘#’.
/*
include <foo.h
include <bar.hAgain, testing shows that I was wrong. But I still think that that is
how it should be.Is there a current ANSI spec that mandates the order of pre-processing
vs. comment interpreting?
The order is described by standard C phases of translation.
Go to google and search for “ANSI C translation phases” for details.
In terms of pre-processing vs comments, standard C considers both
to be preprocessing operations that happen at the same time (phase 4
according to the spec). Since they happen ‘at the same time’ a
“#” directive won’t be recognized in a comment. I’ve never heard of
a compiler that would do it the other way around.
–
Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8
Bill Caroselli <qtps@earthlink.net> wrote:
Wojtek Lerch <> wojtek_l@ottawa.com> > wrote:
/* We don’t need these headers:
#include <foo.h
#include <bar.h
*/I thought that preprocessor directives:
- had to appear on a line by themselves (without any standard C code)
Yes, unless you count comments as “standard C code”.
- had to start with a ‘#’
Yes, but you can have some white space or even a comment
in front of the ‘#’.
- got parsed before comments
No. Comments disappear in phase 3, and preprocessing directives are
executed in phase 4.
So that I would have coded the above as:
//#include <foo.h
//#include <bar.hor, before ‘//’ was a recognized comment I’d remove the ‘#’.
/*
include <foo.h
include <bar.hAgain, testing shows that I was wrong. But I still think that that is
how it should be.
Do you mean that if you forgot to remove the '#'s, you’d expect the
compiler to actually try to include the header, and stick its contents
inside the comment, and give you a pile of syntax errors if the header
existed and happened to contain a comment?
Is there a current ANSI spec that mandates the order of pre-processing
vs. comment interpreting?
You can buy a pdf copy of the actual ISO standard from ANSI. Last time
I checked, the price was $18 US. (But some people say that you
shouldn’t buy it from ANSI because the licensing agreement allows ANSI
to sue you too easily.)