This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Guile docstrings---should Guile code be ANSI C compatible?
- To: Maciej Stachowiak <mstachow at alum dot mit dot edu>
- Subject: Guile docstrings---should Guile code be ANSI C compatible?
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: Sat, 15 Jan 2000 00:31:48 +0100
- Cc: guile at sourceware dot cygnus dot com
- Reply-to: Mikael Djurfeldt <djurfeldt at nada dot kth dot se>
(Again I'm forced to bring things up which could be interpreted as
implicit criticism of Greg's work: Let me just repeat that I like
his work a lot, and think it is important.)
Guile's current docstrings are not compatible with ANSI C.
"In ANSI C, string literals are not allowed to continue past newlines
like this, but this is how Guile's docstrings look like now."
"ANSI C requires that newlines are included explicitly\n\
like that."
(The last \ just says that the two lines should be interpreted as one
line.)
Until now we have followed the rule that Guile code should be ANSI C
compatible. Since the code in the current repository isn't compatible
with regard to docstrings, it can't be compiled on all ANSI C
compilers.
We now have two alternatives:
1. (Greg's suggestion) Making an exception to the rule about ANSI C
compliance and using a script which transforms the code in the
.x-files into ANSI compilant source using a script:
#!/usr/bin/perl -pwi.bak
BEGIN { $backslashing = 0; }
if (/^SCM_DEFINE/) { $backslashing = 1; next }
if (/^\#define FUNC_NAME/) { $backslashing = 0; next }
if ($backslashing && (m/^\S/ || m/^\s*$/)) {
s/$/\\n\\/ unless (m/\"\s*\)\s*$/ || m/\\$/);
}
2. (I could do this if this choice is selected) Putting in \n\ at the
end of lines in multiline docstrings to make it ANSI C compatible.
I guess the main point speaking for 1 is that since gcc *allows* a
newline in strings, people will easily forget the \n\ so that Guile
code breaks on other compilers.
The main point speaking for 2 is that the code will be standard C.
Maciej, could you please make a decision which route we should take.
/mdj