Dealing with a large integer

[yong]

Hi all

I have an large integer in this format
x1*256^5 + x2*256^4 + x3*256^3 + x4*256^2 + x5*256 + x6
now I must convert it to this format
y1*900^4 + y2*900^3 + y3*900^2 + y4*900 + y5

x1-x5 is given.I must get y1-y4 from it.

How can I do this on my 32bit PC?

Sorry for that my English is poor.

Thanks.

[Jordan Abel]

On 2006-03-06, en******@yahoo. com <en******@yahoo .com> wrote:

Jordan Abel wrote:

On 2006-03-05, en******@yahoo. com <en******@yahoo .com> wrote:

>
> CBFalconer wrote:
>> Actually, under C99, if the underlying hardware has such objects
>> the implementation must then support them. Otherwise they can be
>> omitted.
>
> If you read the relevant paragraph in the standard,
> you'll see that it doesn't say anything about the
> underlying hardware. It's perfectly legal for an
> implementation to have 8 bit chars, 16 bit shorts,
> and 64 bit ints, longs and long longs, and not define
> int32_t, regardless of what hardware it's running on.

I think his claim is that the types have to be available if the relevant
standard types are twos-complement and have no padding. I don't know if
that's true or not. "hardware" is just a shorthand for "whatever the
'native' types are implemented on."

If that's the claim that was intended then someone needs
a lesson in writing for clarity.

I find it more likely that your reading is simply overly
charitable. There was no mention, for example, of twos
complement in the original message.

It's implied in "such objects".

[ena8t8si]

Jordan Abel wrote:

On 2006-03-06, en******@yahoo. com <en******@yahoo .com> wrote:

Jordan Abel wrote:

On 2006-03-05, en******@yahoo. com <en******@yahoo .com> wrote:
>
> CBFalconer wrote:
>> Actually, under C99, if the underlying hardware has such objects
>> the implementation must then support them. Otherwise they can be
>> omitted.
>
> If you read the relevant paragraph in the standard,
> you'll see that it doesn't say anything about the
> underlying hardware. It's perfectly legal for an
> implementation to have 8 bit chars, 16 bit shorts,
> and 64 bit ints, longs and long longs, and not define
> int32_t, regardless of what hardware it's running on.

I think his claim is that the types have to be available if the relevant
standard types are twos-complement and have no padding. I don't know if
that's true or not. "hardware" is just a shorthand for "whatever the
'native' types are implemented on."

If that's the claim that was intended then someone needs
a lesson in writing for clarity.

I find it more likely that your reading is simply overly
charitable. There was no mention, for example, of twos
complement in the original message.

It's implied in "such objects".

Only to someone who already knows what the Standard
says, since twos complement isn't mentioned in any
message in the thread before yours. Obviously, someone
who is writing to explain what the standard says is
assuming that his audience doesn't already know what
it says, otherwise there's no point in explaining it.

[Mark McIntyre]

On 6 Mar 2006 04:52:50 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmai l.com> wrote:

On 2006-03-06, James Dow Allen <jd*********@ya hoo.com> wrote:

The gets() which I defended gots'ed a string which my own software
had printf'ed. Got it?

How did you guarantee this? There is no mechanism in the standard to
ensure that this happens.

Of course there isn't.

But there's also nothing in the standard that ensures that
fflush(stdout) won't explode a nuclear device. It requires it to clear
the buffer, nothing more. Evaporating the installation would achieve
this handily.

Hyperbole aside, my point is that any part of the standard that
interacts with the outside world is open to abuse. Careful programming
and careful use prevent that, nothing more.

For what its worth I agree, gets() is overly dangerous and it'd be
nice if it were gone. I disagree that its impossible to safely use it.
Its just excessively hard.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Jordan Abel]

On 2006-03-06, Mark McIntyre <ma**********@s pamcop.net> wrote:

On 6 Mar 2006 04:52:50 GMT, in comp.lang.c , Jordan Abel
<ra*******@gmai l.com> wrote:

On 2006-03-06, James Dow Allen <jd*********@ya hoo.com> wrote:

The gets() which I defended gots'ed a string which my own software
had printf'ed. Got it?

How did you guarantee this? There is no mechanism in the standard to
ensure that this happens.

Of course there isn't.

But there's also nothing in the standard that ensures that
fflush(stdout) won't explode a nuclear device. It requires it to clear
the buffer, nothing more. Evaporating the installation would achieve
this handily.

Hyperbole aside, my point is that any part of the standard that
interacts with the outside world is open to abuse. Careful programming
and careful use prevent that, nothing more.

For what its worth I agree, gets() is overly dangerous and it'd be
nice if it were gone. I disagree that its impossible to safely use it.
Its just excessively hard.
Mark McIntyre

Post code that you think safely uses gets and i'll prove it wrong within
the context of the API you are using to "ensure" it. [well, i'm hoping
you're using the unix api, since i wouldn't have the first clue about
any other one]

[Walter Roberson]

In article <sl************ ***********@ran dom.yi.org>,
Jordan Abel <ra*******@gmai l.com> wrote:

Post code that you think safely uses gets and i'll prove it wrong within
the context of the API you are using to "ensure" it. [well, i'm hoping
you're using the unix api, since i wouldn't have the first clue about
any other one]

How about something like this:

Open a file w+. Write known data into it. fseek() back to the
beginning of the file. gets() with a buffer at least as big as
the data to be written.

Within standard C, there is nothing that could sneak in and change
the file contents "underneath you". Unix has multiprocessing
and another Unix process could change the file, but that's not the
fault of standard C. And besides, you could run this on a system
that did not offer multiple processes. (Now, if you start going
in and bashing The One True Process with a debugger, clearly C
would not be able to offer any guarantees of anything at all.)
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

[Ben Pfaff]

ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson) writes:

In article <sl************ ***********@ran dom.yi.org>,
Jordan Abel <ra*******@gmai l.com> wrote:

Post code that you think safely uses gets and i'll prove it wrong within
the context of the API you are using to "ensure" it. [well, i'm hoping
you're using the unix api, since i wouldn't have the first clue about
any other one]

How about something like this:

Open a file w+. Write known data into it. fseek() back to the
beginning of the file. gets() with a buffer at least as big as
the data to be written.

gets() reads from stdin. You'll have to use freopen() to replace
stdin by your file. Seems like a pretty big stretch to make just
to use gets() safely, when you could just use a better designed
function instead.
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Jordan Abel]

On 2006-03-06, Ben Pfaff <bl*@cs.stanfor d.edu> wrote:

ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson) writes:

In article <sl************ ***********@ran dom.yi.org>,
Jordan Abel <ra*******@gmai l.com> wrote:

Post code that you think safely uses gets and i'll prove it wrong within
the context of the API you are using to "ensure" it. [well, i'm hoping
you're using the unix api, since i wouldn't have the first clue about
any other one]

How about something like this:

Open a file w+. Write known data into it. fseek() back to the
beginning of the file. gets() with a buffer at least as big as
the data to be written.

gets() reads from stdin. You'll have to use freopen() to replace
stdin by your file. Seems like a pretty big stretch to make just
to use gets() safely, when you could just use a better designed
function instead.

Is it even permissible to change the mode of stdin?

[Walter Roberson]

In article <87************ @benpfaff.org>,
Ben Pfaff <bl*@cs.stanfor d.edu> wrote:

gets() reads from stdin. You'll have to use freopen() to replace
stdin by your file.
True.
Seems like a pretty big stretch to make just
to use gets() safely, when you could just use a better designed
function instead.

Mark's claim is that there exists at least one standards-compliant
system under which at least one standards-complaint program can safely
use gets().

Jordan's claim appears to be that gets() is unsafe for every *possible*
standards-compliant program on every *possible* standards-compliant
environment.

Mark doesn't claim that gets() is safe in every environment or
every program; nor does he claim that the safe program could be
written in (say) less than a million lines of code -- just that
at least one such safe program + environment combination exists.

So... if the safe program involves freopen() on stdin and requires
a single-user mono-tasking environment, then so be it: if it can
be done *at all* then Mark would be right. Mark did say that
it was "excessivel y hard" to do...
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[Walter Roberson]

In article <sl************ ***********@ran dom.yi.org>,
Jordan Abel <ra*******@gmai l.com> wrote:

On 2006-03-06, Ben Pfaff <bl*@cs.stanfor d.edu> wrote:

gets() reads from stdin. You'll have to use freopen() to replace
stdin by your file.

Is it even permissible to change the mode of stdin?

C89 does not have an prohibition against it in the description
of freopen(); it might somewhere else, perhaps.

But in this connection, the footnote is informative:

116. The primary use of the freopen function is to change the
file associated with a standard text stream (stderr, stdin,
or stdout), as those identifiers need not be modifiable lvalues
to which the value returned by the fopen function may be assigned.
I would interpret that as being supportive of changing the mode
as well as the association, in that it talks about providing a
mechanism to essentially assign new values to those predefined
identifiers -- and if one *could* just write to those identifiers
(if they were lvalues) then one could put in a stream of a
different mode.

Of course, my interpretation is not to be considered "proof" ;-)

--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell

[Jordan Abel]

On 2006-03-06, Walter Roberson <ro******@ibd.n rc-cnrc.gc.ca> wrote:

In article <sl************ ***********@ran dom.yi.org>,
Jordan Abel <ra*******@gmai l.com> wrote:

On 2006-03-06, Ben Pfaff <bl*@cs.stanfor d.edu> wrote:

gets() reads from stdin. You'll have to use freopen() to replace
stdin by your file.

Is it even permissible to change the mode of stdin?

C89 does not have an prohibition against it in the description
of freopen(); it might somewhere else, perhaps.

But in this connection, the footnote is informative:

116. The primary use of the freopen function is to change the
file associated with a standard text stream (stderr, stdin,
or stdout), as those identifiers need not be modifiable lvalues
to which the value returned by the fopen function may be assigned.
I would interpret that as being supportive of changing the mode
as well as the association, in that it talks about providing a
mechanism to essentially assign new values to those predefined
identifiers -- and if one *could* just write to those identifiers
(if they were lvalues) then one could put in a stream of a
different mode.

Of course, my interpretation is not to be considered "proof" ;-)

My interpretation is the opposite - that it's intended to change stdin
to be _another file_ open in read mode, or stdout/stderr to another file
open in write mode.

It's also possible that on some systems extra magic may be needed to
make a re-opened stdout become the standard output of a command executed
via system(), or even for a re-opened stream to become the standard
stream used by functions not implemented in standard C such as perror().
It also might be desirable for the buffering state of a stream to be
retained in some cases. For example, there is a good reason why stderr
is not fully buffered at program start. (It's unclear to me whether
freopen can even change the buffering state at all - though it could be
desirable to do so when changing stdout to be a regular file when it was
an interactive device at program startup)