[Toybox] getconf NPROCESSORS_ONLN broken

[enh]

On Thu, Oct 4, 2018 at 2:12 PM Rob Landley <rob at landley.net> wrote:
>
> On 10/04/2018 03:48 PM, enh wrote:
> > yeah, and right now we have exactly one macro for which we need this...
> >
> > ...and an alternative fix would be to just drop the UUCP feature from
> > getconf. GNU getconf doesn't support it (somewhat obviously), and
> > Android is always going to say "no", and i'm not expecting a great
> > UUCP renaissance any time soon where it suddenly becomes relevant
> > again.
>
> Trimming the UUCP feature sounds fine to me, although I need to revisit the
> whole mess of:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/getconf.html
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/sysconf.html
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/confstr.html
>
> At some point...
>
> Possibly what I need is an #ifdef/#else staircase for all those symbols in a
> header file, which can be generated once from the actual posix spec and then
> ignored. (I don't care about ugly in header files. I just don't want the data in
> two places that have to be kept in sync...)

i think that's overkill. we demonstrably don't have to care about
anything outside the subset that GNU supports. (and in practice it
seems like there are really only a tiny handful that are actually
used.)

i think my patch to add the pathconf variables is more useful ---
there are real live instances of that in the AOSP build.

note that i also have an orthogonal interest in going in the direction
of my patches: if i'm going to move AOSP to toybox, i'll end up
replicating your build scripts in soong. so as far as i'm concerned,
the less that's done there, the better...

> > (but i'm still interested to see that's even possible with the
> > preprocessor. i've long believed it wasn't.)
>
> Preprocessor combined with the ? : operator working on a constant first argument
> so the test optimizes out, maybe? (If C11 or C18 had added _is_defined(x) and
> macro_or_default(x, y) instead of all the useless nonsense it _did_ add, I'd
> care a lot more about them...)
>
> But at the moment I'm tired after a long day of sitting in a cubicle and trying
> to work through company politics and history to figure out what (if anything)
> the technical requirements for various Change Requests are, besides which I
> shouldn't be thinking about this for another hour anyway. :)
>
> Rob