www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP(?) Warning to facilitate porting to other archs

reply "Temtaime" <temtaime gmail.com> writes:
Hi everyone.
I think it's need to have -w64(or other name, offers ?) flag that 
warns if code may not compile on other archs.

Example:
size_t a;
uint b = a; // ok on 32 without a warning but fail on 64 with 
error

And on 32 with -w64 it'll be :
Warning : size_t.sizeof may be greater than 32 bit

What you thinks ?
Should i create proposal or nobody cares about porting and it's 
useless ?

Any ideas are welcome.
May 01 2014
next sibling parent "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail gmail.com> writes:
Sounds like a nice warning. It bit me a few times when swapping 
architectures.
May 01 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 May 2014 21:17, Temtaime via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Hi everyone.
 I think it's need to have -w64(or other name, offers ?) flag that warns if
 code may not compile on other archs.

 Example:
 size_t a;
 uint b = a; // ok on 32 without a warning but fail on 64 with error

 And on 32 with -w64 it'll be :
 Warning : size_t.sizeof may be greater than 32 bit

 What you thinks ?
 Should i create proposal or nobody cares about porting and it's useless ?

 Any ideas are welcome.


Definitely a good idea. I've noticed a few of such super-helpful
portability warnings don't seem to be present in D compared to other
compilers.
May 01 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Temtaime:


 I think it's need to have -w64(or other name, offers ?) flag 
 that warns if code may not compile on other archs.


It's a problem and I'd like some way to compiler help solving 
such problems.

I suggested this, that was refused (I don't remember who reopened 
it):
https://issues.dlang.org/show_bug.cgi?id=5063

Bye,
bearophile
May 01 2014
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 02 May 2014 01:56:49 +0000
schrieb "bearophile" <bearophileHUGS lycos.com>:


 Temtaime:
 

 I think it's need to have -w64(or other name, offers ?) flag 
 that warns if code may not compile on other archs.


 
 It's a problem and I'd like some way to compiler help solving 
 such problems.
 
 I suggested this, that was refused (I don't remember who reopened 
 it):
 https://issues.dlang.org/show_bug.cgi?id=5063
 
 Bye,
 bearophile


That would have be me going renegade against a
RESOLVED-WONTFIX after I found a library that wouldn't compile
on my amd64 because it mixed size_t and uint as if it was the
same. Later I found a little flood of bug reports for other
libraries as well. Whether a warning or size_t as a distinct
type like some other language does, the current situation is
the source of statically checkable, avoidable portability bugs.

-- 
Marco
Aug 31 2014
prev sibling next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 1 May 2014 at 11:17:10 UTC, Temtaime wrote:

 Hi everyone.
 I think it's need to have -w64(or other name, offers ?) flag 
 that warns if code may not compile on other archs.

 Example:
 size_t a;
 uint b = a; // ok on 32 without a warning but fail on 64 with 
 error

 And on 32 with -w64 it'll be :
 Warning : size_t.sizeof may be greater than 32 bit

 What you thinks ?
 Should i create proposal or nobody cares about porting and it's 
 useless ?

 Any ideas are welcome.


+1. Lost count how many times my Linux code wouldn't compile on 
Windows because of this.

Atila
May 02 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 1 May 2014 at 11:17:10 UTC, Temtaime wrote:

 Hi everyone.
 I think it's need to have -w64(or other name, offers ?) flag 
 that warns if code may not compile on other archs.

 Example:
 size_t a;
 uint b = a; // ok on 32 without a warning but fail on 64 with 
 error

 And on 32 with -w64 it'll be :
 Warning : size_t.sizeof may be greater than 32 bit

 What you thinks ?
 Should i create proposal or nobody cares about porting and it's 
 useless ?

 Any ideas are welcome.


Why not? I had some minor difficulties porting from 32 to 64bit. 
I think it's a good idea to let the user know beforehand that 
there might be problems when porting. If you find that out when 
you are already on a 64 or 32bit machine, it's a bit annoying to 
go back and change the code.
May 02 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Temtaime:


 I think it's need to have -w64(or other name, offers ?) flag 
 that warns if code may not compile on other archs.


Some of the things it has to guard against:

void main() {
     size_t x;
     ptrdiff_t y;
     uint r1 = x; // warn
     int  r2 = x; // warn
     uint r3 = y; // warn
     int  r4 = y; // warn
     char[] data;
     foreach (uint i, c; data) {} // warn
     foreach (int i, c; data) {} // warn
}

Is something missing?

Bye,
bearophile
May 02 2014
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 01 May 2014 11:17:09 +0000
Temtaime via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Hi everyone.
 I think it's need to have -w64(or other name, offers ?) flag that
 warns if code may not compile on other archs.

 Example:
 size_t a;
 uint b = a; // ok on 32 without a warning but fail on 64 with
 error

 And on 32 with -w64 it'll be :
 Warning : size_t.sizeof may be greater than 32 bit

 What you thinks ?
 Should i create proposal or nobody cares about porting and it's
 useless ?

 Any ideas are welcome.


The compiler doesn't even know that size_t exists. It's just an alias in
object_.d. So, it could be fairly involved to get the compiler to warn
about something like this.

And while in some respects, this would be nice to have, I don't think that
it's actually a good idea. IMHO, the compiler pretty much has no business
warning about anything. As far as the compiler is concerned, everything
should be either an error or nothing (and Walter agrees with me on this;
IIRC, the only reason that he added warnings in the first place was as
an attempt to appease some folks). About the only exception would be
deprecation-related warnings, because those are items that aren't currently
errors but are going to be errors. If warnings are in the compiler,
programmers are forced to fix them as if they were errors (because it's
bad practice to leave compiler warnings in your build), and they can actually
affect what does and doesn't compile thanks to the -w flag (which can be
particularly nasty when stuff like template constraints get involved).

Warnings belong in lint-like tools where the user can control what they want
to be warned about, including things that would be useful to them but most
other folks wouldn't care about. So, unless you're suggesting that we make
it an error to assign a value of size_t to a uint, I don't think that it
makes any sense for the compiler to say anything about this, and given the
fact that it doesn't know anything about size_t anyway, it's probably not
particularly reasonable to have the compiler warn about it even if we agreed
that it would be a good idea.

D is ideally suited to writing lint-like tools, and as I understand it, Brian
Schott has written one. I don't know what state it's currently in or what
exactly it can warn you about at this point, but I think that it would be
better to look at putting warnings like this in such a tool than to try and
get it put in the compiler.

- Jonathan M Davis
May 02 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/2/2014 12:21 PM, Jonathan M Davis via Digitalmars-d wrote:

 As far as the compiler is concerned, everything
 should be either an error or nothing (and Walter agrees with me on this;


It would be nice if all code *could* be considered either "good" or 
"error" without causing problems. But we don't live in a perfect 
back-and-white reality, and forcing everything into dichotomy doesn't 
always work out so well.


 Warnings belong in lint-like tools where the user can control what they want
 to be warned about,


Warnings ARE a built-in lint-like tool. On top of that, lint itself 
proves that lint tends to not get used. If it's too hard for people to 
occasionally toss in a -m32 to check if that works, then no lint-like 
tool is going to solve the issue either.

That said, I do think people are underestimating the difficulty of this 
enhancement, and overestimating the benefit. It's difficult because 
size_t is (by design) only an alias and there are issues with making it 
a separate type. And it's not really worth the difficulty of getting 
around all that because it's it's already trivially checked whenever you 
want by tossing in an -m32.

I think this enhancement is a great *idea*, but not realistic.
May 02 2014
next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Friday, 2 May 2014 at 19:54:43 UTC, Nick Sabalausky wrote:

 Warnings ARE a built-in lint-like tool. On top of that, lint 
 itself proves that lint tends to not get used. If it's too hard 
 for people to occasionally toss in a -m32 to check if that 
 works, then no lint-like tool is going to solve the issue 
 either.


One solution to this is to have your editor run the lint tool:

http://i.imgur.com/w7SgbnN.png
May 02 2014
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 02 May 2014 15:54:37 -0400
Nick Sabalausky via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Warnings ARE a built-in lint-like tool.


Perhaps, but having them in the compiler is inherently flawed, because
you have little-to-no control over what it warns about, and you're
forced to essentially treat them as errors, because it's incredibly
error-prone to leave any warnings in the build (they mask real problems
too easily). As such, it makes no sense to have warnings in the compiler
IMHO.


 On top of that, lint itself proves that lint tends to not get used.


True, that is a problem. But if folks really want the warnings, they
can go to the extra effort. And I'd much rather err on the side of
folks screwing up because they didn't bother to run the tool than
having to fix nonexistent problems in my code because someone
convinced a compiler dev to make the compiler warn about something that's
a problem some of the time but isn't a problem in what I'm actually doing.

- Jonathan M Davis
May 02 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Friday, 2 May 2014 at 21:40:09 UTC, Jonathan M Davis via 
Digitalmars-d wrote:

 True, that is a problem. But if folks really want the warnings, 
 they can go to the extra effort.


Why are we making people go to extra effort to get lint-like 
functionality if we want it to be something that everyone uses? 
Whether a linter is a separate logical entity within the compiler 
or a library that can be hooked into, it should be on by default.
May 02 2014
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 02 May 2014 22:39:12 +0000
Meta via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Friday, 2 May 2014 at 21:40:09 UTC, Jonathan M Davis via
 Digitalmars-d wrote:

 True, that is a problem. But if folks really want the warnings,
 they can go to the extra effort.


 Why are we making people go to extra effort to get lint-like
 functionality if we want it to be something that everyone uses?
 Whether a linter is a separate logical entity within the compiler
 or a library that can be hooked into, it should be on by default.


The problem that some of what gets warned about is _not_ actually a problem.
If it always were, it would be an error. So, unless you have control over
exactly what gets warned about and have the ability to disable the warning
in circumstances where it's wrong, it makes no sense to have the warnings,
because you're forced to treat them as errors and always "fix" them, even if
the fix is unnecessary. If the compiler provides that kind of control, then
fine, it can have warnings, but dmd doesn't and won't, because Walter doesn't
want it to have a vast assortment of flags to control anything (warnings
included). That being the case, it makes no sense to put the warnings in the
compiler. With a lint tool however, you can configure it however you want
(especially because there isn't necessarily one, official tool, making it
possible to have a lint tool that does exactly what you want for your
project). It's not tied to what the language itself requires, making it much
more sane as a tool for giving warnings. The compiler tends to have to do
what fits _everyone's_ use case, and that just doesn't work for warnings.

Putting warnings in the compiler always seems to result in forcing people to
change their code to make the compiler shut up about something that is
perfectly fine.

- Jonathan M Davis
May 02 2014
next sibling parent "Meta" <jared771 gmail.com> writes:
On Saturday, 3 May 2014 at 01:17:36 UTC, Jonathan M Davis via 
Digitalmars-d wrote:

 The problem that some of what gets warned about is _not_ 
 actually a problem.
 If it always were, it would be an error. So, unless you have 
 control over
 exactly what gets warned about and have the ability to disable 
 the warning
 in circumstances where it's wrong, it makes no sense to have 
 the warnings,
 because you're forced to treat them as errors and always "fix" 
 them, even if
 the fix is unnecessary. If the compiler provides that kind of 
 control, then
 fine, it can have warnings, but dmd doesn't and won't, because 
 Walter doesn't
 want it to have a vast assortment of flags to control anything 
 (warnings
 included). That being the case, it makes no sense to put the 
 warnings in the
 compiler. With a lint tool however, you can configure it 
 however you want
 (especially because there isn't necessarily one, official tool, 
 making it
 possible to have a lint tool that does exactly what you want 
 for your
 project). It's not tied to what the language itself requires, 
 making it much
 more sane as a tool for giving warnings. The compiler tends to 
 have to do
 what fits _everyone's_ use case, and that just doesn't work for 
 warnings.

 Putting warnings in the compiler always seems to result in 
 forcing people to
 change their code to make the compiler shut up about something 
 that is
 perfectly fine.

 - Jonathan M Davis


I'm not arguing for warnings in the compiler. If we agree that a 
linter is a good thing that everyone should use, then we should 
make it as easy as possible to use it - including having it on by 
default. It's fine if it's customizable, disable-able, etc. Then 
the users that want to tweak its behaviour or go without can do 
so.

As for what "having it on by default" means, that's up for 
debate. Currently, only the determined can use, for example, 
DScanner, as they have to clone the Github repo, compile it, and 
then set it up to use with their editor of choice. DScanner 
hasn't become a de-facto standard yet, or "officially blessed", 
of course, but as soon as that happens, rapid action needs to be 
taken to ensure that it is as painless as possible to use and 
enabled by default, preferably transparent to the casual or 
uninformed user.
May 02 2014
prev sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Sat, 03 May 2014 03:17:23 +0200
schrieb Jonathan M Davis via Digitalmars-d
<digitalmars-d puremagic.com>:


 [=E2=80=A6]
=20
 Putting warnings in the compiler always seems to result in forcing people=


 to

 change their code to make the compiler shut up about something that is
 perfectly fine.
=20
 - Jonathan M Davis


I agree with you about warnings about clarity of operator
precedence and the like, where it is just a matter of style.
But I don't see what that has to do with this issue and code
like:

  size_t =3D ulong; // breaks when porting from 64 to 32 bit
  uint =3D size_t;  // breaks when porting from 32 to 64 bit

which is obviously broken, but accepted. I would really like
to force people to change their code to make the compiler shut
up. See some of the linked bugs for examples:
https://issues.dlang.org/show_bug.cgi?id=3D5063#c4

Now we have 3 bad options and no good one: :(

- add warnings to dmd, which should never have real warnings
  and dozens of flags to control them
- make size_t a distinct type, which is unfeasible to implement
  and is likely to break _something_
- keep the status quo with libraries that don't compile and
  try to educate people about the issue

--=20
Marco
Aug 31 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Marco Leise"  wrote in message 
news:20140831232805.7fe19a60 marco-leise.homedns.org...


 size_t = ulong; // breaks when porting from 64 to 32 bit
   uint = size_t;  // breaks when porting from 32 to 64 bit

 which is obviously broken, but accepted. I would really like
 to force people to change their code to make the compiler shut
 up. See some of the linked bugs for examples:
 https://issues.dlang.org/show_bug.cgi?id=5063#c4


Maybe it's just my history with C, but I'm always really pleased when this 
kind of code errors out the first time it's compiled on 64-bit.

Since dmd is always a cross-compiler, just can just stick -m64/-m32 on your 
command line and test the other type of size_t.  Even if you're on windows, 
and don't have the 64-bit toolchain set up, you will get all these errors 
from semantic.
Aug 31 2014