native: prettify argument parsing

[miri64]

I always found it quite weird how native parses it's command-line arguments. This PR moves that to libc's getopt_long(). According to my research this should also be available on OSX and BSD. I also cleaned up some weird state settings (using strings instead of enums oO, what was that about).

Reminder to self: fix #6121 and #6311 for this if this PR gets merged.

[LudwigKnuepfer]

using strings instead of enums oO, what was that about

Honestly I can't remember why I chose to do so. Probably I was just too lazy. The reason why I did not change it is that it does not make that much of a difference IMHO. It's not like this is on a hot path or something ;) Another reason might be that historically this information was also used in a different module and this made the internal API simpler. Look at the git history if you are really interested and not just trying to troll me :-p
In any case this is an improvement, so thank you :)

[LudwigKnuepfer]

You have my general blessing for making the long due switch to getopt per se ;)
Code looks sane as well.

However I do not have time to carefully test, or capacity to think through it though.
Please pick someone else for reviewing.

[miri64]

Look at the git history if you are really interested and not just trying to troll me :-p

Not trying to troll you, just honest bewilderment. Seems like it was laziness after all (or because of stuff you never commited), since it is like this basically since its inception in 864267f

[LudwigKnuepfer]

Actually this is what I had in mind when I wrote:

Another reason might be that historically this information was also used in a different module and this made the internal API simpler.

Modules are cpu and board in this case.

[OlegHahm]

Did someone check on BSD or OSX? @kYc0o, @emmanuelsearch, @smlng?

[OlegHahm]

Maybe you change this to a nice ERRNO?

[miri64]

It's native internal and I just check if an error accured. I don't see the point to use an errno here.

[OlegHahm]

I thought it would ease refactoring to have macro constant instead of a literal, but no strong opinion.

[miri64]

It's just this internal function and the check is either <0 or =0, so even if there is refactoring needed in the future, it shouldn't be that extensive. ;-)

[miri64]

Remember: we are talking about the error-handling of some file-internal function that executes commands by a value that was set due to user input. ;-)

[smlng]

just tested (a little) on macOS: works

[miri64]

just tested (a little) on macOS: works

what does "a little" mean, did you check long options and short e.g.?

[OlegHahm]

just tested (a little) on macOS: works

what does "a little" mean, did you check long options and short e.g.?

From Cambridge Dictionary:

(A) little and (a) few are quantifiers meaning ‘some’. Little and few have negative meanings. We use them to mean ‘not as much as may be expected or wished for’.

[miri64]

@OlegHahm Go home, you're drunk

[smlng]

I tested with example/hello-world, and tried for instance -o and --stdout-pipe and same for stderr -> worked. What else do you suggest?

[edit] for the nit picky: on macOS, of course

[OlegHahm]

Btw. the elf file grows by about 4kB.

[miri64]

Just to test both long and short options, because during implementation I wasn't sure getopt_long() is actually working on non-GNU systems (though through research I found out it is, but still I have some sliver of doubt ;-)).

[miri64]

Btw. the elf file grows by about 4kB.

I find more readable code and easier handling of command-line options actually better for native-only code, than thinking about code-size ;-)

[LudwigKnuepfer]

Btw. the elf file grows by about 4kB.

That's about 5% for examples/gnrc_minimal and examples/hello-world, 2% for examples/gnrc_border_router.

More interesting (although probably as insignificant): what's the increase in RAM usage?