Bug 137526 - missing return statement
missing return statement
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: macutils (Show other bugs)
3
All Linux
low Severity low
: ---
: ---
Assigned To: Jindrich Novy
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-29 05:27 EDT by David Binderman
Modified: 2013-07-02 19:03 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-02 04:17:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Binderman 2004-10-29 05:27:44 EDT
Description of problem:

I just tried to compile package macutils-2.0b3-29 from 
Redhat Fedora Core 3 Test 3.

The compiler said

hqx.c(392): remark #1011: missing return statement at end of non-void
function "getqbuf"

Upon inspection of the source code, I recommend either adding a return
statement or marking the return type of the function as void.

The code could also be improved by using ISO C function definition.
K&R style has been deprecated since the 1980s.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jindrich Novy 2004-10-29 07:22:52 EDT
I see no such remark while compiling macutils 2.0b3-29. Please note
that this does not affect functionality of macutils so I set both
priority and severity to low.

The message of compiler output you presented seems not to be very
common. Which compiler do you use? Please post here "gcc --version" if
you use gcc or write to me which compiler do you use.

thanks,
Jindrich
Comment 2 David Binderman 2004-10-29 11:13:21 EDT
>I set both priority and severity to low.

Ok, fine.

>Which compiler do you use?

Intel 8.1 It is much better than gcc - both for warning messages
and code generation.
Comment 3 Jindrich Novy 2004-10-30 12:20:03 EDT
The Intel(R) compiler is not supported at all because it's
proprietary. So when using it we would be dependent on Intel's
decisions and couldn't fix possible bugs ourselves what is in direct
conflict with our idea of open-source development.

Please do not file any more bugs in bugzilla when some application is
not compilable by icc or when it shows any warnings.

gcc has plenty of warning options and generates a very good optimized
code not only for Intel(R) processors but almost for any platform
where you can run GNU/Linux. Furthermore it's free.

Regarding the old K&R C style in macutils I think I shouldn't fix it,
because it would require a complete rewrite of macutils what is
pointless since the utilities are working fine for years and by
correcting the style I could cause some bugs.

Jindrich
Comment 4 David Binderman 2004-10-31 05:18:14 EST
>The Intel(R) compiler is not supported at all because it's
>proprietary. So when using it we would be dependent on Intel's
>decisions and couldn't fix possible bugs ourselves what is in direct
>conflict with our idea of open-source development.

Perhaps there is some confusion. I'm not asking you to use Intel
compiler - I'm just expressing an opinion that I think it's better.

>Please do not file any more bugs in bugzilla when some application is
>not compilable by icc or when it shows any warnings.

Thanks - can I assume that even where the Fedora source code is 
broken and Intel finds a fault and gcc can't find the fault, then you
still don't want to know about it ?

>gcc has plenty of warning options 

Intel has more, and they are numbered. There are about 1600 warning
messages.

>and generates a very good optimized
>code not only for Intel(R) processors but almost for any platform
>where you can run GNU/Linux. Furthermore it's free.

Intel runs on Intel and Intel compatibles only. 

In tests, it beats gcc by 10-20% usually.

>Regarding the old K&R C style in macutils I think I shouldn't fix it,
>because it would require a complete rewrite of macutils what is
>pointless since the utilities are working fine for years and by
>correcting the style I could cause some bugs.

More confusion. I'm not asking for a complete re-write - I'm
just asking for this particular function to be improved.

The function is certainly broken and certainly old. I think I
am on safe ground suggesting an improvement.
Comment 5 Jindrich Novy 2004-11-02 04:17:23 EST
The recommended strategy is to report this improvement upstream, so
that it's fixed for all the distributions using macutils in the next
release. 

Note You need to log in before you can comment on or make changes to this bug.