www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 447] New: frontend: writeable

reply d-bugmail puremagic.com writes:
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.


--
Oct 24 2006
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=447






Created an attachment (id=39)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=39&action=view)
dmd-0.170.string_constants


--
Oct 24 2006
prev sibling next sibling parent reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=447






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.


--
Oct 25 2006
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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>


-----BEGIN PGP SIGNATURE-----

iD8DBQFFQVC5LK5blCcjpWoRAkCgAJ48YFkIuYDNrFNlH0acacLA6HTO6wCeLH5Y
rU0gq/zrcnvzd2lO+FE42eI=
=PQ5G
-----END PGP SIGNATURE-----
Oct 26 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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).
Oct 26 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
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.
Oct 26 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
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
Oct 27 2006
prev sibling parent d-bugmail puremagic.com writes:
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



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: -------
Apr 15 2010