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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#146047

Thiago Adams <thiago.adams@gmail.com> writes:
> 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.

I think you mean POSIX, not Linux.

Linux, stricty speaking, is just the kernel, and there are plenty of
UNIX-like systems (such as the various BSD-based systems, including
MacOS) that don't use the Linux kernel.  (The word "Linux" is also
commonly used to refer to operating systems that use the Linux kernel
-- and *please* let's not argue about whether that usage is correct.)

-- 
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]

#146039

Malcolm McLean <malcolm.arthur.mclean@gmail.com> 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.

I've always thought that the linker should have the ability to resolve
symbolic enumeration values of a shared enumeration type (i.e. defined in
fragments) to globally unique values. For statically compiled languages like
Rust it's even easier. But as far as I know, no language provides such a
feature. In dynamic languages it's easy--you just request a value or range
of values to bind to variable names at runtime, which is exactly what the
linker would be doing, except the linker would have to substitute the
resolved values in the code itself.

> 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. 

A shared error_t gets you 80% of the way to a practical composability
utopia. Yes, context is important, but *usually* the caller has the context
directly (e.g. they passed the file path) or indirectly (e.g. they have a
handle to the resource from which they can query the file path used). Issues
like memory allocation and ownership of *arbitrary* context are effectively
intractable, particularly in a language like C, so asking for such a
capability is as useful as asking for World Peace.

FWIW, I *do* use a shared error_t values in most of my C projects. My
standard header preamble for every major component of a project usually
begins something like:

  #define FOO_EBASE -(('f' << 24) | ('o' << 16) | ('o' << 8) | 64)
  #define FOO_ISERRNO(e) ((e) >= FOO_EBASE && (e) < FOO_ELAST)

  #define foo_error_t int /* for API documentation only */

  enum foo_errno {
    FOO_EBAR = FOO_EBASE,
    FOO_EBAZ,
    // ...
    FOO_ELAST,
  };

  const char *foo_strerror(foo_error_t);

where foo_strerror will forward unknown values to any component it uses and
for which it may have returned an error value, otherwise as a fail-safe it
proxies to strerror(3), which will always produce a valid result even for
unknown values. (Invariably system errors are a subset of the errors
returned as foo_error_t, so excepting bugs in the application strerror(3) is
really only invoked for system errno values.)

I might sometimes have something like:

  const char *foo_strerror(foo_error_t, struct foo *ctx);

But IME the relevant context is usually already available to the caller. And
if it's not that's a clue that my code and APIs need to be restructured so
the caller does have access to the relevant context, rather than boiling the
oceans chasing the perfect error reporting API.

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

#146042

On 5/9/19 11:16 pm, 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.

It's actually not that hard. You need to wrap many Windows system calls 
(like filesystem APIs) in order to re-instate the "missing" error 
parameters, and that covers most of the error codes you want to 
integrate anyway. As a result, my ErrorT system incorporates HRESULT 
with no conversion. The Set/Message numbers follow exactly the pattern 
used on Windows; the top bit is reserved to say "this is an error", the 
next two are reserved because some Windows subsystems use them, and the 
next 13 bits are the module number - which Windows also does, but we 
avoid the module/subsystem numbers we know Windows is using (though 
there is a possibility of conflict as there's no central registry AFAIK).

> 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.

No end user wants to know the source code line. Stack unwinding can be 
very expensive and should not be done for an error that will be 
recovered, but it cannot be done afterward.

*Tracing* is different from error management. I built an equivalent 
system for that too (around 1998), a long time before dtrace and 
considerably more sophisticated in some ways, but I didn't want to 
change the subject.

> 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]

#146044

On 5/9/19 9:57 pm, Thiago Adams wrote:
> 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);
> }

It is important not to format the message immediately.

In my system the user gets the ErrorT from a call to Error(), to which a 
macro is used which provides the first two parameters. One is a string 
that contains printf-style insertions that are scanned to extract the 
required argument types. Those arguments are then cached for use in a 
*future* formatting operation. As a simplified example (I wouldn't use 
this text or directly use fopen() like this):

{
	FILE* fp = fopen(filename, "r");
	if (!fp)
		return Error(ERR_FILE_NOT_FOUND, ArgList << filename);
}

ERR_FILE_NOT_FOUND is *two* parameters, the error number and the default 
message text, e.g. "File %1$s not found". The "1$" is a positional 
indicator which is optional in this context, but can be used in 
translated text to re-order parameters. Basically Error() scans the 
default text to find that a string is expected, and the ArgList is 
checked to ensure that it contains the required parameter (and type!).

The error stack thus has ErrorT, default text, and the parameters all 
available, which can be formatted, even after being forwarded over a 
network to a different locale/language environment.

ArgList provides a type-safe varargs system. A mis-translated error 
message cannot crash the error system.

Clifford Heath.

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

#146061

On Thursday, September 5, 2019 at 6:36:00 PM UTC-3, Clifford Heath wrote:
> On 5/9/19 9:57 pm, Thiago Adams wrote:
> > 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);
> > }
> 
> It is important not to format the message immediately.

Generally I use this string that comes from the operation system
to show details. The final message is something like:

"We cannot do what you want using X Y. Details 'SO error here'"

The caller also have the context and the opportunity of reformat.

error_t MyProgram(Error* error) {
    error_t  e = ...
    Error_Set(error, "Error opening...%d", errorNo);
}

error_t Caller(Error* error) {
  Error innererror;
  error_t e = MyProgram(&innererror);
  if (e != 0)
  {
    Error_Set(error, "Reformat error %s", innererror.text); 
  }
  return e;
}

My Error struct has basically a string.

Let's say I want to keep line and column from a parser.
Then I can  create a new Error with the 'base' error inside.

struct ParserError
{
  struct Error error;  //<- basic error
  int line, col;       //<- extra information
};

error_t Parse(struct ParserError* parsererror) {

   //here Open can use the basic error
   error_t e = Open(..., &parsererror->error);
   if (e != 0) {
      ...
      //and here Read can use the extended error
      //and set the line and col of error
      Read(parsererror);
   }
}


What is interesting is that the error type is part of the function 
signature.

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

#146024

Clifford Heath <no.spam@please.net> writes:
>On 5/9/19 7:14 am, Thiago Adams wrote:
>
>> 
>> 
>> What do you think?
>
>Errno is possibly the most evil thing to happen in the history of the 
>computer industry.

No, tell us what you _really_ think.

>
>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. 

Sure there is.  In the documentation for the system call.


>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.

You realize this was all designed in the mid 1970's to run on
a machine with less than 64k bytes of ram?

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

#146041

On 5/9/19 11:59 pm, Scott Lurndal wrote:
> Clifford Heath <no.spam@please.net> writes:
>> On 5/9/19 7:14 am, Thiago Adams wrote:
>>> What do you think?
>>
>> Errno is possibly the most evil thing to happen in the history of the
>> computer industry.
> 
> No, tell us what you _really_ think.
>> 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.
> 
> Sure there is.  In the documentation for the system call.

The documentation lists dozens of things that might be the cause, and 
cannot name the actual files, directories, acls, etc, that are involved.

>> 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.
> 
> You realize this was all designed in the mid 1970's to run on
> a machine with less than 64k bytes of ram?

Yes. I was there, coding them. Been a Unix aficionado since 1979, and 
coding since 1974. Still have millions of lines of my code running 
millions of machines worldwide.

The machines have moved on. Perhaps it's time we did also?

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

#146009

On Wed, 2019-09-04, Thiago Adams wrote:
>
...
> But I think it should be more universal and library implementers
> could use the same typedef.
...
> What do you think?

https://xkcd.com/927/

It's too late to change APIs which have existed for 20--40 years.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#146012

On Thursday, September 5, 2019 at 7:01:56 AM UTC-3, Jorgen Grahn wrote:
> On Wed, 2019-09-04, Thiago Adams wrote:
> >
> ...
> > But I think it should be more universal and library implementers
> > could use the same typedef.
> ...
> > What do you think?
> 
> https://xkcd.com/927/
> 
> It's too late to change APIs which have existed for 20--40 years.
> 

I don't think this is the case.
Remember, before C99 each programmer was using its own definition
for bool.

Today, each programmer is using its own definition for what
is error.

The problem we can see is that errors have they own namespace
and each library has its own set of errors. Having a type for each
library makes this clear but different sets needs to be converted.

For instance:


MyProgramError MyProgramFunc()
{
  MyProgramError e = MYPROGRAM_ERROR;

  MyLibError e1 = MyLibFunc();

  if (e1 == MYLIB_SUCEEDED) {
    
    YourLibError e2 = YourLibFunc();

    if (e2 != YOURLIB_SUCCEEDED)  {
       e = ConvertYourLibErrorToMyProgramError(e2);
    }

  }
  else {
     e = ConvertMyLibErrorToMyProgramError(e1);
  }

  return e;
}

Considering that most of the time we don't care about the specific
error we could have just.


error_t MyProgramFunc()
{
  error_t e = MyLibFunc();

  if (e1 == std_success) {
    e = YourLibFunc();
  }

  return e;
}

The problem here is how to known if the number used
is from MyLib or YourLib?

I believe this can be solved with different approaches.

Possibilities:

1 - Just build an string using each lib error_to_string and erase
    the error making it equals 1 for instance.
    
    error_t MyProgramFunc(char errorstr[MAX_ERROR]);

2 - Add a second number (LibEnum) that is the lib number.
    error_t MyProgramFunc(LibEnum* libnumber);

    So error reported is referring to the libnumber that is a number
    set inside MyProgram to avoid conflict.

    A function:

    error_to_string(error_t error, LibEnum lib){
      if (lib == MyLib) { ... }
      else if (lib == YourLib) { ... }
    }


The standard could add some errors that are universal,
for instance std_error and std_nomem.

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

#146045

Thiago Adams <thiago.adams@gmail.com> writes:
> On Thursday, September 5, 2019 at 7:01:56 AM UTC-3, Jorgen Grahn wrote:
>> On Wed, 2019-09-04, Thiago Adams wrote:
>> >
>> ...
>> > But I think it should be more universal and library implementers
>> > could use the same typedef.
>> ...
>> > What do you think?
>> 
>> https://xkcd.com/927/
>> 
>> It's too late to change APIs which have existed for 20--40 years.
>> 
>
> I don't think this is the case.
> Remember, before C99 each programmer was using its own definition
> for bool.
>
> Today, each programmer is using its own definition for what
> is error.

Before C99, most C programs didn't bother defining a Boolean type.
They typically used int, with 0 for false and 1 for true.  (A lot
of C code still does that.)

The definition of what is an error is generally imposed by the OS
(POSIX, Windows, etc.).

Given that most POSIX functions return 0 on success, and apparently
many Windows functions return true (1) on success, I don't
think it's feasible to define a consistent std_success constant.
A single program could use functions from different libraries with
inconsistent error reporting schemes.

[...]

-- 
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]

#146063

On Thursday, September 5, 2019 at 6:43:48 PM UTC-3, Keith Thompson wrote:
> Thiago Adams  writes:
> > On Thursday, September 5, 2019 at 7:01:56 AM UTC-3, Jorgen Grahn wrote:
> >> On Wed, 2019-09-04, Thiago Adams wrote:
> >> >
> >> ...
> >> > But I think it should be more universal and library implementers
> >> > could use the same typedef.
> >> ...
> >> > What do you think?
> >> 
> >> https://xkcd.com/927/
> >> 
> >> It's too late to change APIs which have existed for 20--40 years.
> >> 
> >
> > I don't think this is the case.
> > Remember, before C99 each programmer was using its own definition
> > for bool.
> >
> > Today, each programmer is using its own definition for what
> > is error.
> 
> Before C99, most C programs didn't bother defining a Boolean type.
> They typically used int, with 0 for false and 1 for true.  (A lot
> of C code still does that.)
> 

I am happy to have found errno_t in the C11 standard.
I will not change bool for errno_t in my current programs (because 
this creates a inverse logic) but I intend to use errno_t in new 
programs.
I am starting to think that is not so bad not having a constant
for success.(that is zero by definition of errno_t)
POSIX also don't have a 'no error' constant. Maybe if it had
probably this would be the success constant for errno_t .

Having the type errno_t  automatically shows the function contract.

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

#146070

Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> I am happy to have found errno_t in the C11 standard.
> I will not change bool for errno_t in my current programs (because 
> this creates a inverse logic) but I intend to use errno_t in new 
> programs.

Then your new programs won't compile with implementations that don't
support the optional Annex K (unless you define errno_t yourself).

> I am starting to think that is not so bad not having a constant
> for success.(that is zero by definition of errno_t)
> POSIX also don't have a 'no error' constant. Maybe if it had
> probably this would be the success constant for errno_t .
>
> Having the type errno_t  automatically shows the function contract.

I'll note that the intended use of errno_t is for the value of errno.
Most conventions don't have functions returning error codes.  Many POSIX
functions for example, return 0 for success and 1 for failure, with
errno set to indicate which error occurred.  (Linux kernel functions
that implement system calls typically return a non-negative value for
success or a negated E* value for failure, but that's mapped to setting
errno when a user-space program calls them.)

I agree it would be nice to have a convention that's (a) more consistent
and (b) returns both the result and the status from the function rather
than using the ugly errno mechanism.  But there's only so much you can
do given the existing standards and libraries.

-- 
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]

#146075

Keith Thompson <kst-u@mib.org> writes:
>Thiago Adams <thiago.adams@gmail.com> writes:
>[...]
>> I am happy to have found errno_t in the C11 standard.
>> I will not change bool for errno_t in my current programs (because 
>> this creates a inverse logic) but I intend to use errno_t in new 
>> programs.
>
>Then your new programs won't compile with implementations that don't
>support the optional Annex K (unless you define errno_t yourself).
>
>> I am starting to think that is not so bad not having a constant
>> for success.(that is zero by definition of errno_t)
>> POSIX also don't have a 'no error' constant. Maybe if it had
>> probably this would be the success constant for errno_t .
>>
>> Having the type errno_t  automatically shows the function contract.
>
>I'll note that the intended use of errno_t is for the value of errno.
>Most conventions don't have functions returning error codes.  Many POSIX
>functions for example, return 0 for success and 1 for failure, with
>errno set to indicate which error occurred.  (Linux kernel functions
>that implement system calls typically return a non-negative value for
>success or a negated E* value for failure, but that's mapped to setting
>errno when a user-space program calls them.)
>
>I agree it would be nice to have a convention that's (a) more consistent
>and (b) returns both the result and the status from the function rather
>than using the ugly errno mechanism.  But there's only so much you can
>do given the existing standards and libraries.

I will point out that the POSIX interfaces added with 1003.4 and
beyond return 0 for success and an value (e.g. EIO, EINTR, EINVAL etc) directly
avoiding the global (or per-thread) 'errno'.   See pthread* for example.

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

#146076

On Friday, September 6, 2019 at 3:18:44 PM UTC-3, Keith Thompson wrote:
> Thiago Adams writes:
> [...]
> > I am happy to have found errno_t in the C11 standard.
> > I will not change bool for errno_t in my current programs (because 
> > this creates a inverse logic) but I intend to use errno_t in new 
> > programs.
> 
> Then your new programs won't compile with implementations that don't
> support the optional Annex K (unless you define errno_t yourself).

When I compiled using VC++ 2019 I didn't have to add any defines
like #define __STDC_WANT_LIB_EXT1__ 1 to use errno_t or other.
I guess it is not following the standard in this case.

I tried online some compilers and they are not recognizing
errno_t even when I  use
#define __STDC_WANT_LIB_EXT1__  1

So, unfortunately, I will need to add an extra include checking
the existence  of errno_t that was something I was expecting for 
free. :-/

We can find information here:

Subject: Updated Field Experience With Annex K 
— Bounds Checking Interfaces

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm

Available Implementations
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm#impementations

So, I guess I returned to my starting point.
My proposal is to add errno_t without the need of Annex K.

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

#146077

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

> On Friday, September 6, 2019 at 3:18:44 PM UTC-3, Keith Thompson wrote:
>> Thiago Adams writes:
>> [...]
>> > I am happy to have found errno_t in the C11 standard.
>> > I will not change bool for errno_t in my current programs (because 
>> > this creates a inverse logic) but I intend to use errno_t in new 
>> > programs.
>> 
>> Then your new programs won't compile with implementations that don't
>> support the optional Annex K (unless you define errno_t yourself).
>
> When I compiled using VC++ 2019 I didn't have to add any defines
> like #define __STDC_WANT_LIB_EXT1__ 1 to use errno_t or other.
> I guess it is not following the standard in this case.

No, that's permitted.  A C11 implementation should not define these
types etc. when __STDC_WANT_LIB_EXT1__ is defined to be 0 (at the
appropriate time) and it should when __STDC_WANT_LIB_EXT1__ is defined
to be 1, but the default (what happens when there is no explicit define
for __STDC_WANT_LIB_EXT1__) is left up to the implementation.

> I tried online some compilers and they are not recognizing
> errno_t even when I  use
> #define __STDC_WANT_LIB_EXT1__  1

It would be helpful to see where that define is in your test case, along
with the compiler's name and the options you used.

-- 
Ben.

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

#146080

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> On Friday, September 6, 2019 at 3:18:44 PM UTC-3, Keith Thompson wrote:
>>> Thiago Adams writes:
>>> [...]
>>> > I am happy to have found errno_t in the C11 standard.
>>> > I will not change bool for errno_t in my current programs (because 
>>> > this creates a inverse logic) but I intend to use errno_t in new 
>>> > programs.
>>> 
>>> Then your new programs won't compile with implementations that don't
>>> support the optional Annex K (unless you define errno_t yourself).
>>
>> When I compiled using VC++ 2019 I didn't have to add any defines
>> like #define __STDC_WANT_LIB_EXT1__ 1 to use errno_t or other.
>> I guess it is not following the standard in this case.
>
> No, that's permitted.  A C11 implementation should not define these
> types etc. when __STDC_WANT_LIB_EXT1__ is defined to be 0 (at the
> appropriate time) and it should when __STDC_WANT_LIB_EXT1__ is defined
> to be 1, but the default (what happens when there is no explicit define
> for __STDC_WANT_LIB_EXT1__) is left up to the implementation.

Right.  There are three ways for an implementation to conform to C11
with respect to Annex K:

1. Don't support it at all.  The macro __STDC_LIB_EXT1__ is not
   predefined.  Defining or undefining __STDC_WANT_LIB_EXT1__
   (probably) has no effect.

2. Support it, but disable it by default.  __STDC_LIB_EXT1__ is
   predefined as 201112L.  A program that uses Annex K features
   must define __STDC_WANT_LIB_EXT1__ as 1.

3. Support it and enable it by default.  __STDC_LIB_EXT1__ is
   predefined as 201112L.  A program that uses Annex K features
   may define __STDC_WANT_LIB_EXT1__ as 1.

A program may also `#define __STDC_WANT_LIB_EXT1__ 0` to disable Annex K
features (for example if it uses identifiers that are optionally defined
by Annex K).

Note that the value "201112L" doesn't appear correctly either in N1570
or in the published C11 standard.  Technical Corregendum 1 updated it,
and also gave the correct value for __STDC_VERSION__.

>> I tried online some compilers and they are not recognizing
>> errno_t even when I  use
>> #define __STDC_WANT_LIB_EXT1__  1
>
> It would be helpful to see where that define is in your test case, along
> with the compiler's name and the options you used.

If you're using gcc or clang, that's expected; neither supports Annex K.
(More precisely, the implementations I use, consisting of gcc or clang
with glibc, do not support it.  I don't know whether gcc with a
different library implementation might support Annex K.)

-- 
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]

#146081

On Friday, September 6, 2019 at 5:20:33 PM UTC-3, Keith Thompson wrote:
> Ben Bacarisse writes:
> > Thiago Adams  writes:
> >> On Friday, September 6, 2019 at 3:18:44 PM UTC-3, Keith Thompson wrote:
> >>> Thiago Adams writes:
> >>> [...]
> >>> > I am happy to have found errno_t in the C11 standard.
> >>> > I will not change bool for errno_t in my current programs (because 
> >>> > this creates a inverse logic) but I intend to use errno_t in new 
> >>> > programs.
> >>> 
> >>> Then your new programs won't compile with implementations that don't
> >>> support the optional Annex K (unless you define errno_t yourself).
> >>
> >> When I compiled using VC++ 2019 I didn't have to add any defines
> >> like #define __STDC_WANT_LIB_EXT1__ 1 to use errno_t or other.
> >> I guess it is not following the standard in this case.
> >
> > No, that's permitted.  A C11 implementation should not define these
> > types etc. when __STDC_WANT_LIB_EXT1__ is defined to be 0 (at the
> > appropriate time) and it should when __STDC_WANT_LIB_EXT1__ is defined
> > to be 1, but the default (what happens when there is no explicit define
> > for __STDC_WANT_LIB_EXT1__) is left up to the implementation.
> 
> Right.  There are three ways for an implementation to conform to C11
> with respect to Annex K:
> 
> 1. Don't support it at all.  The macro __STDC_LIB_EXT1__ is not
>    predefined.  Defining or undefining __STDC_WANT_LIB_EXT1__
>    (probably) has no effect.
> 
> 2. Support it, but disable it by default.  __STDC_LIB_EXT1__ is
>    predefined as 201112L.  A program that uses Annex K features
>    must define __STDC_WANT_LIB_EXT1__ as 1.
> 
> 3. Support it and enable it by default.  __STDC_LIB_EXT1__ is
>    predefined as 201112L.  A program that uses Annex K features
>    may define __STDC_WANT_LIB_EXT1__ as 1.
> 

Visual C++ is not defining __STDC_LIB_EXT1__.
In case I need to create my own header I will have to check by
compiler.

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

#146083

Thiago Adams <thiago.adams@gmail.com> writes:
> On Friday, September 6, 2019 at 5:20:33 PM UTC-3, Keith Thompson wrote:
[...]
>> Right.  There are three ways for an implementation to conform to C11
>> with respect to Annex K:
>> 
[details snipped]
>
> Visual C++ is not defining __STDC_LIB_EXT1__.
> In case I need to create my own header I will have to check by
> compiler.

If you mean Visual C++ used as a C++ compiler, I wouldn't expect it to;
C++ hasn't copied that feature from C.  If you mean Visual C++ used as a
C compiler, I don't believe it supports C11 (or even all of C99).

If you want to define your own error type, I suggest *not* calling it
"errno_t" as C11 Annex K does.  Support for Annex K is not widespread,
and it's been proposed for removal in the next edition.

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm#adi>

I like the idea of a consistent error reporting convention for library
functions, but existing and widely used libraries are *not* consistent,
and that's not going to change any time soon.  What is the intended
scope of your proposal?

-- 
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]

#146084

On Friday, September 6, 2019 at 6:25:27 PM UTC-3, Keith Thompson wrote:
> Thiago Adams  writes:
> > On Friday, September 6, 2019 at 5:20:33 PM UTC-3, Keith Thompson wrote:
> [...]
> >> Right.  There are three ways for an implementation to conform to C11
> >> with respect to Annex K:
> >> 
> [details snipped]
> >
> > Visual C++ is not defining __STDC_LIB_EXT1__.
> > In case I need to create my own header I will have to check by
> > compiler.
> 
> If you mean Visual C++ used as a C++ compiler, I wouldn't expect it to;
> C++ hasn't copied that feature from C.  If you mean Visual C++ used as a
> C compiler, I don't believe it supports C11 (or even all of C99).

By default, if the source is .c VC++ compiles as C. It has some C99 and some
C11 features not complete.


> If you want to define your own error type, I suggest *not* calling it
> "errno_t" as C11 Annex K does.  Support for Annex K is not widespread,
> and it's been proposed for removal in the next edition.
> 
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm#adi>

I think they should do a fix. In the worst case just ignore the 
extra arguments and leave it for static analysis.

> I like the idea of a consistent error reporting convention for library
> functions, but existing and widely used libraries are *not* consistent,
> and that's not going to change any time soon.  What is the intended
> scope of your proposal?
Sorry, I didn't understand you question.

The objective of having a error_t is very similar of having a bool.
We have a common contract in the standard and other libs can use
the same contract as well.
When someone creates a multiplatform code, this type can be used.
Doesn't matter if the SO is different, but interface is adapting the 
contract.
If I create my own code it doesn't help too much because the contract
is by lib basis instead of universal.

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

#146085

Thiago Adams <thiago.adams@gmail.com> writes:
> On Friday, September 6, 2019 at 6:25:27 PM UTC-3, Keith Thompson wrote:
[...]
>> If you want to define your own error type, I suggest *not* calling it
>> "errno_t" as C11 Annex K does.  Support for Annex K is not widespread,
>> and it's been proposed for removal in the next edition.
>> 
>> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm#adi>
>
> I think they should do a fix. In the worst case just ignore the 
> extra arguments and leave it for static analysis.

I don't think that will happen.

>> I like the idea of a consistent error reporting convention for library
>> functions, but existing and widely used libraries are *not* consistent,
>> and that's not going to change any time soon.  What is the intended
>> scope of your proposal?
> Sorry, I didn't understand you question.

For example, are you pushing for POSIX and other standards/libraries to
be updated to adopt your proposal?  Or just newly designed libraries?
Or just your own?

> The objective of having a error_t is very similar of having a bool.
> We have a common contract in the standard and other libs can use
> the same contract as well.
> When someone creates a multiplatform code, this type can be used.
> Doesn't matter if the SO is different, but interface is adapting the 
> contract.
> If I create my own code it doesn't help too much because the contract
> is by lib basis instead of universal.

-- 
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]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web