Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #145998 > unrolled thread

error_t proposal

Back to article view | Back to comp.lang.c

Contents

  error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-04 14:14 -0700
    Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-04 15:20 -0700
      Re: error_t proposal Mateusz Viste <mateusz@wont.tell> - 2019-09-05 08:02 +0000
        Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 04:04 -0700
          Re: error_t proposal Bruce S <bruces42@hotmail.com> - 2019-09-05 08:18 -0600
            Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-05 14:31 -0700
              Re: error_t proposal James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-05 17:49 -0400
                Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-05 15:14 -0700
              Re: error_t proposal Bruce S <bruces42@hotmail.com> - 2019-09-06 14:03 -0600
    Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-05 09:30 +1000
      Re: error_t proposal Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-05 02:38 -0700
      Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 04:57 -0700
        Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 05:16 -0700
          Re: error_t proposal Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-05 05:35 -0700
            Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 06:08 -0700
              Re: error_t proposal Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-05 06:16 -0700
                Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 06:37 -0700
                  Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 07:04 -0700
                    Re: error_t proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-05 20:51 +0100
                      Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 13:52 -0700
                        Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-05 14:56 -0700
                Re: error_t proposal William Ahern <william@25thandClement.com> - 2019-09-05 13:18 -0700
                Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-06 07:25 +1000
        Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-06 07:35 +1000
          Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 04:22 -0700
      Re: error_t proposal scott@slp53.sl.home (Scott Lurndal) - 2019-09-05 13:59 +0000
        Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-06 07:10 +1000
    Re: error_t proposal Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-05 10:01 +0000
      Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 04:36 -0700
        Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-05 14:43 -0700
          Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 05:01 -0700
            Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-06 11:18 -0700
              Re: error_t proposal scott@slp53.sl.home (Scott Lurndal) - 2019-09-06 19:34 +0000
              Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 12:37 -0700
                Re: error_t proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-06 20:54 +0100
                  Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-06 13:20 -0700
                    Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 13:43 -0700
                      Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-06 14:25 -0700
                        Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 15:14 -0700
                          Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-06 15:49 -0700
                            Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 18:44 -0700
                              Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-07 12:35 +1000
                                Re: error_t proposal Ike Naar <ike@sdf.lonestar.org> - 2019-09-08 20:15 +0000
                                  Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-09 09:30 +1000
                                    Re: error_t proposal Ike Naar <ike@iceland.freeshell.org> - 2019-09-09 07:35 +0000
                                      Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-09 19:44 +1000
                                    Re: error_t proposal scott@slp53.sl.home (Scott Lurndal) - 2019-09-09 13:58 +0000
                                    Re: error_t proposal Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-10 14:24 +0000
                                      Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-11 09:22 +1000
                                        Re: error_t proposal Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-10 16:48 -0700
                                          Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-11 10:45 +1000
                    Re: error_t proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-06 21:47 +0100
    Re: error_t proposal jadill33@gmail.com - 2019-09-05 07:04 -0700
      Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 07:36 -0700
        Re: error_t proposal jadill33@gmail.com - 2019-09-05 08:43 -0700

Page 1 of 3  [1] 2 3  Next page →

#145998 — error_t proposal

In my experience, most of the time I don't need to check
for specific errors.

For instance, I rarely need to do this:

if (error == specific_error) { 
 /*do something*/
}

in general I just check for general errors:

if (error != error_success) {
 /*do something*/
}

Some libraries uses 0 to say "no error" and others use
1 or true do say "no error".

My suggestion is to add at <errno.h>

typedef int error_t
and a enum item  std_success


If you look at existing code, for instance

int thrd_create( thrd_t *thr, thrd_start_t func, void *arg );
"thrd_success if the creation of the new thread was successful."


int bind(SOCKET s, const sockaddr *addr, int namelen);
"If no error occurs, bind returns zero. Otherwise, it returns SOCKET_ERROR, and a specific error code can be "

You will see different approaches.

But I think it should be more universal and library implementers
could use the same typedef.

Let's say

error_t MyLibFunc();

then I could use 

error_t er = MyLibFunc();

if (er != std_success)
{
  printf("%s", MyLibErrorToString(er));
}

and then automatically, the programmer that is using that lib
knows how do check for errors.


What do you think?
How do you propagate errors? Do you create your own type?
Do you use enun or int? 
How do you integrate errors from thirty party libs in our own
errors?


Apart of that some range could be reserved for known errors.
E.g nomen or io errors.

then errors like

thrd_nomem 

would not need a specific namespaces.

[toc] | [next] | [standalone]

#146001

Thiago Adams <thiago.adams@gmail.com> writes:
> In my experience, most of the time I don't need to check
> for specific errors.
>
> For instance, I rarely need to do this:
>
> if (error == specific_error) { 
>  /*do something*/
> }
>
> in general I just check for general errors:
>
> if (error != error_success) {
>  /*do something*/
> }
>
> Some libraries uses 0 to say "no error" and others use
> 1 or true do say "no error".
[...]

What libraries use 1 to denote "no error"?

In my experience, error codes in C are almost always zero for
success, non-zero for failure (with either the value or errno
providing more information about the error).  (My experience does
have a UNIX/POSIX/Linux bias.)

Some functions (not many in the standard library) might return 0
for "false" and 1 or non-zero for "true" (for example isdigit()
et al), but for those functions "false" is not an error, just a
piece of information.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#146007

On Wed, 04 Sep 2019 15:20:06 -0700, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> Some libraries uses 0 to say "no error" and others use 1 or true do say
>> "no error".
> [...]
> 
> What libraries use 1 to denote "no error"?
>
> In my experience, error codes in C are almost always zero for success,
> non-zero for failure (with either the value or errno providing more
> information about the error).  (My experience does have a
> UNIX/POSIX/Linux bias.)

Your experience missed inet_pton() then. :)
But yes - it is quite an exception.

Mateusz

[toc] | [prev] | [next] | [standalone]

#146011

On Thursday, September 5, 2019 at 5:02:25 AM UTC-3, Mateusz Viste wrote:
> On Wed, 04 Sep 2019 15:20:06 -0700, Keith Thompson wrote:
> > Thiago Adams  writes:
> >> Some libraries uses 0 to say "no error" and others use 1 or true do say
> >> "no error".
> > [...]
> > 
> > What libraries use 1 to denote "no error"?
> >
> > In my experience, error codes in C are almost always zero for success,
> > non-zero for failure (with either the value or errno providing more
> > information about the error).  (My experience does have a
> > UNIX/POSIX/Linux bias.)
> 
> Your experience missed inet_pton() then. :)
> But yes - it is quite an exception.

Windows API has several functions returning BOOL where non zero
is success. Zero is error and then GetLastError is used.

BOOL DeleteFileA(LPCSTR lpFileName);

[toc] | [prev] | [next] | [standalone]

#146028

On 9/5/19 5:04 AM, Thiago Adams wrote:
> On Thursday, September 5, 2019 at 5:02:25 AM UTC-3, Mateusz Viste wrote:
>> On Wed, 04 Sep 2019 15:20:06 -0700, Keith Thompson wrote:
>>> Thiago Adams  writes:
>>>> Some libraries uses 0 to say "no error" and others use 1 or true do say
>>>> "no error".
>>> [...]
>>>
>>> What libraries use 1 to denote "no error"?
>>>
>>> In my experience, error codes in C are almost always zero for success,
>>> non-zero for failure (with either the value or errno providing more
>>> information about the error).  (My experience does have a
>>> UNIX/POSIX/Linux bias.)
>>
>> Your experience missed inet_pton() then. :)
>> But yes - it is quite an exception.
> 
> Windows API has several functions returning BOOL where non zero
> is success. Zero is error and then GetLastError is used.
> 
> BOOL DeleteFileA(LPCSTR lpFileName);

IIRC from my VAX days, their library functions returned an odd value for
success, an even one for error.  So 1 would be *one of* the many, many
values denoting "no error".  Unfortunately, the libraries we built to
work in that environment followed the same approach.  I don't recall
ever having code that depended on exactly which "success" code was
returned, though there were plenty that depended on specific errors.

[toc] | [prev] | [next] | [standalone]

#146043

Bruce S <bruces42@hotmail.com> writes:
> On 9/5/19 5:04 AM, Thiago Adams wrote:
>> On Thursday, September 5, 2019 at 5:02:25 AM UTC-3, Mateusz Viste wrote:
>>> On Wed, 04 Sep 2019 15:20:06 -0700, Keith Thompson wrote:
>>>> Thiago Adams  writes:
>>>>> Some libraries uses 0 to say "no error" and others use 1 or true do say
>>>>> "no error".
>>>> [...]
>>>>
>>>> What libraries use 1 to denote "no error"?
>>>>
>>>> In my experience, error codes in C are almost always zero for success,
>>>> non-zero for failure (with either the value or errno providing more
>>>> information about the error).  (My experience does have a
>>>> UNIX/POSIX/Linux bias.)
>>>
>>> Your experience missed inet_pton() then. :)
>>> But yes - it is quite an exception.
>> 
>> Windows API has several functions returning BOOL where non zero
>> is success. Zero is error and then GetLastError is used.
>> 
>> BOOL DeleteFileA(LPCSTR lpFileName);
>
> IIRC from my VAX days, their library functions returned an odd value for
> success, an even one for error.  So 1 would be *one of* the many, many
> values denoting "no error".  Unfortunately, the libraries we built to
> work in that environment followed the same approach.  I don't recall
> ever having code that depended on exactly which "success" code was
> returned, though there were plenty that depended on specific errors.

VMS (VAX is the hardware, which can also run Unix) does the same for the
return status of a program -- which is probably part of the reason we
have the EXIT_SUCCESS and EXIT_FAILURE macros in <stdlib.h>.  When I
worked on VMS, I sometimes ran into C programs that used "return 1;" or
"exit(1);" to indicate failure, but that indicates success on VMS.

(But "return 0;" or "exit(0);" is required to return a successful
status, even though the OS treats that as a failure code.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#146046

On 9/5/19 5:31 PM, Keith Thompson wrote:
...
> VMS (VAX is the hardware, which can also run Unix) does the same for the
> return status of a program -- which is probably part of the reason we
> have the EXIT_SUCCESS and EXIT_FAILURE macros in <stdlib.h>.  When I
> worked on VMS, I sometimes ran into C programs that used "return 1;" or
> "exit(1);" to indicate failure, but that indicates success on VMS.
> 
> (But "return 0;" or "exit(0);" is required to return a successful
> status, even though the OS treats that as a failure code.)

"If the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status _successful termination_ is
returned." (7.20.4.3p5).
I don't believe that a status which the OS treats as a failure code
could qualify as a successful status. On a platform where successful
statuses are indicated by odd values, exit(0) must return an odd status.

"If the return type of the main function is a type compatible with int,
a return from the initial call to the main function is equivalent to
calling the exit function with the value
returned by the main function as its argument; ..." (5.1.2.2.3p1).
So the same should also be true of "return 0;" from main().

[toc] | [prev] | [next] | [standalone]

#146048

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 9/5/19 5:31 PM, Keith Thompson wrote:
> ...
>> VMS (VAX is the hardware, which can also run Unix) does the same for the
>> return status of a program -- which is probably part of the reason we
>> have the EXIT_SUCCESS and EXIT_FAILURE macros in <stdlib.h>.  When I
>> worked on VMS, I sometimes ran into C programs that used "return 1;" or
>> "exit(1);" to indicate failure, but that indicates success on VMS.
>> 
>> (But "return 0;" or "exit(0);" is required to return a successful
>> status, even though the OS treats that as a failure code.)
>
> "If the value of status is zero or EXIT_SUCCESS, an
> implementation-defined form of the status _successful termination_ is
> returned." (7.20.4.3p5).
> I don't believe that a status which the OS treats as a failure code
> could qualify as a successful status. On a platform where successful
> statuses are indicated by odd values, exit(0) must return an odd status.
>
> "If the return type of the main function is a type compatible with int,
> a return from the initial call to the main function is equivalent to
> calling the exit function with the value
> returned by the main function as its argument; ..." (5.1.2.2.3p1).
> So the same should also be true of "return 0;" from main().

Yes, I didn't mean to imply otherwise.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#146078

On 9/5/19 3:31 PM, Keith Thompson wrote:
> Bruce S <bruces42@hotmail.com> writes:
>> On 9/5/19 5:04 AM, Thiago Adams wrote:
>>> On Thursday, September 5, 2019 at 5:02:25 AM UTC-3, Mateusz Viste wrote:
>>>> On Wed, 04 Sep 2019 15:20:06 -0700, Keith Thompson wrote:
>>>>> Thiago Adams  writes:
>>>>>> Some libraries uses 0 to say "no error" and others use 1 or true do say
>>>>>> "no error".
>>>>> [...]
>>>>>
>>>>> What libraries use 1 to denote "no error"?
>>>>>
>>>>> In my experience, error codes in C are almost always zero for success,
>>>>> non-zero for failure (with either the value or errno providing more
>>>>> information about the error).  (My experience does have a
>>>>> UNIX/POSIX/Linux bias.)
>>>>
>>>> Your experience missed inet_pton() then. :)
>>>> But yes - it is quite an exception.
>>>
>>> Windows API has several functions returning BOOL where non zero
>>> is success. Zero is error and then GetLastError is used.
>>>
>>> BOOL DeleteFileA(LPCSTR lpFileName);
>>
>> IIRC from my VAX days, their library functions returned an odd value for
>> success, an even one for error.  So 1 would be *one of* the many, many
>> values denoting "no error".  Unfortunately, the libraries we built to
>> work in that environment followed the same approach.  I don't recall
>> ever having code that depended on exactly which "success" code was
>> returned, though there were plenty that depended on specific errors.
> 
> VMS (VAX is the hardware, which can also run Unix) does the same for the
> return status of a program -- which is probably part of the reason we
> have the EXIT_SUCCESS and EXIT_FAILURE macros in <stdlib.h>.  When I
> worked on VMS, I sometimes ran into C programs that used "return 1;" or
> "exit(1);" to indicate failure, but that indicates success on VMS.

You're right; I meant VMS specifically.  For checking for errors (when
we did that at all) we used a couple of macros, something like
SUCCESS(x), and ERROR(x), which simply checked for odd or even.  I can't
recall if it was OS libraries, or application libraries, or both. 
Programmers in our group had adopted that approach throughout our code
as well.  I came from a shop where we used 0 for success and everything
else as error codes, and found the odd/even approach odd and awkward.

> (But "return 0;" or "exit(0);" is required to return a successful
> status, even though the OS treats that as a failure code.)

I actually have no idea what our code did for program exit.  From
some other things I saw, I wouldn't be surprised if it were simply
"return;", or no explicit return at all.  Some practices there were less
than ideal.  For instance, while many malloc() and friends return values
were cast, there were generally no checks for NULL.

[toc] | [prev] | [next] | [standalone]

#146003

On 5/9/19 7:14 am, Thiago Adams wrote:
> In my experience, most of the time I don't need to check
> for specific errors.
> 
> For instance, I rarely need to do this:
> 
> if (error == specific_error) {
>   /*do something*/
> }
> 
> in general I just check for general errors:
> 
> if (error != error_success) {
>   /*do something*/
> }
> 
> Some libraries uses 0 to say "no error" and others use
> 1 or true do say "no error".
> 
> My suggestion is to add at <errno.h>
> 
> typedef int error_t
> and a enum item  std_success
> 
> 
> If you look at existing code, for instance
> 
> int thrd_create( thrd_t *thr, thrd_start_t func, void *arg );
> "thrd_success if the creation of the new thread was successful."
> 
> 
> int bind(SOCKET s, const sockaddr *addr, int namelen);
> "If no error occurs, bind returns zero. Otherwise, it returns SOCKET_ERROR, and a specific error code can be"
> 
> You will see different approaches.
> 
> But I think it should be more universal and library implementers
> could use the same typedef.
> 
> Let's say
> 
> error_t MyLibFunc();
> 
> then I could use
> 
> error_t er = MyLibFunc();
> 
> if (er != std_success)
> {
>    printf("%s", MyLibErrorToString(er));
> }
> 
> and then automatically, the programmer that is using that lib
> knows how do check for errors.
> 
> 
> What do you think?

Errno is possibly the most evil thing to happen in the history of the 
computer industry.

Every error has a context which goes beyond a simple indication of 
failure. The very first errno in Unix is EPERM, permission denied. There 
is no indication of what permission was denied, or what the user can do 
to fix it. The second one is ENOENT, no such file or directory. Exactly 
*which* file or directory (in the path provided) does not exist? 
Perchance you could tell me whether it was expected to be a file, or a 
directory? And so it goes on.

This problem of missing context from error reports was copied by 
Microsoft (who hasn't laughed at a dialog saying "Unknown Error 
0x80000000"?) and the cultural phenomenon went on to become by far the 
single biggest single cause of user frustration in all computing. We've 
even trained our users to expect it, when they should be screaming blue 
murder. We have normalised this insanity.

Every primary error indication should contain or make available every 
detail that isn't implicit from the call. Errno and the culture 
surrounding that says "too hard, don't care, f*ck the users, they can 
work it out by themselves". It embodies a culture of deep disrespect.

> How do you propagate errors? Do you create your own type?

I made (for our company in the late 1980's, and still in use now) a kind 
of exception management environment. It's complicated. It deserves a 
book all by itself, or at least several chapters in one.

In C++, we were using many different early compilers (targeting 50+ 
platforms) so couldn't rely on much, and especially not on exceptions. 
But I defined a type which contained a 32-bit error code called ErrorT 
broken into a module (subsystem) ID and a message number within that 
module (we called these the S/M numbers). The error numbers were 
generated into a C++ header by a compiler for our Error Catalog Source 
language, and that was integrated into the makefile process. So you 
can't allocate a number at random, you can only use one that's been 
properly defined. And here, "properly defined" meant that message text 
was made available in each language, with type-safe argument 
interpolation. It also meant that sufficient documentation was provided 
to generate a PDF error messages manual that had useful content, and for 
translators to know how to translate to a new language. We expected that 
each message would usually be broken into Problem/Reason/Solution, since 
that was usually appropriate.

The definition of an ErrorT included defining the parameters for each 
error. The constructor for each error code requires the parameters, like 
with an exception.

But here's where this diverges from being just a fancy exception system. 
To create an ErrorT to return, it's necessary to provide the parameters 
to a type-safe varargs-style function (I won't go into how we did that 
but it was pretty fast). The error code and the parameter values were 
pushed onto an error tombstone (stack). If the caller doesn't take 
corrective action and unwind this stack (discarding the copied 
parameters), a top-level GUI loop (or atexit function) would fetch all 
appropriate message text, format the messages and spit them out. So you 
got a full cause-and-effect chain report. The message cascade could even 
be serialised over a network to be formatted into a remote user's native 
language.

E.g.

Your project "Some Work" could not be saved. Please save it elsewhere.
-> Failed to write file "a/b/c".
-> Out of space on volume "/mnt/work", free up space and try again.

and sometimes much more complicated error cascades. It really wasn't 
costly at runtime, and the discipline it imposed on developers was 
excellent for them personally as well as for the company and our users.

Clifford Heath.

> Do you use enun or int?
> How do you integrate errors from thirty party libs in our own
> errors?
> 
> 
> Apart of that some range could be reserved for known errors.
> E.g nomen or io errors.
> 
> then errors like
> 
> thrd_nomem
> 
> would not need a specific namespaces.

[toc] | [prev] | [next] | [standalone]

#146008

On Thursday, 5 September 2019 00:30:19 UTC+1, Clifford Heath  wrote:
> 
> Every primary error indication should contain or make available every 
> detail that isn't implicit from the call. Errno and the culture 
> surrounding that says "too hard, don't care, f*ck the users, they can 
> work it out by themselves". It embodies a culture of deep disrespect.
> 
We were allowed to report two errors. "Drive door open" and "disk dirty".
The first error required the user to close the drive. The second error
required him to remove the CD, shutting down his game and losing his 
place, polish it, then return it to the drive and restart. That fixed
that problem.

[toc] | [prev] | [next] | [standalone]

#146013

On Wednesday, September 4, 2019 at 8:30:19 PM UTC-3, Clifford Heath wrote:
...
> Every error has a context which goes beyond a simple indication of 
> failure. The very first errno in Unix is EPERM, permission denied. There 
> is no indication of what permission was denied, or what the user can do 
> to fix it. The second one is ENOENT, no such file or directory. Exactly 
> *which* file or directory (in the path provided) does not exist? 
> Perchance you could tell me whether it was expected to be a file, or a 
> directory? And so it goes on.

Generally I convert the error to bool plus a string.

bool MyProgram(Error* error) {
   /*error has a string inside*/
   Error_Set(error, "Error opening...%s", error_string(errorNo));
}

The problem with my current approach is:
I always erase the error code making it equal to false. This problem
is not so big because I generally don't need to check for an specific
error.

The way I an considering to do is change the bool for error_t.

So instead of erasing the error code I just propagate it.

The same error number can be from different libs but it is
my choice how to deal with it.

I can erase it, making it generic, or I can convert for a new
error set inside my program, or I can add a extra number etc.

Sample:
error_t MyProgram(Error* error) {

   error_t  e = ...

   Error_Set(error, e, MyLib, "Error opening...%d", errorNo);  
}

What is interesting to notice is that the problem of 
'error code sets' is not only from lib to lib but the
same lib in different OS.

Let's say I have a function DeleteFile.
Error for delete file can be different from linux and windows for 
instance.
This makes difficult to check for specific error without creating
a conversion.

For istance:
LINUX_ERROR_CODE_ACCESS_DENIED,  /*some number*/
WINDOWS_ERROR_CODE_ACCESS_DENIED /*some number*/

I need to convert to:
MYLIB_ERROR_CODE_ACCESS_DENIED /*some number*/

then:

MyLibErrorCode e = DeleteFile("file");

if (e == MYLIB_ERROR_CODE_ACCESS_DENIED) { ... }

It works, but this conversion must be created.
The other alternative is to choose one to mimic in the
other platform.
(I have this problem with sockets)

[toc] | [prev] | [next] | [standalone]

#146014

On Thursday, September 5, 2019 at 8:57:31 AM UTC-3, Thiago Adams wrote:
...
> What is interesting to notice is that the problem of 
> 'error code sets' is not only from lib to lib but the
> same lib in different OS.

The other approach I have seen in Windows for avoiding error
conversion is to use the same error type used in windows.
For instance, windows has HRESULT, then instead creating
MyLibErrorCode or MyProgramErrorCode windows programmers 
can choose to use HRESULT in their own code.
Sometimes function that have zero Windows dependencies uses
HRESULT.

Does linux have similar error type?

(
Adding more sample of libs that return 1 for success:

openssl. e.g
BIO_up_ref() and BIO_free() return 1 for success and 0 for failure.


)

[toc] | [prev] | [next] | [standalone]

#146015

On Thursday, 5 September 2019 13:16:46 UTC+1, Thiago Adams  wrote:
> On Thursday, September 5, 2019 at 8:57:31 AM UTC-3, Thiago Adams wrote:
> ...
> > What is interesting to notice is that the problem of 
> > 'error code sets' is not only from lib to lib but the
> > same lib in different OS.
> 
> The other approach I have seen in Windows for avoiding error
> conversion is to use the same error type used in windows.
> For instance, windows has HRESULT, then instead creating
> MyLibErrorCode or MyProgramErrorCode windows programmers 
> can choose to use HRESULT in their own code.
> Sometimes function that have zero Windows dependencies uses
> HRESULT.
> 
Then it has a Windows dependency. 

[toc] | [prev] | [next] | [standalone]

#146017

On Thursday, September 5, 2019 at 9:35:35 AM UTC-3, Malcolm McLean wrote:
> On Thursday, 5 September 2019 13:16:46 UTC+1, Thiago Adams  wrote:
> > On Thursday, September 5, 2019 at 8:57:31 AM UTC-3, Thiago Adams wrote:
> > ...
> > > What is interesting to notice is that the problem of 
> > > 'error code sets' is not only from lib to lib but the
> > > same lib in different OS.
> > 
> > The other approach I have seen in Windows for avoiding error
> > conversion is to use the same error type used in windows.
> > For instance, windows has HRESULT, then instead creating
> > MyLibErrorCode or MyProgramErrorCode windows programmers 
> > can choose to use HRESULT in their own code.
> > Sometimes function that have zero Windows dependencies uses
> > HRESULT.
> > 
> Then it has a Windows dependency.
Yes. I don't like this practice. 

[toc] | [prev] | [next] | [standalone]

#146020

On Thursday, 5 September 2019 14:08:23 UTC+1, Thiago Adams  wrote:
> On Thursday, September 5, 2019 at 9:35:35 AM UTC-3, Malcolm McLean wrote:
> > On Thursday, 5 September 2019 13:16:46 UTC+1, Thiago Adams  wrote:
> > > On Thursday, September 5, 2019 at 8:57:31 AM UTC-3, Thiago Adams wrote:
> > > ...
> > > > What is interesting to notice is that the problem of 
> > > > 'error code sets' is not only from lib to lib but the
> > > > same lib in different OS.
> > > 
> > > The other approach I have seen in Windows for avoiding error
> > > conversion is to use the same error type used in windows.
> > > For instance, windows has HRESULT, then instead creating
> > > MyLibErrorCode or MyProgramErrorCode windows programmers 
> > > can choose to use HRESULT in their own code.
> > > Sometimes function that have zero Windows dependencies uses
> > > HRESULT.
> > > 
> > Then it has a Windows dependency.
> Yes. I don't like this practice.
>
An integrated error system will take some designing. For performance
reasons, an error_t will probably have to be an int. Whilst that gives
enough codes for each library to define as many error types as it
needs, it doesn't give enough space to avoid error code collisions.

Then errors need tagging with error-specific data, plus data common
to all errors such as the line on which it occurred and the call
stack trace to show how it got there. If you fail to open a file,
the user wants to know what name was passed to fopen(), if a memory
allocation request fails, the debugging programmer wants to know the
size of the allocation request, and so on. 

[toc] | [prev] | [next] | [standalone]

#146023

On Thursday, September 5, 2019 at 10:17:04 AM UTC-3, Malcolm McLean wrote:
> On Thursday, 5 September 2019 14:08:23 UTC+1, Thiago Adams  wrote:
> > On Thursday, September 5, 2019 at 9:35:35 AM UTC-3, Malcolm McLean wrote:
> > > On Thursday, 5 September 2019 13:16:46 UTC+1, Thiago Adams  wrote:
> > > > On Thursday, September 5, 2019 at 8:57:31 AM UTC-3, Thiago Adams wrote:
> > > > ...
> > > > > What is interesting to notice is that the problem of 
> > > > > 'error code sets' is not only from lib to lib but the
> > > > > same lib in different OS.
> > > > 
> > > > The other approach I have seen in Windows for avoiding error
> > > > conversion is to use the same error type used in windows.
> > > > For instance, windows has HRESULT, then instead creating
> > > > MyLibErrorCode or MyProgramErrorCode windows programmers 
> > > > can choose to use HRESULT in their own code.
> > > > Sometimes function that have zero Windows dependencies uses
> > > > HRESULT.
> > > > 
> > > Then it has a Windows dependency.
> > Yes. I don't like this practice.
> >
> An integrated error system will take some designing. For performance
> reasons, an error_t will probably have to be an int. Whilst that gives
> enough codes for each library to define as many error types as it
> needs, it doesn't give enough space to avoid error code collisions.
> 
> Then errors need tagging with error-specific data, plus data common
> to all errors such as the line on which it occurred and the call
> stack trace to show how it got there. If you fail to open a file,
> the user wants to know what name was passed to fopen(), if a memory
> allocation request fails, the debugging programmer wants to know the
> size of the allocation request, and so on.

fopen is a good sample because it is inside the standard and
it requires SO calls.
The standard only says it returns null? Where is the error?

the https://en.cppreference.com/w/c/io/fopen
says "POSIX requires that errno be set in this case."

Searching at standard I found:

"
K.3.6 General utilities <stdlib.h>
1 The header <stdlib.h> defines three types.
2 The types are
errno_t
which is type int; and
"
and errno_t is already used!


"errno_t fopen_s(FILE * restrict * restrict streamptr,
const char * restrict filename,
const char * restrict mode);"

"The fopen_s function returns zero if it opened the file. If it did not open the file or if
there was a runtime-constraint violation, fopen_s returns a nonzero value."


So basically, my suggestion already exists but there is no constant
to say "no-error" that is apparently zero.

But if I look  at some function that returns errno_t I may 
conclude that it follows the practice where 0 is no error.
This is different from looking at some function that returns int
and try to figure out the meaning.


I think the C standard is incoherent with these return types.

Look at:

"int thrd_create(thrd_t *thr, thrd_start_t func,
void *arg);"

"The thrd_create function returns thrd_success on success, or thrd_nomem if
no memory could be allocated for the thread requested, or thrd_error if the request
could not be honored."

Why not use errno_t  in both!?
and make  thrd_success, thrd_nomem , thrd_error values 
associated with errno_t ? (changing their names)

[toc] | [prev] | [next] | [standalone]

#146026

On Thursday, September 5, 2019 at 10:37:47 AM UTC-3, Thiago Adams wrote:
...
> Searching at standard I found:
> 
> "
> K.3.6 General utilities <stdlib.h>
> 1 The header <stdlib.h> defines three types.
> 2 The types are
> errno_t
> which is type int; and
> "
> and errno_t is already used!

errno_t was added in C11.

There is also a strerror_s, strerrorlen_s, strnlen_s

I compiled this code using visual studio 2019 (latest version)

  FILE* fp = fopen("blablab", "r");
  if (fp == NULL)
  {
    errno_t e1 = errno;
    printf("File opening error: %s\n", strerror(e1));
    char errmsg[200];
    strerror_s(errmsg, 200, e1);
    printf("File opening error: %s\n", errmsg);
  }

The number returned is 2 (ENOENT) and the message
is "No such file or directory".

I found this ENOENT declared inside #include <errno.h>
but it is not part of C standard. 

[toc] | [prev] | [next] | [standalone]

#146037

Thiago Adams <thiago.adams@gmail.com> writes:

> On Thursday, September 5, 2019 at 10:37:47 AM UTC-3, Thiago Adams wrote:
> ...
>> Searching at standard I found:
>> 
>> "
>> K.3.6 General utilities <stdlib.h>
>> 1 The header <stdlib.h> defines three types.
>> 2 The types are
>> errno_t
>> which is type int; and
>> "
>> and errno_t is already used!
>
> errno_t was added in C11.
>
> There is also a strerror_s, strerrorlen_s, strnlen_s

All of these are optional.  They are part of the political "annex K".
You can turn them off by having

  #define __STDC_WANT_LIB_EXT1__ 0

before including any header that might define them.

> I compiled this code using visual studio 2019 (latest version)
>
>   FILE* fp = fopen("blablab", "r");
>   if (fp == NULL)
>   {
>     errno_t e1 = errno;
>     printf("File opening error: %s\n", strerror(e1));
>     char errmsg[200];
>     strerror_s(errmsg, 200, e1);
>     printf("File opening error: %s\n", errmsg);
>   }
>
> The number returned is 2 (ENOENT) and the message
> is "No such file or directory".
>
> I found this ENOENT declared inside #include <errno.h>
> but it is not part of C standard.

Yes.  fopen does not "document the use of errno" which means it can do
pretty much anything it likes with it (except set it to zero).
Traditionally, the IO functions make use of this permission, but they
don't have to.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#146040

On Thursday, September 5, 2019 at 4:51:21 PM UTC-3, Ben Bacarisse wrote:
..
> Yes.  fopen does not "document the use of errno" which means it can do
> pretty much anything it likes with it (except set it to zero).
> Traditionally, the IO functions make use of this permission, but they
> don't have to.
> 
We might be entering in a new era where POSIX came back to windows.
I think this is the ideal world where SO functions should no be 
described or wrapped (like threads) inside the C standard.
Instead a common interface like POSIX could describe these functions.

https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem

WSL has a new version inside windows. 
https://docs.microsoft.com/pt-br/windows/wsl/wsl2-index

I ask myself if the only interface we will need is linux in the 
future.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web