Hi,
On Mon, Apr 14, 2025 at 09:51:50PM +, justin.colon--- via Gcc wrote:
> Hello GCC and GNU support, I am the proxy service lead for Lockheed
> Martin and something seems to be blocking our traffic when our US
> users try to reach https://gcc.gnu.org/onlinedocs/. Our Non-US users
> do not hav
Hello GCC and GNU support, I am the proxy service lead for Lockheed Martin and
something seems to be blocking our traffic when our US users try to reach
https://gcc.gnu.org/onlinedocs/. Our Non-US users do not have the same issues.
Our reserved Zscaler IP Space for US users is the following:
13
On Mon, 14 Apr 2025 at 14:47, Julian Waters wrote:
>
> Hi Jonathan,
>
> Thanks for the suggestion, it seems promising. I switched out the
> error attribute for the warning attribute at first, since they should
> be equivalent except warning just warns instead of erroring. This
> results in the lin
On Mon, 14 Apr 2025 at 11:53, Julian Waters wrote:
>
> Hi Jonathan,
>
> Yep, unfortunately #pragma GCC poison is far too restrictive, it
> doesn't check if it is a function call to that particular banned
> function, it restricts any and all use of that identifier in the code
> altogether. Not only
On Mon, 14 Apr 2025 at 12:57, Jonathan Wakely wrote:
>
> On Mon, 14 Apr 2025 at 11:53, Julian Waters wrote:
> >
> > Hi Jonathan,
> >
> > Yep, unfortunately #pragma GCC poison is far too restrictive, it
> > doesn't check if it is a function call to that particular banned
> > function, it restricts
>
>
> A codebase I'm working with has decided that poisoning certain
> standard library functions is necessary, as it explicitly does not use
> those functions unless absolutely necessary for its own reasons (This
> was not my decision to make). As such, we've been looking into ways to
> implemen
Hi Jonathan,
Yep, unfortunately #pragma GCC poison is far too restrictive, it
doesn't check if it is a function call to that particular banned
function, it restricts any and all use of that identifier in the code
altogether. Not only does this mean you can't use overloads of a
banned function, you
On Mon, 14 Apr 2025 at 10:11, Julian Waters via Gcc wrote:
>
> Hi all,
>
> A codebase I'm working with has decided that poisoning certain
> standard library functions is necessary, as it explicitly does not use
> those functions unless absolutely necessary for its own reasons (This
> was not my de
Hi all,
A codebase I'm working with has decided that poisoning certain
standard library functions is necessary, as it explicitly does not use
those functions unless absolutely necessary for its own reasons (This
was not my decision to make). As such, we've been looking into ways to
implement that.
