GNOME Bugzilla – Bug 539894
Support long string literals without corresponding support in C compiler
Last modified: 2010-10-14 08:28:40 UTC
Please describe the problem: A declaration such as: protected static const string xmldef="BIG LONG STRING"; generates this code: #define PHONE_UI_GLADE_xmldef "BIG LONG STRING" but C99 requires only that 4K inline strings be used. Steps to reproduce: Write some vala code with: protected static const string xmldef="BIG LONG STRING"; in and compare the generated C to protected static string xmldef="BIG LONG STRING"; Actual results: Expected results: I suggest that a better definition would be: (in .h) extern const char* phone_ui_glade_xmldef; (in .c) const char* phone_ui_glade_xmldef = "BIG LONG STRING"; It would make very long static const strings safer, it would avoid the problem of linking libraries combined with different versions of the constant (which would be very confusing) by keeping it as part of the target library. It would also allow string comparisons acorss shared libraries to be optimized as the address-of would be the same. Does this happen every time? Other information: I think the #define implementation was clever, but turns out to be not very useful when very long strings are defined.
If the string is longer than 4K, then wouldn't const char* phone_ui_glade_xmldef = "BIG LONG STRING"; also cause the same length problem as the macro implementation?
Jared; no it doesn't cause the same problem as the macro implementation; not for gcc anyway. I also note that C99 only requires a minimum of 4096 characters to be permitted on one line, so vala probably ought to use a const char* AND break it up onto multiple lines.
I propose a CCode attribute like [CCode (no_macro = true)] const string phone_ui = "asdfqwefqwefqewwqwqf"; Without the attribute macro is used.
I have a testcase where the define way is breaking a code and a patch that solves the issue. I dont really see any problem to use #define for constants, but they should be prefixed in a way or other to not crash at C level. the test case: --------- const string str = "fooo!\n"; unowned string retstr () { return str; } void main () { unowned string str = retstr (); print (str); } --------- the patch: --------- diff --git a/vala/valaconstant.vala b/vala/valaconstant.vala index b382bcb..6b933e4 100644 --- a/vala/valaconstant.vala +++ b/vala/valaconstant.vala @@ -94,7 +94,7 @@ public class Vala.Constant : Member, Lockable { */ public string get_cname () { if (cname == null) { - cname = get_default_cname (); + cname = "__const_" + get_default_cname (); } return cname; } ---------
As far as I can tell, C99 requires implementation only to support 4095 characters in any string literal, even after concatenation. So it really doesn't matter whether it's in a macro and on multiple lines or not. It also doesn't mean that generating longer string literals is invalid C, it's just not guaranteed to be supported by all implementations. So it would be interesting to have a list with actual limits of widespread implementations and possible alternative code we could generate. (In reply to comment #4) > I have a testcase where the define way is breaking a code and a patch that > solves the issue. I dont really see any problem to use #define for constants, > but they should be prefixed in a way or other to not crash at C level. The same issue would happen with global variables. It's a general namespacing issue, not directly related to this bug.
This bug mixes various issues. Long string literals are split nowadays, see bug 606838. String constants still use #define, however, at least from my interpretation of the standard, I don't see how a C const would differ regarding string length. Local string constants use C const for scoping reasons, so if you really want to avoid #define, you can use a local constant (and return it in a public method if you need outside access). The identifier conflict is a more general issue. For example, glibc headers define various macros where similar conflicts may happen. I'm closing this bug as a duplicate of bug 606838 as that's closest to the original bug report. *** This bug has been marked as a duplicate of bug 606838 ***