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

Groups > comp.lang.c++ > #68299 > unrolled thread

standard error messages in a std::string or in a const char *

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

Contents

  standard error messages in a std::string or in a const char * Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-11 00:35 +0200
    Re: standard error messages in a std::string or in a const char * Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-11 00:37 +0200
      Re: standard error messages in a std::string or in a const char * Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-11 08:28 +0000
        Re: standard error messages in a std::string or in a const char * Juha Nieminen <nospam@thanks.invalid> - 2019-09-11 08:58 +0000
          Re: standard error messages in a std::string or in a const char * Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-11 11:09 +0200
            Re: standard error messages in a std::string or in a const char * Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-11 11:37 +0200
          Re: standard error messages in a std::string or in a const char * Keith Thompson <kst-u@mib.org> - 2019-09-11 02:37 -0700
            Re: standard error messages in a std::string or in a const char * Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-11 11:47 +0200
              Re: standard error messages in a std::string or in a const char * Öö Tiib <ootiib@hot.ee> - 2019-09-11 04:43 -0700
                Re: standard error messages in a std::string or in a const char * James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-11 08:27 -0400
                  Re: standard error messages in a std::string or in a const char * Manfred <noname@add.invalid> - 2019-09-11 14:56 +0200
                    Re: standard error messages in a std::string or in a const char * Daniel <danielaparker@gmail.com> - 2019-09-11 07:00 -0700
            Re: standard error messages in a std::string or in a const char * Thiago Adams <thiago.adams@gmail.com> - 2019-09-11 09:44 -0700
            Re: standard error messages in a std::string or in a const char * Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-12 10:21 +0000
              Re: standard error messages in a std::string or in a const char * Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-12 13:05 +0200
          Re: standard error messages in a std::string or in a const char * Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-11 17:43 +0200
            Re: standard error messages in a std::string or in a const char * Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-11 19:23 +0300
              Re: standard error messages in a std::string or in a const char * Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-11 19:19 +0200
                Re: standard error messages in a std::string or in a const char * Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-11 20:32 +0300
                  Re: standard error messages in a std::string or in a const char * Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-12 13:08 +0200
                    Re: standard error messages in a std::string or in a const char * Thiago Adams <thiago.adams@gmail.com> - 2019-09-12 04:29 -0700
                      Re: standard error messages in a std::string or in a const char * Keith Thompson <kst-u@mib.org> - 2019-09-12 14:41 -0700
                Re: standard error messages in a std::string or in a const char * Thiago Adams <thiago.adams@gmail.com> - 2019-09-11 10:39 -0700
                Re: standard error messages in a std::string or in a const char * James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-11 19:50 -0400
                  Re: standard error messages in a std::string or in a const char * Keith Thompson <kst-u@mib.org> - 2019-09-11 17:11 -0700
                    Re: standard error messages in a std::string or in a const char * James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-11 20:23 -0400
                      Re: standard error messages in a std::string or in a const char * David Brown <david.brown@hesbynett.no> - 2019-09-12 11:21 +0200
                        Re: standard error messages in a std::string or in a const char * James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-12 07:31 -0400
                          Re: standard error messages in a std::string or in a const char * Manfred <noname@add.invalid> - 2019-09-12 15:44 +0200

Page 1 of 2  [1] 2  Next page →

#68299 — standard error messages in a std::string or in a const char *

I'm striving with the translation of standard error codes 
(returned by runtime functions), like "errno" codes in the 
corresponding TEXTUAL DESCRIPTIONS.

I've seen perror () functions knows how to translate errno, 
but it does not allow to return that description as a 
string. Instead it "prints" to stderr, which is useless if 
ones tries to bubble error messages in a chain of function 
calls (with the aim : me, callee, don't know how to handle, 
I bubble the message to you, the caller, and maybe you know 
or THE USER might know).

perror must lookup some internal table where errno's values 
are translated and the text returned (or copied to stderr).

How to get it in a string ?
thanks



-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [next] | [standalone]

#68300

Il 11/09/19 00:35, Soviet_Mario ha scritto:
> I'm striving with the translation of standard error codes 
> (returned by runtime functions), like "errno" codes in the 
> corresponding TEXTUAL DESCRIPTIONS.
> 
> I've seen perror () functions knows how to translate errno, 
> but it does not allow to return that description as a 
> string. Instead it "prints" to stderr, which is useless if 
> ones tries to bubble error messages in a chain of function 
> calls (with the aim : me, callee, don't know how to handle, 
> I bubble the message to you, the caller, and maybe you know 
> or THE USER might know).
> 
> perror must lookup some internal table where errno's values 
> are translated and the text returned (or copied to stderr).
> 
> How to get it in a string ?
> thanks
> 
> 
> 

merd !
sorry ... I find this just now

https://linux.die.net/man/3/strerror

maybe will work ...
:\

-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

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

#68304

On Tue, 2019-09-10, Soviet_Mario wrote:
> Il 11/09/19 00:35, Soviet_Mario ha scritto:
>> I'm striving with the translation of standard error codes 
>> (returned by runtime functions), like "errno" codes in the 
>> corresponding TEXTUAL DESCRIPTIONS.
>> 
>> I've seen perror () functions knows how to translate errno, 
>> but it does not allow to return that description as a 
>> string. Instead it "prints" to stderr, which is useless if 
>> ones tries to bubble error messages in a chain of function 
>> calls (with the aim : me, callee, don't know how to handle, 
>> I bubble the message to you, the caller, and maybe you know 
>> or THE USER might know).
>> 
>> perror must lookup some internal table where errno's values 
>> are translated and the text returned (or copied to stderr).
>> 
>> How to get it in a string ?
>> thanks

> merd !
> sorry ... I find this just now
>
> https://linux.die.net/man/3/strerror
>
> maybe will work ...

It will do what the documentation says, and lots of people use it.
Note its limitations, though.  It's not thread-safe, for example.

/Jorgen

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

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

#68305

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>> https://linux.die.net/man/3/strerror
>>
>> maybe will work ...
> 
> It will do what the documentation says, and lots of people use it.
> Note its limitations, though.  It's not thread-safe, for example.

What do you mean it's not thread-safe? AFAIK errno is thread-local
according to the standard.

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

#68307

>>> https://linux.die.net/man/3/strerror
>>> maybe will work ...

>> It will do what the documentation says, and lots of people use it.
>> Note its limitations, though.  It's not thread-safe, for example.

> What do you mean it's not thread-safe?
> AFAIK errno is thread-local according to the standard.

http://man7.org/linux/man-pages/man3/errno.3.html
"errno is thread-local; setting it in one thread does not affect
its value in any other thread."

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

#68308

>> What do you mean it's not thread-safe?
>> AFAIK errno is thread-local according to the standard.

> http://man7.org/linux/man-pages/man3/errno.3.html
> "errno is thread-local; setting it in one thread does not affect
> its value in any other thread."

 From the 2007 POSIX draft:
"3.396 Thread
A single flow of control within a process. Each thread has its
own thread ID, scheduling priority and policy, errno value ..."

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

#68309

Juha Nieminen <nospam@thanks.invalid> writes:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>> https://linux.die.net/man/3/strerror
>>>
>>> maybe will work ...
>> 
>> It will do what the documentation says, and lots of people use it.
>> Note its limitations, though.  It's not thread-safe, for example.
>
> What do you mean it's not thread-safe? AFAIK errno is thread-local
> according to the standard.

errno is thread-local.  That doesn't necessarily mean that strerror()
is thread-safe.  For example, a conforming implementation could
always return a pointer to the same static buffer, initialized
with the appropriate message before it returns.  And at least one
implementation (x86_64-w64-mingw32-gcc) appears to do exactly that.

N1570 7.24.6.2p3:

    The strerror function is not required to avoid data races with
    other calls to the strerror function. The implementation shall
    behave as if no library function calls the strerror function.

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

#68310

There's strerror_r, which is thread-safe.

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

#68314

On Wednesday, 11 September 2019 12:48:03 UTC+3, Bonita Montero  wrote:
> There's strerror_r, which is thread-safe.

Somewhere there is strerror_r but not in C++ standard. In C++ standard
there was added strerror_s by C++11 but it may be is deprecated again.

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

#68315

On 9/11/19 7:43 AM, Öö Tiib wrote:
> On Wednesday, 11 September 2019 12:48:03 UTC+3, Bonita Montero  wrote:
>> There's strerror_r, which is thread-safe.
> 
> Somewhere there is strerror_r but not in C++ standard. ...

Such a function is specified by POSIX, which doesn't help those
targeting non-POSIX systems.

> ... In C++ standard
> there was added strerror_s by C++11 but it may be is deprecated again.

It is still mentioned in N4659.pdf, dated 2017-03-01. It is described in
20.1.5.2p10 as a carry-over from C. There is no other description,
you're supposed to cross-reference the C standard for that.

The description of sterror_s() in the C standard (C11 K3.7.4.2) does
not, itself, say anything about threads. It simply lacks any clause
comparable to the one in the description of sterror() description which
says "The strerror function is not required to avoid data races with
other calls to the strerror function." (C11 7.24.6.2p3). That's
sufficient, since "Unless explicitly stated otherwise in the detailed
descriptions that follow, library functions shall prevent data races."
(C11 7.1.4p5).

Just in case you didn't notice that omission, footnote 312 on the
description of strerror() says "The strerror_s function can be used
instead to avoid data races.".

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

#68316

On 9/11/2019 2:27 PM, James Kuyper wrote:
> On 9/11/19 7:43 AM, Öö Tiib wrote:
>> On Wednesday, 11 September 2019 12:48:03 UTC+3, Bonita Montero  wrote:
>>> There's strerror_r, which is thread-safe.
>>
>> Somewhere there is strerror_r but not in C++ standard. ...
> 
> Such a function is specified by POSIX, which doesn't help those
> targeting non-POSIX systems.
> 
>> ... In C++ standard
>> there was added strerror_s by C++11 but it may be is deprecated again.
> 
> It is still mentioned in N4659.pdf, dated 2017-03-01. It is described in
> 20.1.5.2p10 as a carry-over from C. There is no other description,
> you're supposed to cross-reference the C standard for that.
> 
> The description of sterror_s() in the C standard (C11 K3.7.4.2) does
> not, itself, say anything about threads. It simply lacks any clause
> comparable to the one in the description of sterror() description which
> says "The strerror function is not required to avoid data races with
> other calls to the strerror function." (C11 7.24.6.2p3). That's
> sufficient, since "Unless explicitly stated otherwise in the detailed
> descriptions that follow, library functions shall prevent data races."
> (C11 7.1.4p5).
> 
> Just in case you didn't notice that omission, footnote 312 on the
> description of strerror() says "The strerror_s function can be used
> instead to avoid data races.".
> 

strerror_s is indeed part of annex K, which has become more and more 
controversial, and some implementations (notably glibc) do not support it.
However, a good indication that it is thread safe comes from its 
interface: instead of returning a pointer to an internal string buffer, 
it requires a writable buffer to be provided by the caller.

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

#68320

On Wednesday, September 11, 2019 at 8:56:57 AM UTC-4, Manfred wrote:
> 
> strerror_s is indeed part of annex K, which has become more and more 
> controversial, and some implementations (notably glibc) do not support it.
> However, a good indication that it is thread safe comes from its 
> interface: instead of returning a pointer to an internal string buffer, 
> it requires a writable buffer to be provided by the caller.

There appears to be a lot to say about some very simple functions! e.g.

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

I hadn't known about this: "since virtually every function in the Bounds 
checking library relies on a single process-global runtime-constraint handler, 
the APIs are ill-suited for multi-threaded components."

Daniel

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

#68333

On Wednesday, September 11, 2019 at 6:37:40 AM UTC-3, Keith Thompson wrote:
> Juha Nieminen rites:
> > Jorgen Grahn  wrote:
> >>> https://linux.die.net/man/3/strerror
> >>>
> >>> maybe will work ...
> >> 
> >> It will do what the documentation says, and lots of people use it.
> >> Note its limitations, though.  It's not thread-safe, for example.
> >
> > What do you mean it's not thread-safe? AFAIK errno is thread-local
> > according to the standard.
> 
> errno is thread-local.  That doesn't necessarily mean that strerror()
> is thread-safe.  For example, a conforming implementation could
> always return a pointer to the same static buffer, initialized
> with the appropriate message before it returns.  And at least one
> implementation (x86_64-w64-mingw32-gcc) appears to do exactly that.
> 
> N1570 7.24.6.2p3:
> 
>     The strerror function is not required to avoid data races with
>     other calls to the strerror function. The implementation shall
>     behave as if no library function calls the strerror function.
> 

I recently came across this subject as well and I was wondering 
why strerror is not thread safe. The answer I gave to myself is that
is probably because it uses locales. It is just a guess.

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

#68357

On Wed, 2019-09-11, Keith Thompson wrote:
> Juha Nieminen <nospam@thanks.invalid> writes:
>> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>>> https://linux.die.net/man/3/strerror
>>>>
>>>> maybe will work ...
>>> 
>>> It will do what the documentation says, and lots of people use it.
>>> Note its limitations, though.  It's not thread-safe, for example.
>>
>> What do you mean it's not thread-safe? AFAIK errno is thread-local
>> according to the standard.
>
> errno is thread-local.

And strerror doesn't use errno.

> That doesn't necessarily mean that strerror()
> is thread-safe.  For example, a conforming implementation could
> always return a pointer to the same static buffer, initialized
> with the appropriate message before it returns.  And at least one
> implementation (x86_64-w64-mingw32-gcc) appears to do exactly that.
>
> N1570 7.24.6.2p3:
>
>     The strerror function is not required to avoid data races with
>     other calls to the strerror function. The implementation shall
>     behave as if no library function calls the strerror function.

That was what I was referring to.  Sorry for being unclear.

/Jorgen

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

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

#68358

Il 12/09/19 12:21, Jorgen Grahn ha scritto:
> On Wed, 2019-09-11, Keith Thompson wrote:
>> Juha Nieminen <nospam@thanks.invalid> writes:
>>> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>>>> https://linux.die.net/man/3/strerror
>>>>>
>>>>> maybe will work ...
>>>>
>>>> It will do what the documentation says, and lots of people use it.
>>>> Note its limitations, though.  It's not thread-safe, for example.
>>>
>>> What do you mean it's not thread-safe? AFAIK errno is thread-local
>>> according to the standard.
>>
>> errno is thread-local.
> 
> And strerror doesn't use errno.


one can always pass errno to it ... but it does not strictly 
guarantee that it will return the message associated with 
THAT particular errno. Elsewhere some other caller could 
have made another call and each receive mixed or the same 
response depending on timing.


> 
>> That doesn't necessarily mean that strerror()
>> is thread-safe.  For example, a conforming implementation could
>> always return a pointer to the same static buffer, initialized
>> with the appropriate message before it returns.  And at least one
>> implementation (x86_64-w64-mingw32-gcc) appears to do exactly that.
>>
>> N1570 7.24.6.2p3:
>>
>>      The strerror function is not required to avoid data races with
>>      other calls to the strerror function. The implementation shall
>>      behave as if no library function calls the strerror function.
> 
> That was what I was referring to.  Sorry for being unclear.
> 
> /Jorgen
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

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

#68328

Il 11/09/19 10:58, Juha Nieminen ha scritto:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>> https://linux.die.net/man/3/strerror
>>>
>>> maybe will work ...
>>
>> It will do what the documentation says, and lots of people use it.
>> Note its limitations, though.  It's not thread-safe, for example.
> 
> What do you mean it's not thread-safe? AFAIK errno is thread-local
> according to the standard.
> 

maybe errno is such, but I think strerror should return a 
pointer to an internal buffer which it alone reserves the 
right to modify on subsequent calls.
In this buffer the function should copy the message (or 
maybe it just sets the pointer to a more risky internally 
maintained table ... much faster).

So if different threads calls the functions without notice, 
one thread could get the error generated from the other ...
That's the little I have understood


but my main problem is : even including all possible 
headers, QT IDE does not see strerror prototype.

Normally when I include sth, within seconds the intellisense 
starts popping up the parameters type-info and return value. 
Here it does not do so, and underlines the name in red as 
unknown :\ :\

-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

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

#68332

On 11.09.2019 18:43, Soviet_Mario wrote:
>
> but my main problem is : even including all possible headers, QT IDE
> does not see strerror prototype.

"All possible headers" are not needed, man strerror clearly says it is 
declared in <string.h>.

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

#68337

Il 11/09/19 18:23, Paavo Helde ha scritto:
> On 11.09.2019 18:43, Soviet_Mario wrote:
>>
>> but my main problem is : even including all possible 
>> headers, QT IDE
>> does not see strerror prototype.
> 
> "All possible headers" are not needed, man strerror clearly 
> says it is declared in <string.h>.
> 

thanks a lot.
I included C++ like headers, among them "plain" <string>
and guess what ?
the C++ header DONT have a strerror prototype.
But later I replaced that header with the C-like you 
suggested, and exploring the code I found the prototype.

Many thanks Paavo !

-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

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

#68339

On 11.09.2019 20:19, Soviet_Mario wrote:
> Il 11/09/19 18:23, Paavo Helde ha scritto:
>> On 11.09.2019 18:43, Soviet_Mario wrote:
>>>
>>> but my main problem is : even including all possible headers, QT IDE
>>> does not see strerror prototype.
>>
>> "All possible headers" are not needed, man strerror clearly says it is
>> declared in <string.h>.
>>
>
> thanks a lot.
> I included C++ like headers, among them "plain" <string>
> and guess what ?
> the C++ header DONT have a strerror prototype.

That's expected. The C++ equivalent of <string.h> is <cstring>, not 
<string>. And even with <cstring> you should call std::strerror(), not 
strerror().

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

#68359

Il 11/09/19 19:32, Paavo Helde ha scritto:
> On 11.09.2019 20:19, Soviet_Mario wrote:
>> Il 11/09/19 18:23, Paavo Helde ha scritto:
>>> On 11.09.2019 18:43, Soviet_Mario wrote:
>>>>
>>>> but my main problem is : even including all possible 
>>>> headers, QT IDE
>>>> does not see strerror prototype.
>>>
>>> "All possible headers" are not needed, man strerror 
>>> clearly says it is
>>> declared in <string.h>.
>>>
>>
>> thanks a lot.
>> I included C++ like headers, among them "plain" <string>
>> and guess what ?
>> the C++ header DONT have a strerror prototype.
> 
> That's expected. The C++ equivalent of <string.h> is 
> <cstring>, not <string>. 

ahhhh ! Got it. Strangely I had included the (useless) 
<cerrno> but not completely consciously, and did not include 
<cstring>

> And even with <cstring> you should 
> call std::strerror(), not strerror().

it allowed plain strerror, maybe due to the fact I have 
included a using namespace std directive. I will remove it 
anyway

tnx again

> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web