Drew,
I agree with Terry, but would like to add some more details.
The statement you sited relates to the case when the value of OMP_PROC_BIND is not among cases listed in OpenMP specification as allowed - true, false, master, spread, close.
E.g. OMP_PROC_BIND=123456789. In this case the behavior is implementation defined. That means implementation can do whatever it wants, only requirement is the implementation needs to describe its actions in documentation. The statement has nothing with correct values of the OMP_PROC_BIND.
a fake omp library that needs to return the same value as a real omp library
What real omp library do you mean? There are many real omp libraries on the market - Microsoft omp library, IBM omp library, GNU omp library, etc. Each real omp library can have different behavior, so you need to pick one to emulate.
if the OMP_PROC_BIND variable is set, then omp_get_proc_bind should return the value that corresponds to what the user requested.
That's fine. But what if user requested to return implementation defined value? Like with OMP_PROC_BIND=true the implementation should return the first element on bind-var ICV list, which is implementation defined.
When OMP_PROC_BIND is used is the return value of omp_get_proc_bind allowed to be implementation defined or not?
My interpretation is: yes. Once the specification defined only three thread affinity policies - master, close and spread, - but also allows to specify that binding if just "enabled" via OMP_PROC_BIND=true, it is implementation defined how the bind-var list is filled in this case. Note that "true" is not a thread affinity policy, - that is my understanding.
Also, an implementation is allowed to add more thread affinity policies to the list of allowed ones. Then it is possible to set other policies via OMP_PROC_BIND, and retrieve via omp_get_proc_bind(). This of cause should be documented, and omp.h header should have all the definitions.
-- Andrey