Re: factor

[ThMO]

Hello Jim and others listening,

> [...]
> I'd be more interested in a patch to make GNU factor accept negative
> numbers if it weren't so invasive.  How about just examining the string
> for a leading `-' (possibly after white space), remembering that, and
> skipping over it.  Then the existing unsigned code will work just fine.
> Patch below.

That's a possibility too.

But your patch introduces a bug - it's possible now to give an invalid
number on the command line, which would normally be rejected by strtol():
·  ./gfactor -- '  -  130'
·  ./gfactor -- '  -  +131'
xstrtoumax() now skips the white spaces between `-' and the number itself,
which is wrong in this case; so if a minus sign has been scanned, you need
to ensure, that there is a digit following immediately.  The same applies
for a possible `+' sign.
That's the reason, why I've preferred to let this dirty work handed over
to the conversion routines, as otherwise I'll have to reinvent the wheel
over and over again...

Another ugly looking thing, although it's not quite an error:
  ./gfactor -- '-69ways'
would state, that ``-69ways'' isn't a valid *positive* value, which isn't
quite the correct error message, as 
  ./gfactor -- -69
will work as expected, so the word `positive' should be eliminated, IMHO.

> BTW, thanks for the improved definition of MAX_N_FACTORS.
> I've already checked in that part.

Seems to be the obvious thing.

> If you're really interested in improving this program, extending it to
> use GMP[*] (i.e., -lgmp) is the way to go.  Then, it will be able to
> accept arbitrarily long strings of digits, and of course it'll be
> much more efficient for large numbers.

I may check this out using my v3.1.1 of the gmp library, but I can't promise
you that, since my personal approach would be to write a wrapper-script around
`gp', as it's inceribbly fast...

THX for listening.

CU Tom.
(Thomas M.Ott)
Germany