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







getErrno(), but it seems like library functions never reset errno unless







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




 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 






 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




 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.



 attempt to fake the unix errno behavior. It is not part of the Windows




 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.



 attempt to fake the unix errno behavior. It is not part of the Windows




 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,




No, I have found that out by now.

Well, three out of four is not bad :-)

Regards,
Martin



 Aug 18 2004