Hello. Could you please advise a good way to obtain the errno value. I use the following way but I don't like it:
cat errno.c
#include <errno.h> int get_errno (void) { return errno; }
cat errno.sml
open Foreign val errnolib = loadLibrary "errno.so" val get_errno = buildCall0 ((getSymbol errnolib "get_errno"), (), cInt) fun main () = print ("errno=" ^ (Int.toString (get_errno())) ^ "\n")
cc -shared -o errno.so errno.c polyc -o errno errno.sml
env LD_LIBRARY_PATH=. ./errno
errno=0
The difficulty with getting errno in this way is that by the time you get it it may have changed from the value it had. Any calls to the run-time system may involve a system call that could affect it.
What are you trying to get the value of errno from? If you are using the FFI to call a function that may set errno you really need to either return it as part of the result or save it away somewhere so you can get it later.
David
On 11/11/2016 17:46, Kostirya wrote:
Hello. Could you please advise a good way to obtain the errno value. I use the following way but I don't like it:
cat errno.c
#include <errno.h> int get_errno (void) { return errno; }
cat errno.sml
open Foreign val errnolib = loadLibrary "errno.so" val get_errno = buildCall0 ((getSymbol errnolib "get_errno"), (), cInt) fun main () = print ("errno=" ^ (Int.toString (get_errno())) ^ "\n")
cc -shared -o errno.so errno.c polyc -o errno errno.sml
env LD_LIBRARY_PATH=. ./errno
errno=0 _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
* David Matthews:
The difficulty with getting errno in this way is that by the time you get it it may have changed from the value it had. Any calls to the run-time system may involve a system call that could affect it.
Would it make sense to use a special return type which instructs PolyML to obtain the errno value at the time of return? This would address the synchronization issue.
I'm still thinking about this. It would certainly be useful to get the error result: errno in Unix and GetLastError and possibly also errno in Windows. It don't see a way to specify this as a return type in the FFI calls.
The main problem is that there can be invisible calls into the run-time system as a result of either heap exhaustion or stack overflow. As a first step perhaps the error state should be saved explicitly across these so it doesn't change under the feet of the application.
David
On 13/11/2016 11:49, Florian Weimer wrote:
- David Matthews:
The difficulty with getting errno in this way is that by the time you get it it may have changed from the value it had. Any calls to the run-time system may involve a system call that could affect it.
Would it make sense to use a special return type which instructs PolyML to obtain the errno value at the time of return? This would address the synchronization issue. _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
Hello, David. I saw your PolyML last commits on github. I'm impressed! You've considered all my remarks! Many thanks!
P.S. Foreign.Error.getLastError will be very useful for https://github.com/kni/sml-iconv :-)
2016-11-15 18:35 GMT+02:00 David Matthews <David.Matthews at prolingua.co.uk>:
I'm still thinking about this. It would certainly be useful to get the error result: errno in Unix and GetLastError and possibly also errno in Windows. It don't see a way to specify this as a return type in the FFI calls.
The main problem is that there can be invisible calls into the run-time system as a result of either heap exhaustion or stack overflow. As a first step perhaps the error state should be saved explicitly across these so it doesn't change under the feet of the application.
David
On 13/11/2016 11:49, Florian Weimer wrote:
- David Matthews:
The difficulty with getting errno in this way is that by the time you get it it may have changed from the value it had. Any calls to the run-time system may involve a system call that could affect it.
Would it make sense to use a special return type which instructs PolyML to obtain the errno value at the time of return? This would address the synchronization issue. _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
I've been thinking a bit about this for a while. The new interface to the run-time system uses something like yje FFI calling process but there are two different forms. The simpler, faster form can be used if the C++ code does not need to allocate memory or raise an exception. Otherwise the more general form has to be used. Many of the run-time calls currently raise exceptions if there is an error so have to use the general form. Adding the ability to test the error result would allow the exception to be raised in ML code.
Just to explain what I've done for those who haven't looked at the commits: there is now an extra sub-structure in the Foreign structure, Error. This has signature: structure Error: sig val getLastError: unit -> SysWord.word val setLastError: SysWord.word -> unit type syserror = OS.syserror val fromWord: SysWord.word -> syserror val toWord: syserror -> SysWord.word end
getLastError returns the value of errno on Unix/Cygwin and GetLastError in Windows. setLastError sets errno or calls SetLastError. fromWord and toWord are the same as Posix.Error.fromWord/toWord but I've provided them because that structure isn't present in Windows.
David
On 07/12/2016 07:29, Kostirya wrote:
Hello, David. I saw your PolyML last commits on github. I'm impressed! You've considered all my remarks! Many thanks!
P.S. Foreign.Error.getLastError will be very useful for https://github.com/kni/sml-iconv :-)
2016-11-15 18:35 GMT+02:00 David Matthews <David.Matthews at prolingua.co.uk>:
I'm still thinking about this. It would certainly be useful to get the error result: errno in Unix and GetLastError and possibly also errno in Windows. It don't see a way to specify this as a return type in the FFI calls.
The main problem is that there can be invisible calls into the run-time system as a result of either heap exhaustion or stack overflow. As a first step perhaps the error state should be saved explicitly across these so it doesn't change under the feet of the application.
David
On 13/11/2016 11:49, Florian Weimer wrote:
- David Matthews:
The difficulty with getting errno in this way is that by the time you get it it may have changed from the value it had. Any calls to the run-time system may involve a system call that could affect it.
Would it make sense to use a special return type which instructs PolyML to obtain the errno value at the time of return? This would address the synchronization issue. _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
-
David.Matthews＠prolingua.co.uk -
fw＠deneb.enyo.de -
kostirya＠gmail.com