For C, the proper/expected/standard way to reference a variable without accessing it is a cast to void:

    (void) a;

I'm sure there are commonly-implemented compiler extensions, but this is the normal/native way and should always work.

▲ amluto a day ago | parent [-]

Not if you use GCC.

https://godbolt.org/z/zYdc9ej88

clang gets this right.

▲

comex a day ago | parent | next [-]

It does work in GCC to suppress unused variable warnings. Just not for function calls I guess.

	▲	cminmin 17 hours ago \| parent [-]
		__attribute__((maybe_unused)) or [[maybe_unused]] or such things (dependin on ur spec version i guess?) can be used not to disable a whole line of errors.

▲

gpderetta 12 hours ago | parent | prev | next [-]

interestingly it works for [[nodiscard]]!

and assigning to std::ignore works for both.

▲

Am4TIfIsER0ppos a day ago | parent | prev [-]

You've defined that function with an attribute saying not to ignore the returned value. Is it right to explicitly silence an explicit warning?

▲

amluto a day ago | parent | next [-]

I want some defined way to tell the compiler that I am intentionally ignoring the result.

I encounter this when trying to do best-effort logging in a failure path. I call some function to log and error and maybe it fails. If it does, what, exactly, am I going to do about it? Log harder?

▲

dotancohen 18 hours ago | parent [-]

Yes.

When my database logging fails, I write a file that logs the database fail (but not the original log file).

When my file logging fails, depending on application, I'll try another way of getting the information (the fact that for file logging failed) out - be that an http request or an email or something else.

Databases fail, file systems fill up. Logging logging failures is extremely important.

▲

amluto 18 hours ago | parent [-]

And when that last way fails, what do you do?

I like to have a separate monitoring process that monitors my process and a separate machine in a different datacenter monitoring that. But at the end of the day, the first process is still going to do try to log, detect that it failed, try the final backup log and then signal to its monitor that it’s in a bad state. It won’t make any decisions that depend on whether the final backup logging succeeds or fails.

	▲	dotancohen 16 hours ago \| parent [-]
		I'm not working on anything life-critical, one additional layer of redundancy is all I budget for. If both my database is down and my local filesystem is full simultaneously, things have gone bad and I've likely got lots of other symptoms I'm going to find to direct me.

▲

MathMonkeyMan a day ago | parent | prev [-]

Sometimes. For example, you might be setting a non-crucial option on a socket, and if it fails you don't even care to log the fact (maybe the logging would be too expensive), so you just ignore the return value of whatever library is wrapping setsockopt.