__attribute__ error ("message")

__attribute__ error ("message")

[Jonny Grant]

Hello

May I check, does this attribute error output the error message usually?
My example links fine without any warnings or errors.

Maybe I am misunderstanding it. I am sharing a simple program below and godbolt trunk example.
I only get to see the error message if I don't implement the function and get a link failure.

https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

error ("message")
warning ("message")

If the error or warning attribute is used on a function declaration and a call to such a function is not eliminated through dead code elimination or other optimizations, an error or warning (respectively) that includes message is diagnosed. 



https://godbolt.org/z/n849GPTjj


void compile_abort() __attribute__((error("compile abort")));

void compile_abort()
{
    __builtin_abort();
}

int main()
{
    compile_abort();
}

Re: __attribute__ error ("message")

[Jonathan Wakely]

On Fri, 31 Mar 2023 at 22:55, Jonny Grant wrote:
>
> Hello
>
> May I check, does this attribute error output the error message usually?
> My example links fine without any warnings or errors.
>
> Maybe I am misunderstanding it. I am sharing a simple program below and godbolt trunk example.
> I only get to see the error message if I don't implement the function and get a link failure.

Are you sure about that? If you remove the definition, you should get the error:

https://godbolt.org/z/z1hjn6Yan


>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
>
> error ("message")
> warning ("message")
>
> If the error or warning attribute is used on a function declaration and a call to such a function is not eliminated through dead code elimination or other optimizations, an error or warning (respectively) that includes message is diagnosed.
>
>
>
> https://godbolt.org/z/n849GPTjj
>
>
> void compile_abort() __attribute__((error("compile abort")));
>
> void compile_abort()
> {
>     __builtin_abort();
> }
>
> int main()
> {
>     compile_abort();
> }

Re: __attribute__ error ("message")

[Xi Ruoyao]

On Fri, 2023-03-31 at 22:54 +0100, Jonny Grant wrote:
> If the error or warning attribute is used on a function declaration
> and a call to such a function is not eliminated through dead code
> elimination or other optimizations, an error or warning (respectively)
> that includes message is diagnosed. 

In this example the "call to such a function" is clearly "eliminated
through" inlining (one of "other optimizations").

> https://godbolt.org/z/n849GPTjj

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: __attribute__ error ("message")

[Jonny Grant]

On 31/03/2023 22:58, Xi Ruoyao wrote:
> On Fri, 2023-03-31 at 22:54 +0100, Jonny Grant wrote:
>> If the error or warning attribute is used on a function declaration
>> and a call to such a function is not eliminated through dead code
>> elimination or other optimizations, an error or warning (respectively)
>> that includes message is diagnosed. 
> 
> In this example the "call to such a function" is clearly "eliminated
> through" inlining (one of "other optimizations").
> 
>> https://godbolt.org/z/n849GPTjj
> 

ok yes, now I understand. The compile_abort() got inlined as abort().

compile_abort():
        pushq   %rax
        call    abort
main:
        pushq   %rax
        call    abort


So if I implement it, I must avoid it being optimized (using pragma etc as below)

Or do as Jonathan Wakely suggested, and just remove the implementation.


#pragma GCC push_options
#pragma GCC optimize ("O0")
void compile_abort()
{
}
#pragma GCC pop_options

Re: __attribute__ error ("message")

[Xi Ruoyao]

On Fri, 2023-03-31 at 23:12 +0100, Jonny Grant wrote:
> 
> 
> On 31/03/2023 22:58, Xi Ruoyao wrote:
> > On Fri, 2023-03-31 at 22:54 +0100, Jonny Grant wrote:
> > > If the error or warning attribute is used on a function
> > > declaration
> > > and a call to such a function is not eliminated through dead code
> > > elimination or other optimizations, an error or warning
> > > (respectively)
> > > that includes message is diagnosed. 
> > 
> > In this example the "call to such a function" is clearly "eliminated
> > through" inlining (one of "other optimizations").
> > 
> > > https://godbolt.org/z/n849GPTjj
> > 
> 
> ok yes, now I understand. The compile_abort() got inlined as abort().
> 
> compile_abort():
>         pushq   %rax
>         call    abort
> main:
>         pushq   %rax
>         call    abort
> 
> 
> So if I implement it, I must avoid it being optimized (using pragma
> etc as below)

Or just __attribute__((noipa)).

> 
> Or do as Jonathan Wakely suggested, and just remove the
> implementation.
> 
> 
> #pragma GCC push_options
> #pragma GCC optimize ("O0")
> void compile_abort()
> {
> }
> #pragma GCC pop_options

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: __attribute__ error ("message")

[Jonny Grant]

On 31/03/2023 23:13, Xi Ruoyao wrote:
> On Fri, 2023-03-31 at 23:12 +0100, Jonny Grant wrote:
>>
>>
>> On 31/03/2023 22:58, Xi Ruoyao wrote:
>>> On Fri, 2023-03-31 at 22:54 +0100, Jonny Grant wrote:
>>>> If the error or warning attribute is used on a function
>>>> declaration
>>>> and a call to such a function is not eliminated through dead code
>>>> elimination or other optimizations, an error or warning
>>>> (respectively)
>>>> that includes message is diagnosed. 
>>>
>>> In this example the "call to such a function" is clearly "eliminated
>>> through" inlining (one of "other optimizations").
>>>
>>>> https://godbolt.org/z/n849GPTjj
>>>
>>
>> ok yes, now I understand. The compile_abort() got inlined as abort().
>>
>> compile_abort():
>>         pushq   %rax
>>         call    abort
>> main:
>>         pushq   %rax
>>         call    abort
>>
>>
>> So if I implement it, I must avoid it being optimized (using pragma
>> etc as below)
> 
> Or just __attribute__((noipa)).

That's much clearer.

It does feel a shame the optimizer inlines the function, discarding the error("message"), before the attribute error("message") can be triggered. But we can just put that __attribute__((noipa)) at least.

Jonny

Re: __attribute__ error ("message")

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

On Sat, 1 Apr 2023, 17:58 Jonny Grant, <jg@jguk.org> wrote:

>
>
> On 31/03/2023 23:13, Xi Ruoyao wrote:
> > On Fri, 2023-03-31 at 23:12 +0100, Jonny Grant wrote:
> >>
> >>
> >> On 31/03/2023 22:58, Xi Ruoyao wrote:
> >>> On Fri, 2023-03-31 at 22:54 +0100, Jonny Grant wrote:
> >>>> If the error or warning attribute is used on a function
> >>>> declaration
> >>>> and a call to such a function is not eliminated through dead code
> >>>> elimination or other optimizations, an error or warning
> >>>> (respectively)
> >>>> that includes message is diagnosed.
> >>>
> >>> In this example the "call to such a function" is clearly "eliminated
> >>> through" inlining (one of "other optimizations").
> >>>
> >>>> https://godbolt.org/z/n849GPTjj
> >>>
> >>
> >> ok yes, now I understand. The compile_abort() got inlined as abort().
> >>
> >> compile_abort():
> >>         pushq   %rax
> >>         call    abort
> >> main:
> >>         pushq   %rax
> >>         call    abort
> >>
> >>
> >> So if I implement it, I must avoid it being optimized (using pragma
> >> etc as below)
> >
> > Or just __attribute__((noipa)).
>
> That's much clearer.
>
> It does feel a shame the optimizer inlines the function, discarding the
> error("message"), before the attribute error("message") can be triggered.
> But we can just put that __attribute__((noipa)) at least.
>

Why provide a definition? Why do you want to define a function that can
never be called, because calling it gives an error?

Re: __attribute__ error ("message")

[Jonny Grant]

On 02/04/2023 00:00, Jonathan Wakely wrote:
> 
> 
> On Sat, 1 Apr 2023, 17:58 Jonny Grant, <jg@jguk.org <mailto:jg@jguk.org>> wrote:
> 
> 
> 
>     On 31/03/2023 23:13, Xi Ruoyao wrote:
>     > On Fri, 2023-03-31 at 23:12 +0100, Jonny Grant wrote:
>     >>
>     >>
>     >> On 31/03/2023 22:58, Xi Ruoyao wrote:
>     >>> On Fri, 2023-03-31 at 22:54 +0100, Jonny Grant wrote:
>     >>>> If the error or warning attribute is used on a function
>     >>>> declaration
>     >>>> and a call to such a function is not eliminated through dead code
>     >>>> elimination or other optimizations, an error or warning
>     >>>> (respectively)
>     >>>> that includes message is diagnosed.
>     >>>
>     >>> In this example the "call to such a function" is clearly "eliminated
>     >>> through" inlining (one of "other optimizations").
>     >>>
>     >>>> https://godbolt.org/z/n849GPTjj <https://godbolt.org/z/n849GPTjj>
>     >>>
>     >>
>     >> ok yes, now I understand. The compile_abort() got inlined as abort().
>     >>
>     >> compile_abort():
>     >>         pushq   %rax
>     >>         call    abort
>     >> main:
>     >>         pushq   %rax
>     >>         call    abort
>     >>
>     >>
>     >> So if I implement it, I must avoid it being optimized (using pragma
>     >> etc as below)
>     >
>     > Or just __attribute__((noipa)).
> 
>     That's much clearer.
> 
>     It does feel a shame the optimizer inlines the function, discarding the error("message"), before the attribute error("message") can be triggered. But we can just put that __attribute__((noipa)) at least.
> 
> 
> Why provide a definition? Why do you want to define a function that can never be called, because calling it gives an error?

You make a good point. There's no need to define it, the declaration is enough to get the build error. Without the definition, it doesn't get inlined too.
Jonny

Warning for unsafe/insecure functions

[Rajeev Bansal]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

 Hi All,

  I am looking for if gcc has the capability to report unsafe/insecure
functions used in a C Or CPP program? For example : if strcpy(), strcat(),
alloca(), atoi() etc. are used in a program then gcc should raise a
warning.

In my google search and gcc man page I couldn't find any gcc flags for this
purpose. Let's say if gcc doesn't have the inbuilt capability of reporting
of insecure function calls so how can I add  this functionality in gcc?

Thanks,
-Rajeev

Re: Warning for unsafe/insecure functions

[Xi Ruoyao]

On Sat, 2023-04-01 at 22:41 +0530, Rajeev Bansal via Gcc-help wrote:
>  Hi All,
> 
>   I am looking for if gcc has the capability to report unsafe/insecure
> functions used in a C Or CPP program? For example : if strcpy(), strcat(),
> alloca(), atoi() etc. are used in a program then gcc should raise a
> warning.

If most people believe they are dangerous, they will be marked with
__attribute__((deprecated)) in libc headers.  Then GCC will emit a
warning with -Wdeprecated (enabled by default).

But libc is not a part of GCC.  And before you start to wonder: no, a
patch deprecating these function will be rejected, please do not send
such a patch to libc-alpha.

There are still many valid uses of these functions and you cannot
deprecate them just because your will.  "I think it's dangerous" is
different from "the function is inherently dangerous" or "most people
think it's dangerous".

If you don't want those functions in your project, you can create some
wrappers like:

__attribute__((deprecated)) static inline char *
_strcpy_do_not_use (char *dest, const char *src)
{
  return strcpy (dest, src);
}

#define strcpy _strcpy_do_not_use

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: Warning for unsafe/insecure functions

[Rajeev Bansal]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

Thank you, Xi. I agree with what you said. The solution you suggested will
work for me.

Thanks,
-Rajeev

On Sun, Apr 2, 2023 at 12:20 AM Xi Ruoyao <xry111@xry111.site> wrote:

> On Sat, 2023-04-01 at 22:41 +0530, Rajeev Bansal via Gcc-help wrote:
> >  Hi All,
> >
> >   I am looking for if gcc has the capability to report unsafe/insecure
> > functions used in a C Or CPP program? For example : if strcpy(),
> strcat(),
> > alloca(), atoi() etc. are used in a program then gcc should raise a
> > warning.
>
> If most people believe they are dangerous, they will be marked with
> __attribute__((deprecated)) in libc headers.  Then GCC will emit a
> warning with -Wdeprecated (enabled by default).
>
> But libc is not a part of GCC.  And before you start to wonder: no, a
> patch deprecating these function will be rejected, please do not send
> such a patch to libc-alpha.
>
> There are still many valid uses of these functions and you cannot
> deprecate them just because your will.  "I think it's dangerous" is
> different from "the function is inherently dangerous" or "most people
> think it's dangerous".
>
> If you don't want those functions in your project, you can create some
> wrappers like:
>
> __attribute__((deprecated)) static inline char *
> _strcpy_do_not_use (char *dest, const char *src)
> {
>   return strcpy (dest, src);
> }
>
> #define strcpy _strcpy_do_not_use
>
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University
>