Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005350OCamlOCaml generalpublic2011-08-27 19:402013-08-01 11:21
Reporterelfring 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version3.12.1 
Target Version4.01.0+devFixed in Version4.01.0+dev 
Summary0005350: Check return codes everywhere
DescriptionSome checks for return codes are missing.

Examples:
Would you like to add more error handling for return values from "lseek" like in the function "read_trailer" and from "fprintf" in the function "caml_trace_value_file"?
Additional Informationhttp://caml.inria.fr/cgi-bin/viewcvs.cgi/ocaml/trunk/byterun/startup.c?rev=11156&view=auto [^]
http://caml.inria.fr/cgi-bin/viewcvs.cgi/ocaml/trunk/byterun/instrtrace.c?rev=11156&view=auto [^]
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0006106)
elfring (reporter)
2011-08-27 21:50

I suggest to avoid unchecked function calls.
Would you like to detect every error situation as early as possible?

Another update candidate:
function "editbuffer_getasline" ? realloc()
http://caml.inria.fr/cgi-bin/viewcvs.cgi/ocaml/trunk/win32caml/editbuffer.c?rev=11156&view=auto [^]
(0007169)
lefessan (developer)
2012-03-26 16:05

"lseek" would indeed need a fix, but the other functions are mostly debug functions, where error handling is not important.
(0007172)
elfring (reporter)
2012-03-26 16:21

How do you think about a topic like "How to raise warning if return value is
disregarded - gcc or static code check?"?
http://stackoverflow.com/questions/2042780/how-to-raise-warning-if-return-value-is-disregarded-gcc-or-static-code-check [^]

How do you think about to apply aspect-oriented software development?
http://coccinelle.lip6.fr/ [^]
http://research.msrg.utoronto.ca/ACC/Tutorial#A_Reusable_Aspect_for_Memory_All [^]
http://aspectc.org/ [^]
(0010018)
dsheets (reporter)
2013-07-30 20:35

The return code lseek in read_trailer will never matter as the immediately subsequent read call will always fail if the lseek fails. This will result in a BAD_BYTECODE error.

Is there an actual error in the compiler that results from an unchecked return code that has turned up?

Without a bug reproduction or a listing of questionable code locations, I think this bug should be closed.
(0010057)
xleroy (administrator)
2013-08-01 11:21

Added check for lseek() in read_trailer(). (Commits r13959 in version/4.01 and r13960 in trunk.) I agree with dsheets that it's not really necessary, but the code is clearer this way. Debug printf's don't need checks.

- Issue History
Date Modified Username Field Change
2011-08-27 19:40 elfring New Issue
2011-08-27 21:50 elfring Note Added: 0006106
2012-03-26 16:05 lefessan Note Added: 0007169
2012-03-26 16:05 lefessan Assigned To => lefessan
2012-03-26 16:05 lefessan Status new => acknowledged
2012-03-26 16:21 elfring Note Added: 0007172
2012-07-06 16:22 doligez Target Version => 4.01.0+dev
2012-07-31 13:36 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-09-06 19:22 frisch Target Version 4.00.1+dev => 4.00.2+dev
2013-06-06 23:06 frisch Target Version 4.00.2+dev => 4.01.0+dev
2013-07-01 21:42 lefessan Assigned To lefessan =>
2013-07-01 21:42 lefessan Severity major => minor
2013-07-01 21:42 lefessan Target Version 4.01.0+dev => 4.02.0+dev
2013-07-12 18:15 doligez Target Version 4.02.0+dev => 4.01.1+dev
2013-07-30 20:35 dsheets Note Added: 0010018
2013-08-01 11:21 xleroy Note Added: 0010057
2013-08-01 11:21 xleroy Status acknowledged => resolved
2013-08-01 11:21 xleroy Resolution open => fixed
2013-08-01 11:21 xleroy Fixed in Version => 4.01.0+dev
2013-08-01 11:21 xleroy Target Version 4.01.1+dev => 4.01.0+dev


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker