www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - -w[alter]

reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Inability of compiler to check if function does not return value is just not 
good.
int a() { }  // compiles just fine, but produces unnamed assertion in debug.

I am not using -w  switch for the sole reason, following
code produces warning which is not a warning but just
an error as compiler stops on it.

bool checked();
bool checked(bool onOff);

checked( !checked ); // here I have

- implicit conversion of expression (!this.checked()) of type int to bit can 
cause loss of data

It just not fair. bool is used everywhere.
Can I rely on that it will be repaired in upcoming bulds?

And this switch() { default: break; } is in the same category.

I never heard that someone is complaining on problems with that.

--------------------------------------------
For those who following Harmonia design.
1) It got logo (left-bottom corner):
http://www.terrainformatica.com/screenshots/harmonia.png
not perfect, but took 5 minutes to produce it.
2) tooltips, HTML and plain text.
3) menus (not finished yet).
4) TabStops and tab navigation
5) option boxes and radio boxes.

Despite on my efforts D is still fast.
Demo is here: http://www.terrainformatica.com/screenshots/HarmoniaDemo.zip
May 02 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:d5742n$vuo$1 digitaldaemon.com...

 Inability of compiler to check if function does not return value is just 
 not good.
 int a() { }  // compiles just fine, but produces unnamed assertion in 
 debug.

 I am not using -w  switch for the sole reason, following
 code produces warning which is not a warning but just
 an error as compiler stops on it.


Dlint never stops on warnings so I never use -w anymore (and I only tried it 
once or twice with dmd until giving up). Also the emacs mode for D would 
highlight the line on save/load. http://home.comcast.net/~benhinkle/dlint/
May 03 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Having Dlint is good in general but I guess
real compiler should do such basic stuff by itself, right?
'basic stuff' here means not complexity of compiler code but just
a feature of compiler. All known C/C++/Java compilers
(including the one from Symantec) are preventing such typos.

Currently DMD is just happy seeing above and this one:
void foo() { return 26; }

I understand that it is not so easy to build a compiler, but
I heard some rumors about D v.1.0.... Huh?

Andrew.


"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:d57qeq$20vj$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
 news:d5742n$vuo$1 digitaldaemon.com...

 Inability of compiler to check if function does not return value is just 
 not good.
 int a() { }  // compiles just fine, but produces unnamed assertion in 
 debug.

 I am not using -w  switch for the sole reason, following
 code produces warning which is not a warning but just
 an error as compiler stops on it.


 Dlint never stops on warnings so I never use -w anymore (and I only tried 
 it once or twice with dmd until giving up). Also the emacs mode for D 
 would highlight the line on save/load. 
 http://home.comcast.net/~benhinkle/dlint/
May 03 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <d58hsa$2u2l$1 digitaldaemon.com>, Andrew Fedoniouk says...

Having Dlint is good in general but I guess
real compiler should do such basic stuff by itself, right?
'basic stuff' here means not complexity of compiler code but just
a feature of compiler. All known C/C++/Java compilers
(including the one from Symantec) are preventing such typos.

Currently DMD is just happy seeing above and this one:
void foo() { return 26; }


I remeber this being intentional, though I can't find mention of it in the spec.
Does anyone have a reference to this in the NG?


Sean
May 03 2005
parent pragma <pragma_member pathlink.com> writes:
In article <d58khj$u9$1 digitaldaemon.com>, Sean Kelly says...

In article <d58hsa$2u2l$1 digitaldaemon.com>, Andrew Fedoniouk says...

Having Dlint is good in general but I guess
real compiler should do such basic stuff by itself, right?
'basic stuff' here means not complexity of compiler code but just
a feature of compiler. All known C/C++/Java compilers
(including the one from Symantec) are preventing such typos.

Currently DMD is just happy seeing above and this one:
void foo() { return 26; }


I remeber this being intentional, though I can't find mention of it in the spec.
Does anyone have a reference to this in the NG?


I'd like to think it has something to do with template code, but last I checked,
using 'void' as a template type doesn't work.

There's evidence in phobos that at one time, 'void' was a valid type to use in
that manner (just add a spoof TypeInfo_void and off you go).  In that case, this
'feature' may just be due for deprication.

- EricAnderton at yahoo
May 03 2005
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
The spec says that a return is allowed as long as the statement has some 
effect.  While the compiler isn't following that to a letter, it's at 
least allowing what the spec does, and just not detecting misuse.

The idea, I suspect, was at least partially to allow:

void func1(int a)
{
    if (a < 0)
       return func2(a);

    static float b = 0;

    a = (a << 2) + 5 - ++b;
}

void func2(int a)
{
    ...
}

To mirror the same behavior with functions that return other values.  I 
mean, having to split it out:

    func2(a);
    return;

Is annoying.  Clearly, it's not necessary, but I'm really not seeing 
what problems an accidental "return 42;" could involve... is it any 
different from allowing:

    42;

Which C did?  And we all know that C died specifically because of this 
blunder!

-[Unknown]
May 03 2005
parent Sean Kelly <sean f4.ca> writes:
In article <d58ot0$7gh$1 digitaldaemon.com>, Unknown W. Brackets says...

The spec says that a return is allowed as long as the statement has some 
effect.  While the compiler isn't following that to a letter, it's at 
least allowing what the spec does, and just not detecting misuse.

The idea, I suspect, was at least partially to allow:

void func1(int a)
{
    if (a < 0)
       return func2(a);

    static float b = 0;

    a = (a << 2) + 5 - ++b;
}

void func2(int a)
{
    ...
}

To mirror the same behavior with functions that return other values.  I 
mean, having to split it out:

    func2(a);
    return;

Is annoying.  Clearly, it's not necessary, but I'm really not seeing 
what problems an accidental "return 42;" could involve.


No problems, but it might mask a coding error.  I'd prefer if type checking were
done for return types and it were possible to return void.  ie.

void f() { return void; } // legal
void g() { return 1; } // illegal, cannot convert 'int' to 'void' implicitly

If no return type is specified, 'void' ias assumed.

I've been trying to think of template code that the existing rule would simplify
and I can't.  So long as void is a valid return type (as it is in C++) then I'm
happy on that score.


Sean
May 03 2005