http://d.puremagic.com/issues/show_bug.cgi?id=447

           Summary: frontend: writeable
           Product: D
           Version: 0.170
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: patch
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: thomas-dloop@kuehne.cn


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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=447





------- Comment #1 from thomas-dloop@kuehne.cn  2006-10-24 05:08 -------
Created an attachment (id=39)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=39&action=view)
dmd-0.170.string_constants


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=447





------- Comment #2 from bugzilla@digitalmars.com  2006-10-25 20:48 -------
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.


-- 

d-bugmail@puremagic.com 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>

Thomas Kuehne wrote:
> 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.

I've fixed a lot of bugs in dmd over the years (you know that as well as anyone!). Not one of them would have been found by const-correctness. I've used const-correctness in the past, and it never found any bugs then, either.

My bugs tend to be cases I hadn't thought of, i.e. unexpected interactions between features.

> <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).

Walter Bright wrote:
> My bugs tend to be cases I hadn't thought of, i.e. unexpected interactions between features.

I want to add that, in my experience, the single most important contributor to producing a bug-free product is a thorough test suite. Yours has proven its worth over and over, and is doing so again in helping proof the 64 bit GDC.

The best tool to help create a test suite is a coverage analyzer, like -cov for DMD and -gcov for gcc. I'm guilty of not using them enough, but their worth is beyond dispute.

The other way to create a test suite is to put every bug report into it after it's fixed. That one I do do diligently, and you do too.

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

http://d.puremagic.com/issues/show_bug.cgi?id=447


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |clugdbug@yahoo.com.au
         Resolution|                            |FIXED


--- Comment #5 from Don <clugdbug@yahoo.com.au> 2010-04-15 02:04:47 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------