Hi,
Il giorno Mon, 10 Jun 2013 19:14:50 -0500
"Galos, David" <galosd83_AT_students.rowan.edu> ha scritto:
> The only useful changes to nice here are the move of usage, which is
> more stylistically consistent with the rest of the source, and the
> proper POSIX return value.
>
> I was under the impression that this project includes ARGBEGIN/ARGEND
> macros specifically to avoid getopt, so I see no reason to change to
> it; it's more verbose anyway.
>
If you like it more with ARGBEGIN/ARGEND, I'm fine with it, I
personally saw no reason to use ARGBEGIN and ARGEND macros when getopt
is standard, tested and works just fine, but if that isn't the case,
then I'll modify it accordingly.
> The nice system call automatically clamps the specified value to a
> reasonable number, and even within linux, acceptable values have
> changed enough that including a clamp results in nice being less
> stable, not more.
>
Actually coreutils performs the exact same clamping with the same
value, but according to POSIX it should be unnecessary, so I agree, it
can be removed.
> The change to estrtol could be useful, but it could be better to
> simply replace the atoi call with it, rather than introduce an extra
> variable just to delay the exit until the end of the input loop.
>
>
The point was not to delay the exit after the end of input, but to use
the same path both for the default behavior and the behavior with a
modified value, I find useful to have the minimum amount of logic done
during argument parsing. Both approaches are pretty much the same
anyway, so reverting the change is not a problem.
--
Lorenzo Cogotti
Received on Tue Jun 11 2013 - 14:47:39 CEST