GNU bug report logs - #11085
RFE: teach factor to read/write hexadecimal

Previous Next

To reply to this bug, email your comments to 11085 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Adam Back <adam <at> cypherspace.org>
To: bug-coreutils <at> gnu.org
Subject: factor only supports decimal numbers, doh
Date: Sat, 24 Mar 2012 16:07:11 +0100

Which is stupid because in most cryptographic applications, which is the
main practical use of factor, if people are going to include this in
distrubitons, use hexadecimal.  The underlying crypto library obviously
supports hex and its is more native number system anyway, so please enable
hex numbers.  eg 0xF it might be nice if the factors were in the same base
as the input, or if there was a flag to control the output radix...

Adam

Message #8 received at 11085 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Adam Back <adam <at> cypherspace.org>
Cc: 11085 <at> debbugs.gnu.org
Subject: Re: bug#11085: factor only supports decimal numbers, doh
Date: Sun, 25 Mar 2012 09:54:39 +0200

Adam Back wrote:
> Which is stupid because in most cryptographic applications, which is the
> main practical use of factor, if people are going to include this in
> distrubitons, use hexadecimal.  The underlying crypto library obviously

A feature request that starts with "your implementation is stupid..."
generally doesn't get far, even when it has merit.

What would be near-sighted (I wouldn't say "stupid")
would be to add explicit support for hexadecimal input
when you can get the same effect via your shell:

  factor $((0x1fffffffffffffff))

If the input is larger than 2^64, use bc or dc:

  factor $(echo 'ibase=16; FFFFFFFFFFFFFFFFF' |bc)


> supports hex and its is more native number system anyway, so please enable
> hex numbers.  eg 0xF it might be nice if the factors were in the same base
> as the input, or if there was a flag to control the output radix...

You might have heard about the Unix Philosophy?
It is about connecting tools like factor and bc or your shell
so that we don't have to duplicate base-conversion functionality
in every tool that accepts an integer input.  Similarly, if you
require hexadecimal output, use printf %x for small numbers or
bc/dc/perl/python to convert.

Message #11 received at 11085 <at> debbugs.gnu.org (full text, mbox):

From: Adam Back <adam <at> cypherspace.org>
To: Jim Meyering <jim <at> meyering.net>
Cc: 11085 <at> debbugs.gnu.org
Subject: Re: bug#11085: factor only supports decimal numbers, doh
Date: Sun, 25 Mar 2012 15:23:01 +0200

Hi, 

Thanks for replying.  I am aware of bc, dc etc.  And in fact that was what I
did to work around (used bc), but it seems like unnecessary feature removal
when the underlying crypto library the tool is calling to actually do the
work is more natively working with hex (binary).

Sorry about getting off on the wrong foot with the "stupid" word mixed into
my thought.

I have been using unix exclusively since 1989, and yes I am a fan of the
unix philosophy.  I would qualify "it is possible to use other tools to work
around the lack of this feature" to more the tools are scalable,
conveniently pluggable etc.  And convenient pluggability applies IMO.

Eg lets say od can output in different formats (-tx1 I use commonly if I
need convert a file into something suitable to chain with some other crypto
command line tool) ...  you "could" no doubt work around that with awk, perl
or maybe even bc if you were creative, but it just makes things less
convenient to chain if the default or only output is not directly
compatibile with the main consuming next in the chain tools natural, default
or only input...

Adam

On Sun, Mar 25, 2012 at 09:54:39AM +0200, Jim Meyering wrote:
>Adam Back wrote:
>> Which is stupid because in most cryptographic applications, which is the
>> main practical use of factor, if people are going to include this in
>> distrubitons, use hexadecimal.  The underlying crypto library obviously
>
>A feature request that starts with "your implementation is stupid..."
>generally doesn't get far, even when it has merit.
>
>What would be near-sighted (I wouldn't say "stupid")
>would be to add explicit support for hexadecimal input
>when you can get the same effect via your shell:
>
>  factor $((0x1fffffffffffffff))
>
>If the input is larger than 2^64, use bc or dc:
>
>  factor $(echo 'ibase=16; FFFFFFFFFFFFFFFFF' |bc)
>
>
>> supports hex and its is more native number system anyway, so please enable
>> hex numbers.  eg 0xF it might be nice if the factors were in the same base
>> as the input, or if there was a flag to control the output radix...
>
>You might have heard about the Unix Philosophy?
>It is about connecting tools like factor and bc or your shell
>so that we don't have to duplicate base-conversion functionality
>in every tool that accepts an integer input.  Similarly, if you
>require hexadecimal output, use printf %x for small numbers or
>bc/dc/perl/python to convert.

Message #14 received at 11085 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Adam Back <adam <at> cypherspace.org>
Cc: 11085 <at> debbugs.gnu.org
Subject: Re: bug#11085: factor only supports decimal numbers, doh
Date: Tue, 27 Mar 2012 09:44:48 +0200

severity 11085 wishlist
tags 11085 notabug
retitle 11085 RFE: teach factor to read/write hexadecimal
thanks

Adam Back wrote:
> Thanks for replying.  I am aware of bc, dc etc.  And in fact that was what I
> did to work around (used bc), but it seems like unnecessary feature removal
> when the underlying crypto library the tool is calling to actually do the
> work is more natively working with hex (binary).
>
> Sorry about getting off on the wrong foot with the "stupid" word mixed into
> my thought.
>
> I have been using unix exclusively since 1989, and yes I am a fan of the
> unix philosophy.  I would qualify "it is possible to use other tools to work
> around the lack of this feature" to more the tools are scalable,
> conveniently pluggable etc.  And convenient pluggability applies IMO.
>
> Eg lets say od can output in different formats (-tx1 I use commonly if I
> need convert a file into something suitable to chain with some other crypto
> command line tool) ...  you "could" no doubt work around that with awk, perl
> or maybe even bc if you were creative, but it just makes things less
> convenient to chain if the default or only output is not directly
> compatibile with the main consuming next in the chain tools natural, default
> or only input...

You can define a shell function like this to handle the input conversion:

f2(){ factor $( { echo ibase=16\;;echo "$*"|tr a-f A-F|tr -s ' ' \;; } |bc); }

and use it like this:

    $ f2 FF FFF
    255: 3 5 17
    4095: 3 3 5 7 13

Considering that to get the same effect internally (in factor.c),
I would have to change two separate code paths (with/without GMP),
and -- perhaps more importantly -- that yours is the first request
for this feature, your using the simple wrapper is preferable.

And that is considering only the input conversion.
I'm sure you can find or write a tool that parses an arbitrary
stream of integers and converts them from decimal to hexadecimal.
So far, it does not seem justified to add an option for that.

However, if someone is interested enough to write patches, you might
be able to convince us that a hexadecimal input should be accepted
and should cause factors to be printed in hexadecimal.  e.g.,

    $ factor 0xFF 0xFFF
    0xFF: 3 5 11
    0xFFF: 3 3 5 7 C

Then there's no need for a new option.

But realize that this is no trivial task and would require an FSF
copyright assignment.
As usual, the change set would also have to add tests (be sure to
exercise both code paths) and update documentation and NEWS.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.