Invalid return path checking on inline C++ methods (VS.NET 2003)

[Michael Kennedy [UB]]

Hi,

I am back with more bug reports from Visual Studio.NET 2003's C++ compiler
(unmanaged). Consider the following method:

---------------------------------------------
__forceinline
bool CReplayBase::Re playFillBuffer( )
{
CFile* pFile = NULL;
for(int i=0; i<m_FileList.Ge tCount(); i++)
{
pFile = m_FileList.GetA t ;
}
}
---------------------------------------------

It is has bool return type, but no path returns any values. Obviously this
is an error and should not compile. Yet it does!

Now comment out the __forceinline and it stops compiling and reports the
error of "not all control paths return a value."

Any thoughts? We can certainly live with this bug, but it'd be better if it
was fixed.

Thanks in advance,
Michael

[Gary Chang [MSFT]]

Hi Michael,,

Thanks for your feedback in this group!

I have reproduced it and am performing research on it. I will get back here
with more information as soon as possible.

Best Regards!

Gary Chang
Microsoft Online Partner Support
Get Secure! – www.microsoft.com/security
This posting is provided "AS IS" with no warranties,and confers no rights.
--------------------
| From: "Michael Kennedy [UB]" <mk******@REMOV ETHIS.unitedbin ary.com>
| Subject: Invalid return path checking on inline C++ methods (VS.NET 2003)
| Date: Wed, 22 Oct 2003 15:30:49 -0700
| Lines: 30
| Organization: United Binary, LLC.
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <#p************ **@tk2msftngp13 .phx.gbl>
| Newsgroups: microsoft.publi c.dotnet.langua ges.vc
| NNTP-Posting-Host: 130.191.240.187
| Path: cpmsftngxa06.ph x.gbl!TK2MSFTNG P08.phx.gbl!tk2 msftngp13.phx.g bl
| Xref: cpmsftngxa06.ph x.gbl microsoft.publi c.dotnet.langua ges.vc:29661
| X-Tomcat-NG: microsoft.publi c.dotnet.langua ges.vc
|
| Hi,
|
| I am back with more bug reports from Visual Studio.NET 2003's C++ compiler
| (unmanaged). Consider the following method:
|
| ---------------------------------------------
| __forceinline
| bool CReplayBase::Re playFillBuffer( )
| {
| CFile* pFile = NULL;
| for(int i=0; i<m_FileList.Ge tCount(); i++)
| {
| pFile = m_FileList.GetA t ;
| }
| }
| ---------------------------------------------
|
| It is has bool return type, but no path returns any values. Obviously this
| is an error and should not compile. Yet it does!
|
| Now comment out the __forceinline and it stops compiling and reports the
| error of "not all control paths return a value."
|
| Any thoughts? We can certainly live with this bug, but it'd be better if
it
| was fixed.
|
| Thanks in advance,
| Michael
|
|
|

[Gary Chang [MSFT]]

Hi Micheal,

I think you hadn't called the inline method in your code, if you add a
call to it , you should get a "error C4716: 'CReplayBase::R eplayFillBuffer '
: must return a value".

However, It is a quirk of how we implement that diagnostic. Our product
dev team explained that the code generator issues the diagnostic (mainly
because the parser doesn't build a flow graph), but the parser notices that
the function is never called and it's inline, so the code generator never
sees it.

Does that answer your problem?
Best regards!

Gary Chang
Microsoft Online Partner Support
Get Secure! – www.microsoft.com/security
This posting is provided "AS IS" with no warranties,and confers no rights.
--------------------

[Michael Kennedy [UB]]

Hi Gary,

Thanks for looking into this. I think that you are right about it not being
called in our code. That problem was something we noticed while we were
building the method.

I guess it's sort of a "If a tree falls in the forest and no body is around
to hear it, does it make a noise?" type of situation. But here we have "If
the method is never called, does anyone notice the missing return value?"

Regards,
Michael

"Gary Chang [MSFT]" <v-******@online.m icrosoft.com> wrote in message
news:UF******** *****@cpmsftngx a06.phx.gbl...

Hi Micheal,

I think you hadn't called the inline method in your code, if you add a
call to it , you should get a "error C4716: 'CReplayBase::R eplayFillBuffer ' : must return a value".

However, It is a quirk of how we implement that diagnostic. Our product
dev team explained that the code generator issues the diagnostic (mainly
because the parser doesn't build a flow graph), but the parser notices that the function is never called and it's inline, so the code generator never
sees it.

Does that answer your problem?
Best regards!

Gary Chang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties,and confers no rights.
--------------------

[Gary Chang [MSFT]]

Hi Michael,

Thanks for your response!

I agree with you on this point: "The compilier seems do not want to hear a
tree falling in the forest.", maybe it is a issue will be considered
seriously.

Best regards!

Gary Chang
Microsoft Online Partner Support
Get Secure! – www.microsoft.com/security
This posting is provided "AS IS" with no warranties,and confers no rights.
--------------------
| From: "Michael Kennedy [UB]" <mk******@REMOV ETHIS.unitedbin ary.com>
| References: <#p************ **@tk2msftngp13 .phx.gbl>
<UF************ *@cpmsftngxa06. phx.gbl>
| Subject: Re: Invalid return path checking on inline C++ methods (VS.NET
2003)
| Date: Thu, 23 Oct 2003 09:12:05 -0700
| Lines: 42
| Organization: United Binary, LLC.
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <uq************ **@TK2MSFTNGP11 .phx.gbl>
| Newsgroups: microsoft.publi c.dotnet.langua ges.vc
| NNTP-Posting-Host: 130.191.240.187
| Path: cpmsftngxa06.ph x.gbl!TK2MSFTNG P08.phx.gbl!TK2 MSFTNGP11.phx.g bl
| Xref: cpmsftngxa06.ph x.gbl microsoft.publi c.dotnet.langua ges.vc:29681
| X-Tomcat-NG: microsoft.publi c.dotnet.langua ges.vc
|
| Hi Gary,
|
| Thanks for looking into this. I think that you are right about it not
being
| called in our code. That problem was something we noticed while we were
| building the method.
|
| I guess it's sort of a "If a tree falls in the forest and no body is
around
| to hear it, does it make a noise?" type of situation. But here we have "If
| the method is never called, does anyone notice the missing return value?"
|
| Regards,
| Michael
|
| "Gary Chang [MSFT]" <v-******@online.m icrosoft.com> wrote in message
| news:UF******** *****@cpmsftngx a06.phx.gbl...
| > Hi Micheal,
| >
| > I think you hadn't called the inline method in your code, if you add a
| > call to it , you should get a "error C4716:
| 'CReplayBase::R eplayFillBuffer '
| > : must return a value".
| >
| > However, It is a quirk of how we implement that diagnostic. Our product
| > dev team explained that the code generator issues the diagnostic (mainly
| > because the parser doesn't build a flow graph), but the parser notices
| that
| > the function is never called and it's inline, so the code generator
never
| > sees it.
| >
| > Does that answer your problem?
| >
| >
| > Best regards!
| >
| > Gary Chang
| > Microsoft Online Partner Support
| > Get Secure! - www.microsoft.com/security
| > This posting is provided "AS IS" with no warranties,and confers no
rights.
| > --------------------
| >
|
|
|

[Michael Kennedy [UB]]

Hi Gary,

You're welcome. Thanks again for looking into this issue.

Regards,
Michael

"Gary Chang [MSFT]" <v-******@online.m icrosoft.com> wrote in message
news:vp******** *****@cpmsftngx a06.phx.gbl...

Hi Michael,

Thanks for your response!

I agree with you on this point: "The compilier seems do not want to hear a tree falling in the forest.", maybe it is a issue will be considered
seriously.

Best regards!

Gary Chang
Microsoft Online Partner Support
Get Secure! – www.microsoft.com/security
This posting is provided "AS IS" with no warranties,and confers no rights.
--------------------
| From: "Michael Kennedy [UB]" <mk******@REMOV ETHIS.unitedbin ary.com>
| References: <#p************ **@tk2msftngp13 .phx.gbl>
<UF************ *@cpmsftngxa06. phx.gbl>
| Subject: Re: Invalid return path checking on inline C++ methods (VS.NET
2003)
| Date: Thu, 23 Oct 2003 09:12:05 -0700
| Lines: 42
| Organization: United Binary, LLC.
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <uq************ **@TK2MSFTNGP11 .phx.gbl>
| Newsgroups: microsoft.publi c.dotnet.langua ges.vc
| NNTP-Posting-Host: 130.191.240.187
| Path: cpmsftngxa06.ph x.gbl!TK2MSFTNG P08.phx.gbl!TK2 MSFTNGP11.phx.g bl
| Xref: cpmsftngxa06.ph x.gbl microsoft.publi c.dotnet.langua ges.vc:29681
| X-Tomcat-NG: microsoft.publi c.dotnet.langua ges.vc
|
| Hi Gary,
|
| Thanks for looking into this. I think that you are right about it not
being
| called in our code. That problem was something we noticed while we were
| building the method.
|
| I guess it's sort of a "If a tree falls in the forest and no body is
around
| to hear it, does it make a noise?" type of situation. But here we have "If | the method is never called, does anyone notice the missing return value?" |
| Regards,
| Michael
|
| "Gary Chang [MSFT]" <v-******@online.m icrosoft.com> wrote in message
| news:UF******** *****@cpmsftngx a06.phx.gbl...
| > Hi Micheal,
| >
| > I think you hadn't called the inline method in your code, if you add a | > call to it , you should get a "error C4716:
| 'CReplayBase::R eplayFillBuffer '
| > : must return a value".
| >
| > However, It is a quirk of how we implement that diagnostic. Our product | > dev team explained that the code generator issues the diagnostic (mainly | > because the parser doesn't build a flow graph), but the parser notices
| that
| > the function is never called and it's inline, so the code generator
never
| > sees it.
| >
| > Does that answer your problem?
| >
| >
| > Best regards!
| >
| > Gary Chang
| > Microsoft Online Partner Support
| > Get Secure! - www.microsoft.com/security
| > This posting is provided "AS IS" with no warranties,and confers no
rights.
| > --------------------
| >
|
|
|

[Keith MacDonald]

This situation also arises with member functions of template classes.
Compilers can't compile such code, without knowing the template parameters,
so they ignore it, unless you actually call it.

Keith MacDonald

"Michael Kennedy [UB]" <mk******@REMOV ETHIS.unitedbin ary.com> wrote in
message news:ur******** ******@TK2MSFTN GP11.phx.gbl...

Hi Gary,

You're welcome. Thanks again for looking into this issue.

Regards,
Michael

"Gary Chang [MSFT]" <v-******@online.m icrosoft.com> wrote in message
news:vp******** *****@cpmsftngx a06.phx.gbl...

Hi Michael,

Thanks for your response!

I agree with you on this point: "The compilier seems do not want to hear

a

tree falling in the forest.", maybe it is a issue will be considered
seriously.

Best regards!

Gary Chang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties,and confers no

rights. --------------------
| From: "Michael Kennedy [UB]" <mk******@REMOV ETHIS.unitedbin ary.com>
| References: <#p************ **@tk2msftngp13 .phx.gbl>
<UF************ *@cpmsftngxa06. phx.gbl>
| Subject: Re: Invalid return path checking on inline C++ methods (VS.NET 2003)
| Date: Thu, 23 Oct 2003 09:12:05 -0700
| Lines: 42
| Organization: United Binary, LLC.
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <uq************ **@TK2MSFTNGP11 .phx.gbl>
| Newsgroups: microsoft.publi c.dotnet.langua ges.vc
| NNTP-Posting-Host: 130.191.240.187
| Path: cpmsftngxa06.ph x.gbl!TK2MSFTNG P08.phx.gbl!TK2 MSFTNGP11.phx.g bl
| Xref: cpmsftngxa06.ph x.gbl microsoft.publi c.dotnet.langua ges.vc:29681
| X-Tomcat-NG: microsoft.publi c.dotnet.langua ges.vc
|
| Hi Gary,
|
| Thanks for looking into this. I think that you are right about it not
being
| called in our code. That problem was something we noticed while we were | building the method.
|
| I guess it's sort of a "If a tree falls in the forest and no body is
around
| to hear it, does it make a noise?" type of situation. But here we have

"If

| the method is never called, does anyone notice the missing return

value?"

|
| Regards,
| Michael
|
| "Gary Chang [MSFT]" <v-******@online.m icrosoft.com> wrote in message
| news:UF******** *****@cpmsftngx a06.phx.gbl...
| > Hi Micheal,
| >
| > I think you hadn't called the inline method in your code, if you add a

| > call to it , you should get a "error C4716:
| 'CReplayBase::R eplayFillBuffer '
| > : must return a value".
| >
| > However, It is a quirk of how we implement that diagnostic. Our

product

| > dev team explained that the code generator issues the diagnostic

(mainly

| > because the parser doesn't build a flow graph), but the parser

notices | that
| > the function is never called and it's inline, so the code generator
never
| > sees it.
| >
| > Does that answer your problem?
| >
| >
| > Best regards!
| >
| > Gary Chang
| > Microsoft Online Partner Support
| > Get Secure! - www.microsoft.com/security
| > This posting is provided "AS IS" with no warranties,and confers no
rights.
| > --------------------
| >
|
|
|

[Carl Daniel [VC++ MVP]]

Keith MacDonald wrote:

This situation also arises with member functions of template classes.
Compilers can't compile such code, without knowing the template
parameters, so they ignore it, unless you actually call it.

Yes - VC will fail to diagnose many errors in uninstantiated templates.
It's a limitation of the way in which VC handles templates - they're
basically fancy macros and aren't really checked until the compiler tries to
instantiate them.

-cd