April 18, 2005
"Walter" <newshound@digitalmars.com> wrote in message news:d3up2a$2isn$1@digitaldaemon.com...
>
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d3u9er$25ev$1@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message news:d3sk8r$qgo$1@digitaldaemon.com...
>> > But there can't be a common errno->string function, as C errno and
> Windows
>> > errno coexist, but are different.
>>
>> I'm not sure what you mean by different. They have different errors and numbers and strings but the concept of mapping an error code to a string
> is
>> independent of all that.
>
> What are you going to do with Windows code that calls C's read() function?

Have users deal with it themselves. IMO each platform has a "natural" platform-specific set of error codes and a code->string mapping function. Everything else requires the user calling the right function by hand (which is no worse than what's in dmd-121). As long as sysErrorString documents what it does on each platform the only downside would be if someone doesn't know what error codes they have or if a system doesn't have any natural choice of codes or mapping (in which case one can say sysErrorString isn't supported on that platform).


April 19, 2005
"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d40u2o$1jho$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:d3up2a$2isn$1@digitaldaemon.com...
> >
> > "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d3u9er$25ev$1@digitaldaemon.com...
> >>
> >> "Walter" <newshound@digitalmars.com> wrote in message news:d3sk8r$qgo$1@digitaldaemon.com...
> >> > But there can't be a common errno->string function, as C errno and
> > Windows
> >> > errno coexist, but are different.
> >>
> >> I'm not sure what you mean by different. They have different errors and numbers and strings but the concept of mapping an error code to a
string
> > is
> >> independent of all that.
> >
> > What are you going to do with Windows code that calls C's read()
function?
>
> Have users deal with it themselves. IMO each platform has a "natural" platform-specific set of error codes and a code->string mapping function. Everything else requires the user calling the right function by hand
(which
> is no worse than what's in dmd-121). As long as sysErrorString documents what it does on each platform the only downside would be if someone
doesn't
> know what error codes they have or if a system doesn't have any natural choice of codes or mapping (in which case one can say sysErrorString isn't supported on that platform).

D is supposed to be able to interface directly with C. So on one platform calling standard C routines, one will use errno and use sysErrorString. Then, the *exact same code* on Windows will fail mysteriously at runtime.


April 19, 2005
> D is supposed to be able to interface directly with C. So on one platform calling standard C routines, one will use errno and use sysErrorString. Then, the *exact same code* on Windows will fail mysteriously at runtime.

True, though I would expect that if the user wants to just call standard C routines they should use strerror instead of sysErrorCode. Why would they switch and start using a non-C routine to handle their standard C error? It's debatable whether more bugs will be introduced due to code duplication (and the code rot it turns into) like FileException than by calling sysErrorString by accident. If you don't like putting the version switch in sysErrorString at least put it into FileException so that isn't so much copy/paste of code.


April 20, 2005
"Walter" <newshound@digitalmars.com> wrote in news: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
> 

Would be nice if deprecated aliases were added for renamed things so that the old names will still work for awhile.
1 2 3 4 5
Next ›   Last »