Bug 447 – frontend: writeable string constants

DMD's frontend code assumes that string constants are implicitly convertible to "char *". The attached sources treat string constants as "const char *". Were the changes would require extensive modification the const_cast kludge was used.

Created attachment 39 dmd-0.170.string_constants

The C++ standard allows implicit conversion from string literals to char*, so DMD's usage of it is compliant code. What this would be a move towards is making the DMD source const-correct. Going halfway towards it is where the const_cast thing comes in, and that's not any better than relying on the literal => char* being allowed. Const correctness needs to be done either full bore or not at all. I'm not willing to convert it all to be const-correct, because it's ugly, a lot of work, and I'm pretty sure would not find a single problem.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [email protected] schrieb am 2006-10-26: > http://d.puremagic.com/issues/show_bug.cgi?id=447 > What this would be a move towards is making the DMD source const-correct. Going > halfway towards it is where the const_cast thing comes in, and that's not any > better than relying on the literal => char* being allowed. Const correctness > needs to be done either full bore or not at all. I'm not willing to convert it > all to be const-correct, because it's ugly, a lot of work, and I'm pretty sure > would not find a single problem. Sure, it is a lot of work and the current solution is only a start. (for the time beeing you could replace "const_cast<char *>" with "mem.strdup") "Pritty sure" is nice but having as much as possible automatic detections is more important to me in the long run. <rant> Trying to clean up the frontend for 64bit proved surpisingly hard. 64bit builds with gcc and icc show different behaviours. Seemingly simple test cases like http://dstress.kuehne.cn/run/l/large_id_01_D.d and http://dstress.kuehne.cn/compile/template_class_08.d fail for 64bit but pass for 32bit builds. etc. </rant> -----BEGIN PGP SIGNATURE----- iD8DBQFFQVC5LK5blCcjpWoRAkCgAJ48YFkIuYDNrFNlH0acacLA6HTO6wCeLH5Y rU0gq/zrcnvzd2lO+FE42eI= =PQ5G -----END PGP SIGNATURE-----

Walter Bright wrote: > Thomas Kuehne wrote: > >> <rant> >> Trying to clean up the frontend for 64bit proved surpisingly hard. >> 64bit builds with gcc and icc show different behaviours. >> Seemingly simple test cases like >> http://dstress.kuehne.cn/run/l/large_id_01_D.d and >> http://dstress.kuehne.cn/compile/template_class_08.d >> fail for 64bit but pass for 32bit builds. etc. >> </rant> > > I'm very interested in folding in the changes necessary to fix this. > I've already folded in the ones listed in the bug reports here (they'll > be in the next update). The most obvious offender in Phobos is internal/gc/gc.d, where arrays are cast to long before being returned from functions. GPhobos may be a useful comparison for 64-bit changes needed in Phobos. Sean

I'm closing this because: (1) the 64-bit bugs were fixed in dmd 0.171; (2) The DMD source will not become const-correct; (3) everything else in this bug report is obsolete.