Compiling Guppy-PE extension modules

[Dave Hansen]

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,
                                        -=Dave

-- 
Change is inevitable, progress is not.