www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Setting errno?

reply Nick <Nick_member pathlink.com> writes:
Is there any simple way to set the unix error value errno to zero? D implements
getErrno(), but it seems like library functions never reset errno unless a new
error occurs.

Nick
Aug 15 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cfns9k$m9f$1 digitaldaemon.com>, Nick says...
Is there any simple way to set the unix error value errno to zero? D implements
getErrno(), but it seems like library functions never reset errno unless a new
error occurs.

Nick
I don't know the answer to this, but in any case, I'm not sure it's a practice we should be encouraging. The manual section "Error Handling in D" at http://www.digitalmars.com/d/errors.html explains why I think using errno is not a good idea. Arcane Jill
Aug 15 2004
parent Nick <Nick_member pathlink.com> writes:
In article <cfntcf$mq7$1 digitaldaemon.com>, Arcane Jill says...
I don't know the answer to this, but in any case, I'm not sure it's a practice
we should be encouraging. The manual section "Error Handling in D" at
http://www.digitalmars.com/d/errors.html explains why I think using errno is not
a good idea.
I agree with this, but my use for errno is strictly for interfacing with C library functions, not for writing new code using this method of error reporting. I plan to encapsulate the errno entirely inside a class, making the internal workings invisible to the user. You can then write wrapper functions like this // Sets errno on failure extern(C) { char *some_func(int); } char[] someWrapper(int a) { char *p = some_func(a); if( Errno.error() ) throw new MyException(Errno.msg()); // Errno.msg() also 'clears' the error return std.string.toString(p); } The last part, where msg() clears the error, is hard to do if you can't change errno. Nick
Aug 15 2004
prev sibling parent reply Nick <Nick_member pathlink.com> writes:
In article <cfns9k$m9f$1 digitaldaemon.com>, Nick says...
Is there any simple way to set the unix error value errno to zero? D implements
getErrno(), but it seems like library functions never reset errno unless a new
error occurs.
Nevermind, I settled for just writing it in C myself. Nick
Aug 15 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Nick" <Nick_member pathlink.com> wrote in message
news:cfo8u7$u1i$1 digitaldaemon.com...
 In article <cfns9k$m9f$1 digitaldaemon.com>, Nick says...
Is there any simple way to set the unix error value errno to zero? D
implements
getErrno(), but it seems like library functions never reset errno unless
a new
error occurs.
Nevermind, I settled for just writing it in C myself.
You kind of have to write setErrno() in C, because errno is typically defined as a macro in <errno.h>. This is why getErrno() is written in C.
Aug 15 2004
parent reply Nick <Nick_member pathlink.com> writes:
In article <cfoao7$v10$1 digitaldaemon.com>, Walter says...
You kind of have to write setErrno() in C, because errno is typically
defined as a macro in <errno.h>. This is why getErrno() is written in C.
Yep. But I was sort of hoping you would put it in phobos like you did with getErrno() so I wouldn't have to drag along the extra object file all the time. But it's really no big deal. Nick
Aug 15 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Nick" <Nick_member pathlink.com> wrote in message
news:cfocpc$10ac$1 digitaldaemon.com...
 In article <cfoao7$v10$1 digitaldaemon.com>, Walter says...
You kind of have to write setErrno() in C, because errno is typically
defined as a macro in <errno.h>. This is why getErrno() is written in C.
Yep. But I was sort of hoping you would put it in phobos like you did with getErrno() so I wouldn't have to drag along the extra object file all the
time.
 But it's really no big deal.
I'll add it to std.c.linux.linux
Aug 15 2004
next sibling parent Nick <Nick_member pathlink.com> writes:
In article <cfpkqs$1qpv$1 digitaldaemon.com>, Walter says...
I'll add it to std.c.linux.linux
Thanks a bunch then ;-) Nick
Aug 16 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Sun, 15 Aug 2004 23:31:27 -0700, Walter <newshound digitalmars.com> 
wrote:

 "Nick" <Nick_member pathlink.com> wrote in message
 news:cfocpc$10ac$1 digitaldaemon.com...
 In article <cfoao7$v10$1 digitaldaemon.com>, Walter says...
You kind of have to write setErrno() in C, because errno is typically
defined as a macro in <errno.h>. This is why getErrno() is written in 
C.

 Yep. But I was sort of hoping you would put it in phobos like you did 
 with
 getErrno() so I wouldn't have to drag along the extra object file all 
 the
time.
 But it's really no big deal.
I'll add it to std.c.linux.linux
What about windows? errno exists on windows too. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 16 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opscur54d55a2sq9 digitalmars.com...
 I'll add it to std.c.linux.linux
What about windows? errno exists on windows too.
errno really only exists in the windows C compiler runtime libraries as an attempt to fake the unix errno behavior. It is not part of the Windows API. My intention is to skip the errno "middleman" on Win32 and go straight to the Win32 API, where GetLastError() does the trick.
Aug 16 2004
parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Walter" <newshound digitalmars.com> skrev i en meddelelse
news:cfs2ol$kr9$1 digitaldaemon.com...
 What about windows? errno exists on windows too.
errno really only exists in the windows C compiler runtime libraries as an attempt to fake the unix errno behavior. It is not part of the Windows
API.
 My intention is to skip the errno "middleman" on Win32 and go straight to
 the Win32 API, where GetLastError() does the trick.
I think this is an unhealthy decision for several reasons: 1. I remember using C functions where the only way to determine if an error occurred or not, was to reset errno first, call the function, and then check if errno had been set. Without setErrno() such functions are rendered useless. 2. D might be used to implement libraries callable from C. setErrno() might be needed to communicate errors back. Without it an otherwise unneccesary layer of wrapping will be needed - something that I believe you yourself has strong negative feelings about. 3. In a multithreaded application, a thread-instance of errno is way better than SetLastError() and GetLastError(). 4. Leaving setErrno() out on Windows, you are placing an extra burden on the D developer that needs to maintain portable code. I hope this will help you reconsider. Regards, Martin
Aug 17 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message
news:cftl46$1cng$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> skrev i en meddelelse
 news:cfs2ol$kr9$1 digitaldaemon.com...
 What about windows? errno exists on windows too.
errno really only exists in the windows C compiler runtime libraries as an attempt to fake the unix errno behavior. It is not part of the Windows
API.
 My intention is to skip the errno "middleman" on Win32 and go straight to
 the Win32 API, where GetLastError() does the trick.
I think this is an unhealthy decision for several reasons: 1. I remember using C functions where the only way to determine if an error occurred or not, was to reset errno first, call the function, and then check if errno had been set. Without setErrno() such functions are rendered useless. 2. D might be used to implement libraries callable from C. setErrno() might be needed to communicate errors back. Without it an otherwise unneccesary layer of wrapping will be needed - something that I believe you yourself has strong negative feelings about. 3. In a multithreaded application, a thread-instance of errno is way better than SetLastError() and GetLastError().
Are you saying the the Win32 error number is not thread-specific? If so, that's not correct.
 4. Leaving setErrno() out on Windows, you are placing an extra burden on the
 D developer that needs to maintain portable code.


 I hope this will help you reconsider.
I agree.
Aug 17 2004
parent "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Matthew" <admin.hat stlsoft.dot.org> skrev i en meddelelse
news:cfu9io$1lpv$1 digitaldaemon.com...
 Are you saying the the Win32 error number is not thread-specific? If so,
that's not correct. No, I have found that out by now. Well, three out of four is not bad :-) Regards, Martin
Aug 18 2004