New ANSI C (ANSI C 95?) suggestion 
Author Message
 New ANSI C (ANSI C 95?) suggestion


Quote:

>He's no longer with us, (thankfully!), but his sloppy code lives on.  
>Checking the return values of functions can save you MANY frustrating
>hours of debugging.  

How about adding a ``forced'' keyword to the language for the next
standard revision, meaning a return value which cannot be ignored?
OK, it won't force checking of the results from malloc, but it will at
least make it impossible to assume functions that return an error code
always will work...
Any other suggestions for how to handle this problem?

--
Eivind Eklund AKA Vishnu/CRB

FUNCOM don't speak for me, and I return the courtesy.



Sat, 03 Jan 1998 03:00:00 GMT  
 New ANSI C (ANSI C 95?) suggestion

Quote:

>How about adding a ``forced'' keyword to the language for the next
>standard revision, meaning a return value which cannot be ignored?
>OK, it won't force checking of the results from malloc, but it will at
>least make it impossible to assume functions that return an error code
>always will work...
>Any other suggestions for how to handle this problem?

Lint already checks for this, and compilers could issue a warning if they
wanted to. There is no need to add to the language.

+--------------------------------------------+
|              Michael Quinlan               |

|       http://www.primenet.com/~mikeq       |
+--------------------------------------------+



Sat, 03 Jan 1998 03:00:00 GMT  
 New ANSI C (ANSI C 95?) suggestion


|>How about adding a ``forced'' keyword to the language for the next
|>standard revision, meaning a return value which cannot be ignored?
|>OK, it won't force checking of the results from malloc, but it will at
|>least make it impossible to assume functions that return an error code
|>always will work...
|>Any other suggestions for how to handle this problem?

How about doing it the other way around and stick a `(void)' cast
in front of every function call which return value is intentionally
ignored and let Lint do the rest of the complaining?

kind regards,


--
Qgi rgw d&xj nicws nt swaj ri rgw eufgr>



Sat, 03 Jan 1998 03:00:00 GMT  
 New ANSI C (ANSI C 95?) suggestion

Quote:

>How about adding a ``forced'' keyword to the language for the next
>standard revision, meaning a return value which cannot be ignored?

Bad idea, sorry.  The entire C language is based upon the premise that "the
programmer knows best."  If you start adding things to the language that
serve no purpose other than to "improve the programmer's programming style"
then you might as well make a whole slew of other "force the programmer to
follow good coding practice" changes as well - if you want, I'll be happy to
mail you my top 10 list.  If you want a language which hand holds the
programmer then you don't want C.

Another, and probably more contriversial, answer to your proposal is that it
is bass-ackwards.  It's not the job of the person who wrote the function to
tell me (the caller) that I have to check the function return value.  After
returning the value, the function programmer's responsibility ends.  It is my
job as the caller to decide (from within the context in which I am making the
call) whether or not it is appropriate to check the return value.  The answer
to whether or not it is appropriate is almost always "yes", but it is still
my (the caller's) decision.
--
Ron McFarland



Sun, 04 Jan 1998 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Newbie: separate big .cs file into small .cs files

2. New ANSI C standard ? ANSI vs ISO/IEC

3. To ANSI or not to ANSI (was: Re: Just a minor new twist on free())

4. Form1.cs on new applications

5. Any ANSI-C compilers for Windows'95?

6. ANSI C -- miscellaneous suggestions

7. Need good suggestions for ANSI C compiler!

8. How to show/call Form2.cs from Form1.cs ?

9. Include code in other Cs files

10. Reuse of cs files, namespace, arch advice pls

11. word - automatic numbering/bold/underline/italics

12. How to Generate .cs file at Runtime

 

 
Powered by phpBB® Forum Software