Compiling Guppy-PE extension modules
iddw at hotmail.com
Tue Nov 29 23:49:06 CET 2005
On 29 Nov 2005 11:53:31 -0800 in comp.lang.python, "Sverker Nilsson"
<sverker.is at home.se> wrote:
>One of the problems, seems to be string constants in the C source that
>contain newlines. I am using GCC on Linux so, I missed this with the
I'm not sure what you mean by this. Something like
char long_string = " A long string that
extends to subsequent lines
before closing the quote? ";
>standard warning options. Compiling with -pedantic reveals 'a lot' of
>places where this is a problem.
>I could fix this but it takes some work and it makes the source code
>less readable so I was wondering ...
Eye of the beholder, I guess.
You were aware that C supports concatenation of string literals
separated only by whitespace? For example, if the problem is similar
to the long_string example above, and it does what I think it does,
the following code should be equivalent and will compile on any good C
compiler (even Microsoft's).
char long_string = " A long string that\n"
" extends to subsequent lines\n"
" before closing the quote? ";
Not that much worse, and you could probably write a Python script to
automate the changes. If a quote opens but doesn't close on a line,
append a newline and close the quote, then prepend an opening quote on
the next line. The only tricky part is making sure the opening quote
isn't inside a comment or character literal.
>Is this a common problem? Or maybe it is just the compiler version
>mentioned that doesn't handle it?
I wasn't even aware GCC supported such an extension. Certainly no
other C compiler I've used has anything like this.
>Does someone know of some switch to enable the Microsoft compiler to
>accept strings with newlines?
Not that I'm aware of. Sorry.
Maybe one exists, but if so, I'd resist the temptation to use it. It
might disappear in a later version of the compiler, or you might need
to use some other compiler that doesn't support multiline strings, and
you're back where you started.
>PS. I know it's not ANSI-correct but why do we have to work to make
>our source codes less clear?
Hysterical raisins. Regards,
Change is inevitable, progress is not.
More information about the Python-list