"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d3q1a9$1o1o$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:d3q02q$1nad$1@digitaldaemon.com...
> >
> > "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d3psac$1kr7$1@digitaldaemon.com...
> >> ah, you sneaky devil. You started messing with the Exception
inheritence
> >> tree! Do you have plans for the rest? :-)
> >
> > Well, SysError really was embarassingly bad. I have no other plans on it
> > at
> > the moment.
>
> ok. I have a silly question about SysError, though. The code in dmd-120
had
> hard-coded strings that mapped the same input error codes to the same strings on all platforms. Like you say that won't work since the error
codes
> aren't the same on different platforms. But why can't SysError on linux
call
> strerror?

Because there's a C strerror on Windows, indexed by C errno, and those errno's don't line up with the Windows getLastError values. There are two independent errno systems on Windows. I didn't think the two should be conflated together. Some RTL's try to merge the two by having the Windows values negated, but that strikes me as a too-confusing kludge as well.

> The error codes fed to the function are platform-dependent and the resulting string is platform-dependent but the purpose of the function
(map
> a platform-dependent error code to a platform-dependent string) is platform-independent. So off the top of my head I'd think a linux version using strerror would be ok.

Since the linux code generating a C errno value will likely be under a
version(linux) anyway, it is no problem to just have it call strerror()
directly (as I fixed the routines in Phobos to do).

> Since the linux code generating a C errno value will likely be under a
> version(linux) anyway, it is no problem to just have it call strerror()
> directly (as I fixed the routines in Phobos to do).

Does strerror return a char[]? Presumably one has to write
char*s  = strerror(err);
char[] ds = s[0 .. strlen(s)];
which is annoying when the Windows side has a nice function that returns a
char[].

I still encounter a runtime error "Stream is not seekable". But the apps compiled with V0.119 don't encounter that.

Shawn

"Walter" <newshound@digitalmars.com> :d3pc4b$19cp$1@digitaldaemon.com...
> Focus is on fixing compiler issues, especially the bugs introduced with 0.120.
>
> http://www.digitalmars.com/d/changelog.html
>
>
>
> 

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d3q5oa$1smg$1@digitaldaemon.com...
> > Since the linux code generating a C errno value will likely be under a
> > version(linux) anyway, it is no problem to just have it call strerror()
> > directly (as I fixed the routines in Phobos to do).
>
> Does strerror return a char[]? Presumably one has to write
> char*s  = strerror(err);
> char[] ds = s[0 .. strlen(s)];
> which is annoying when the Windows side has a nice function that returns a
> char[].

Take a look at std.file.

On Fri, 15 Apr 2005 21:18:50 -0700, Walter <newshound@digitalmars.com> wrote:
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
> news:d3q1a9$1o1o$1@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message
>> news:d3q02q$1nad$1@digitaldaemon.com...
>> >
>> > "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
>> > news:d3psac$1kr7$1@digitaldaemon.com...
>> >> ah, you sneaky devil. You started messing with the Exception
> inheritence
>> >> tree! Do you have plans for the rest? :-)
>> >
>> > Well, SysError really was embarassingly bad. I have no other plans on  
>> it
>> > at
>> > the moment.
>>
>> ok. I have a silly question about SysError, though. The code in dmd-120
> had
>> hard-coded strings that mapped the same input error codes to the same
>> strings on all platforms. Like you say that won't work since the error
> codes
>> aren't the same on different platforms. But why can't SysError on linux
> call
>> strerror?
>
> Because there's a C strerror on Windows, indexed by C errno, and those
> errno's don't line up with the Windows getLastError values. There are two
> independent errno systems on Windows.

True, this is a pain.

> I didn't think the two should be
> conflated together. Some RTL's try to merge the two by having the Windows
> values negated, but that strikes me as a too-confusing kludge as well.

Why is it confusing?
People should never refer to the error codes by number, but rather by defined name eg.

ENOENT - No such file or directory
EEXIST - File exists

Also from MSDN docs on GetLastError... "Error codes are 32-bit values (bit 31 is the most significant bit). Bit 29 is reserved for application-defined error codes; no system error code has this bit set. If you are defining an error code for your application, set this bit to one. That indicates that the error code has been defined by an application, and ensures that your error code does not conflict with any error codes defined by the system."

Assuming we decide not to merge them the soln appears to be to have a System(Error/Exception) to handle errno using strerror situations and Windows(Error/Exception) to handle GetLastError/WSAGetLastError using FormatMessage situations.

Regan

On Sat, 16 Apr 2005 21:51:22 +1200, Regan Heath <regan@netwin.co.nz> wrote:
> Also from MSDN docs on GetLastError... "Error codes are 32-bit values (bit 31 is the most significant bit). Bit 29 is reserved for application-defined error codes; no system error code has this bit set. If you are defining an error code for your application, set this bit to one. That indicates that the error code has been defined by an application, and ensures that your error code does not conflict with any error codes defined by the system."

Sorry. Meant to say that we could use bit 29 for defining the errno values. The re-define the range for user defined errors for D.

Regan

On Sat, 16 Apr 2005 22:14:22 +1200, Regan Heath <regan@netwin.co.nz> wrote:
> On Sat, 16 Apr 2005 21:51:22 +1200, Regan Heath <regan@netwin.co.nz> wrote:
>> Also from MSDN docs on GetLastError... "Error codes are 32-bit values (bit 31 is the most significant bit). Bit 29 is reserved for application-defined error codes; no system error code has this bit set. If you are defining an error code for your application, set this bit to one. That indicates that the error code has been defined by an application, and ensures that your error code does not conflict with any error codes defined by the system."
>
> Sorry. Meant to say that we could use bit 29 for defining the errno values. The re-define the range for user defined errors for D.

Having a really bad typing day.. "The re-define the range .." -> "Then re-define .."

Regan

"Walter" <newshound@digitalmars.com> wrote in message news:d3qiqi$2c3o$1@digitaldaemon.com...
>
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d3q5oa$1smg$1@digitaldaemon.com...
>> > Since the linux code generating a C errno value will likely be under a
>> > version(linux) anyway, it is no problem to just have it call strerror()
>> > directly (as I fixed the routines in Phobos to do).
>>
>> Does strerror return a char[]? Presumably one has to write
>> char*s  = strerror(err);
>> char[] ds = s[0 .. strlen(s)];
>> which is annoying when the Windows side has a nice function that returns
>> a
>> char[].
>
> Take a look at std.file.

For purposes of discussion std.file basically looks like
version(Windows) {
  class FooException {
     ...10 lines of code or so ...
     this(char[] x,uint errno) {
      this(x,sysErrorString(errno));
      ...
    }
  }
  ... Windows code ...
} else version (linux) {
  class FooException {
     ...same 10 lines of code as above ...
     this(char[] x,uint errno) {
      char* s = strerror(errno);
      this(x,<stringify>(s));
      ...
    }
  }
  ... Linux code ...
}

Naturally I'd prefer not to duplicate the definition of FooException in the different versions and instead have one definition that calls a common errno->string function (eg sysErrorString). It's cleaner IMO. But it's your call...

Can post or send me some reproduction steps?
thanks
-Ben

"Shawn Liu" <liuxuhong.cn@gmail.com> wrote in message news:d3qcgi$21vo$1@digitaldaemon.com...
>I still encounter a runtime error "Stream is not seekable". But the apps compiled with V0.119 don't encounter that.

File file = new File(hReadPipe, FileMode.In);
 while(!file.eof()){
  String s = file.readLine();
  if(s.length  == 0 )
   break;
  callback(s);
 }
 file.close();

Maybe this occured at file.readLine();


"Ben Hinkle" <ben.hinkle@gmail.com> :d3r7i4$2sm4$1@digitaldaemon.com...
> Can post or send me some reproduction steps?
> thanks
> -Ben
>
> "Shawn Liu" <liuxuhong.cn@gmail.com> wrote in message news:d3qcgi$21vo$1@digitaldaemon.com...
>>I still encounter a runtime error "Stream is not seekable". But the apps compiled with V0.119 don't encounter that.
>
>