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

  • Thread starter Thread starter Michael Kennedy [UB]
  • Start date Start date
M

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::ReplayFillBuffer()
{
CFile* pFile = NULL;
for(int i=0; i<m_FileList.GetCount(); i++)
{
pFile = m_FileList.GetAt ;
}
}
---------------------------------------------

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
 
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]" <[email protected]>
| 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: <#[email protected]>
| Newsgroups: microsoft.public.dotnet.languages.vc
| NNTP-Posting-Host: 130.191.240.187
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.vc:29661
| X-Tomcat-NG: microsoft.public.dotnet.languages.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::ReplayFillBuffer()
| {
| CFile* pFile = NULL;
| for(int i=0; i<m_FileList.GetCount(); i++)
| {
| pFile = m_FileList.GetAt ;
| }
| }
| ---------------------------------------------
|
| 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
|
|
|
 
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::ReplayFillBuffer'
: 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.
--------------------
 
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
 
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]" <[email protected]>
| References: <#[email protected]>
<[email protected]>
| 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: <[email protected]>
| Newsgroups: microsoft.public.dotnet.languages.vc
| NNTP-Posting-Host: 130.191.240.187
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.vc:29681
| X-Tomcat-NG: microsoft.public.dotnet.languages.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
|
| | > 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::ReplayFillBuffer'
| > : 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.
| > --------------------
| >
|
|
|
 
Hi Gary,

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

Regards,
Michael

Gary Chang said:
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]" <[email protected]>
| References: <#[email protected]>
<[email protected]>
| 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: <[email protected]>
| Newsgroups: microsoft.public.dotnet.languages.vc
| NNTP-Posting-Host: 130.191.240.187
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.vc:29681
| X-Tomcat-NG: microsoft.public.dotnet.languages.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
|
| | > 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::ReplayFillBuffer'
| > : 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.
| > --------------------
| >
|
|
|
Click to expand...
 
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 said:
Hi Gary,

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

Regards,
Michael

Gary Chang said:
Hi Michael,

Thanks for your response!

I agree with you on this point: "The compilier seems do not want to
Click to expand...
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]" <[email protected]>
| References: <#[email protected]>
<[email protected]>
| 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: <[email protected]>
| Newsgroups: microsoft.public.dotnet.languages.vc
| NNTP-Posting-Host: 130.191.240.187
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.vc:29681
| X-Tomcat-NG: microsoft.public.dotnet.languages.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
|
| | > Hi Micheal,
| >
| > I think you hadn't called the inline method in your code, if you
Click to expand...
add
a
| > call to it , you should get a "error C4716:
| 'CReplayBase::ReplayFillBuffer'
| > : 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.
| > --------------------
| >
|
|
|
Click to expand...
Click to expand...
 
Keith said:
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.
Click to expand...

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
 
Back
Top