Stefan Behnel wrote:
> AFAIR, there may also be references to __pyx_k_2 in the C source, but
> that's worth checking. In any case, char* literals currently end up in the
> same place as the char* basis of str/unicode literals.
>
> I wouldn't mind putting them right into the string tab, though, and
> declaring them "const char*" there (if the C-API in Py2.3 allows it, don't
> remember).
Note that I meant getting rid of string constants in Symtab.py
altogether, meaning that also char literals (i.e. 'cdef char* s =
"asdf"') would also be "inlined". (You once mentioned splitting up long
char literals for MSVC, was this ever done? At least I wasn't able to
split up a long string when testing.)
>> One could argue that the literal can be reused -- however the C compiler
>> will in most (all?) cases optimize/collapse identical string constants
>
> I doubt that it will do that in many cases. It can really only do that for
> a const char*. All other char sequences are free to be mutated in place.
OK, as that is not an issue I won't worry.
But, going off-topic and conversational -- are you sure? The way I
understood it, all literals are "const char*", it's just that they can
be immediately assigned to a regular char* variable. I tried this with gcc:
char* s = "one one one";
s[2] = 'Z';
printf("%s\n", s);
At least on my gcc, I had two types of behaviour:
a) With no switches, segfault.
b) With -O1 or -O2, no segfault, but my change didn't show up in the
output either (might have just been my testcase though, but at least
when the write is optimized away it is not supported).
With g++ the only apparent difference was that g++ would complain that
the literal was casted from const to non-const without an explicit cast.
> Sounds like a bit of work, but it sounds worthwhile.
If it turns out that way I won't do it actually, but it didn't look too
bad -- estimated an hour...
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
