Generally LGTM, any reason not to poison getenv to make sure it's not used by accident?

Generally LGTM, any reason not to poison getenv to make sure it's not used by accident?

multiple reasons,

1. never heard of it, grepped the code base, seems like it's rarely used, and gcc specific.

2. I don't see a nice way to do it. poison is gcc specific, msvc has #pragma deprecated which kinda does the same thing but emits a warn, but i guess we could add /we4995 to the list of warnings promoted to errors in the main CMakelists.txt. so in theory we could make a macro like this

#ifdef WIN32
#    define POISON(x) __pragma(deprecated(x))
#else
#    define POISON(x) __pragma(GCC poison x)
#endif

and dump it in a header of our liking. and use POISON(getenv) however now there's a new set of problems.

a) in BLI_getenv we still very much like to call it for non windows platforms.

b) Any other deprecated functions such as GetVersionExA (called from system header multimon.h so we can't go in and fix it) will now error instead of warn..

so neat idea, but it seems a tiny bit like opening a can of worms.

Avoiding getenv can be handled in a separate patch,
note that its possible to poison a function and ignore it in a spesific location if we want, or we could just not poison it for the file which calls it.

Reason to suggest this is it's easy for issues to creep back in if a developer forgets we have our own version of this function, this might take years to notice.. users/developers might loose some hours to research and find its exactly the same bug we already solved.

Looked further into a possible deprecation framework. And there's the following issues.

1. No unified way to do this across compilers.
2. There is some way to do this (ie attribute((deprecated)) or #pragma poison for gcc and __declspec(deprecated) for msvc) this is really only applicable to code we control. deprecating functions in the crt is troublesome.
3. even if 2 would work, there's no real way to enforce it, if someone doesn't include the header for deprecation he'll still happily be able to call getenv. There is a way to force include a header for most compilers, but that in turn might break any third party code that we build.
4. no exceptions, it's nearly impossible to make an exception,and we still very much would like to call getenv inside BLI_getenv for some of the platforms.

I feel this is more a task for something like a lint tool (maybe clang-tidy?) than something we can properly solve with some header hackery.

I don't see a way to turn this into a nicely supported framework that's not a giant kludge of hacks and ductape, either way it's well beyond the scope of fixing T54152.

I don't think its necessary to have a deprecation framework or an all-or-nothing approach. Solving this for GCC/Clang is enough that these problems don't get into a release.
MSVC support would be nice, but IIRC it doesn't support features needed for this.

It could be as simple as:

• Define functions we don't allow as error defines.
• Explicit use can undef them.

Or we could use a regex search which runs periodically (ignoring comments and accounting for a handful of exceptions).

*poke*

Please review as is, the deprecation thing has wasted enough time, can't find a nice way that'll work with all compiler configurations, and this bug is holding back other windows things.

ah crap, i merged master and a bunch of comment changes leaked in, no idea wtf.... i'm blaming arc here.