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 "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
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 next 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 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
prev sibling 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 next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling 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 next sibling 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 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=

 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