Earliest date
Felipe Ribeiro
dates and then determines which one is the earliest.
I solved the problem but I think there might be a better way to do it.
Here's the code I wrote:
-------------------------------------------------------------------------------------------------------------
#include <stdio.h>
int main(void)
{
int day, month, year, date;
/*
* Initially earliest needs to be greater than any date, so
initialize
* it with a large value
*/
int earliest = 10000000;
for (;;) {
printf("Enter a date (mm/dd/yy): ");
scanf("%d / %d / %d", &month, &day, &year);
if (month == 0 && day == 0 && year == 0)
break;
/* Put the date into a number, so it's easier to operate on it */
date = year * 10000 + month * 100 + day;
if (date < earliest)
earliest = date;
}
printf("The earliest date is %.2d/%.2d/%.2d\n",
(earliest - ((earliest / 10000) * 10000)) / 100, earliest % 100,
earliest / 10000);
return 0;
}
-------------------------------------------------------------------------------------------------------------
I'd like to know if I could make any changes to improve the program.
Make it clearer or more elegant... I don't know. :)
For example, if I wrote
printf("Enter a date (mm/dd/yy): ");
scanf("%d / %d / %d", &month, &day, &year);
while (month == 0 && day == 0 && year == 0) {
printf("Enter a date (mm/dd/yy): ");
scanf("%d / %d / %d", &month, &day, &year);
...
code
...
}
would it be better than using an infinite loop? Would it improve
anything on performance?
Richard Heathfield
> I have to write a program that asks the user to enter a number of
> dates and then determines which one is the earliest.
> I solved the problem but I think there might be a better way to do
> it. Here's the code I wrote:
>
-------------------------------------------------------------------------------------------------------------
> #include <stdio.h>
>
> int main(void)
> {
> int day, month, year, date;
> /*
> * Initially earliest needs to be greater than any date, so
> initialize
> * it with a large value
> */
> int earliest = 10000000;
How about INT_MAX (which is in <limits.h>)?
> for (;;) {
> printf("Enter a date (mm/dd/yy): ");
> scanf("%d / %d / %d", &month, &day, &year);
Have you tested against inputs such as "April 20, 2009"? How about
1000 1000 1000 ? How would you deal with these?
> if (month == 0 && day == 0 && year == 0)
> break;
>
> /* Put the date into a number, so it's easier to operate on it */
> date = year * 10000 + month * 100 + day;
If the date is not known to be a valid date, this is insufficient.
If the date /is/ known to be valid, this only needs to be:
date = year * 366 + month * 32 + day;
> I'd like to know if I could make any changes to improve the
> program. Make it clearer or more elegant... I don't know. :)
>
> For example, if I wrote
>
> printf("Enter a date (mm/dd/yy): ");
> scanf("%d / %d / %d", &month, &day, &year);
> while (month == 0 && day == 0 && year == 0) {
> printf("Enter a date (mm/dd/yy): ");
> scanf("%d / %d / %d", &month, &day, &year);
How would they finish? There has to be some way for them to let you
know they've stopped entering dates. I had assumed that 0 0 0 was
that way. Now it seems you consider it to be not a sentinel but an
error.
> would it be better than using an infinite loop? Would it improve
> anything on performance?
Performance is not your problem here. Nothing you're doing is going
to take anything like as much time as it takes the user to type in
a date. Your problems here are clarity and robustness. Losing the
infinite loop would, IN MY VIEW, improve clarity, but there are
genuine C experts who disagree with me. Checking the result of
scanf and taking appropriate action if it isn't what you expect
would go some way to improving robustness.
Elegance may have to wait a while.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Felipe Ribeiro
> Felipe Ribeiro said:
>
> > I have to write a program that asks the user to enter a number of
> > dates and then determines which one is the earliest.
> > I solved the problem but I think there might be a better way to do
> > it. Here's the code I wrote:
>
> -------------------------------------------------------------------------------------------------------------
>
> > #include <stdio.h>
>
> > int main(void)
> > {
> > int day, month, year, date;
> > /*
> > * Initially earliest needs to be greater than any date, so
> > initialize
> > * it with a large value
> > */
> > int earliest = 10000000;
>
> How about INT_MAX (which is in <limits.h>)?
I think I should have told that I'm just starting with programming. :)
I'm following K.N. King's book and this problem is in it. The code I
wrote is everything I know so far. :)
>
> > for (;;) {
> > printf("Enter a date (mm/dd/yy): ");
> > scanf("%d / %d / %d", &month, &day, &year);
>
> Have you tested against inputs such as "April 20, 2009"? How about
> 1000 1000 1000 ? How would you deal with these?
I don't really know how to deal with string yet. :)
>
> > if (month == 0 && day == 0 && year == 0)
> > break;
>
> > /* Put the date into a number, so it's easier to operate on it */
> > date = year * 10000 + month * 100 + day;
>
> If the date is not known to be a valid date, this is insufficient.
> If the date /is/ known to be valid, this only needs to be:
>
> date = year * 366 + month * 32 + day;
By using
date = year * 10000 + month * 100 + day;
I have a legal date in the format yymmdd which I later break in parts
to have the date in the format mm/dd/yy. How would I do this with date
= year * 366 + month * 32 + day; ?
>
> > I'd like to know if I could make any changes to improve the
> > program. Make it clearer or more elegant... I don't know. :)
>
> > For example, if I wrote
>
> > printf("Enter a date (mm/dd/yy): ");
> > scanf("%d / %d / %d", &month, &day, &year);
> > while (month == 0 && day == 0 && year == 0) {
> > printf("Enter a date (mm/dd/yy): ");
> > scanf("%d / %d / %d", &month, &day, &year);
>
> How would they finish? There has to be some way for them to let you
> know they've stopped entering dates. I had assumed that 0 0 0 was
> that way. Now it seems you consider it to be not a sentinel but an
> error.
The problem says that the program will finish when the user enters
0/0/0.
The condition should be while (month != 0 || day != 0 || year != 0),
by the way. I know this condition is just ridiculous but I'm just
following the guidelines given by the problem.
Gordon Burditt
>dates and then determines which one is the earliest.
>I solved the problem but I think there might be a better way to do it.
>Here's the code I wrote:
>-------------------------------------------------------------------------------------------------------------
>#include <stdio.h>
>
>int main(void)
>{
> int day, month, year, date;
> /*
> * Initially earliest needs to be greater than any date, so
>initialize
> * it with a large value
> */
> int earliest = 10000000;
An int is not guaranteed to hold a number that large. Try long.
> for (;;) {
> printf("Enter a date (mm/dd/yy): ");
YEARS HAVE 4 DIGITS (at least the recent ones). Then there's
that annoying bit about years BC and future years which end up
with more than 4 digits. Those are dates, too.
> scanf("%d / %d / %d", &month, &day, &year);
Ignoring the return values of your input functions is not a good idea.
What happens when someone enters 31/QUACK?
> if (month == 0 && day == 0 && year == 0)
> break;
Your instructions to the user do not say how to indicate that there
are no more dates to enter. This way of ending input is extremely
non-obvious.
You also don't check dates for validity. You allow things like
2/31/09 or 99/99/-3, to say nothing of the strange stuff involving
Feb. 29.
> /* Put the date into a number, so it's easier to operate on it */
> date = year * 10000 + month * 100 + day;
>
> if (date < earliest)
> earliest = date;
> }
> printf("The earliest date is %.2d/%.2d/%.2d\n",
> (earliest - ((earliest / 10000) * 10000)) / 100, earliest % 100,
> earliest / 10000);
>
> return 0;
>}
>-------------------------------------------------------------------------------------------------------------
>I'd like to know if I could make any changes to improve the program.
>Make it clearer or more elegant... I don't know. :)
>
>For example, if I wrote
>
>printf("Enter a date (mm/dd/yy): ");
>scanf("%d / %d / %d", &month, &day, &year);
>while (month == 0 && day == 0 && year == 0) {
> printf("Enter a date (mm/dd/yy): ");
> scanf("%d / %d / %d", &month, &day, &year);
>...
>code
> ...
>}
>
>would it be better than using an infinite loop? Would it improve
>anything on performance?
Worrying about performance for a program that is mostly keyboard
entry is a lot like worrying about shaving nanoseconds off a plane
trip from the USA to Europe by using aerodynamic design on your car
keys (to make starting the car faster).
Richard Heathfield
<snip>
> I think I should have told that I'm just starting with
> programming. :) I'm following K.N. King's book and this problem is
> in it. The code I wrote is everything I know so far. :)
Okay, fair enough - I'll slow down a bit.
>
>>
>> > for (;;) {
>> > printf("Enter a date (mm/dd/yy): ");
>> > scanf("%d / %d / %d", &month, &day, &year);
>>
>> Have you tested against inputs such as "April 20, 2009"? How
>> about 1000 1000 1000 ? How would you deal with these?
>
> I don't really know how to deal with string yet. :)
No sweat. My point was that your user might enter a string even
though you asked for a number - something many people fail to
handle. But as a beginner, you're allowed not to know how to deal
with that!
Incidentally, scanf returns a useful value - "the number of input
items assigned", as the Standard has it, or EOF in the event of a
complete failure.
<snip>
> By using
> date = year * 10000 + month * 100 + day;
> I have a legal date in the format yymmdd which I later break in
> parts to have the date in the format mm/dd/yy.
Fair point. Forget I said anything.
<snip>
> The problem says that the program will finish when the user enters
> 0/0/0.
> The condition should be while (month != 0 || day != 0 || year !=
> 0), by the way. I know this condition is just ridiculous but I'm
> just following the guidelines given by the problem.
Your solution works, I take it? If so, just move on. This is an
interesting problem insofar as it can be addressed at many levels.
If I needed to solve this myself in a commercial program, almost
certainly I'd be using the time.h data structures and routines, and
I'd be a lot pickier about input - but at the student level you
might as well just say "yep, that works" and go on to the next
exercise.
Han from China
> Felipe Ribeiro said:
>> * Initially earliest needs to be greater than any date, so
>> initialize
>> * it with a large value
>> */
>> int earliest = 10000000;
>
> How about INT_MAX (which is in <limits.h>)?
>
>
>> date = year * 10000 + month * 100 + day;
>
> If the date is not known to be a valid date, this is insufficient.
> If the date /is/ known to be valid, this only needs to be:
>
> date = year * 366 + month * 32 + day;
Both versions fail to take into account the fact that INT_MAX
can be 32767 on a conforming implementation. This point would
be largely academic were those implementations not very
popular.
April 20, 2009 yields
2009 * 366 + 4 * 32 + 20 = 735442
which is well above 32767.
If the date must be in the requested format (mm/dd/yy), we
still have a problem with
99 * 366 + 12 * 32 + 31 = 36649,
which is still above 32767. A whole chunk of other dates
also fail, including every date in the 90s.
Yours,
Han from China
--
"Only entropy comes easy." -- Anton Chekhov
Felipe Ribeiro
wrote:
So it's not a very good idea to treat the date as a number if the
variable storing the number is int?
Richard Heathfield
<snip>
> So it's not a very good idea to treat the date as a number if the
> variable storing the number is int?
The above analysis looks correct to me, and I really should have
spotted that problem myself.
If you use unsigned long int instead, you're good for any year up to
well after after 400,000AD, even if the implementation only uses
the minimum allowed number of bits for the type.
Felipe Ribeiro
Thanks a lot! I'll remember that. :)
The next chapter I'll read is about types. Soon I should be able to
understand it better. :)
blargg
[...]
>>> date = year * 10000 + month * 100 + day;
>> date = year * 366 + month * 32 + day;
>
> Both versions fail to take into account the fact that INT_MAX
> can be 32767 on a conforming implementation. This point would
> be largely academic were those implementations not very
> popular.
Would be? It is, as those implementations AREN'T very popular (or rather,
the architectures that favor them aren't).
Antoninus Twink
> Han from China wrote:
>> Both versions fail to take into account the fact that INT_MAX
>> can be 32767 on a conforming implementation. This point would
>> be largely academic were those implementations not very
>> popular.
>
> Would be? It is, as those implementations AREN'T very popular (or
> rather, the architectures that favor them aren't).
Like it or not, there's no escaping the fact that MS Windows on x86 is
very popular.
Richard Heathfield
Turbo C (INT_MAX 32767) is still widely used in educational
establishments, especially in the third world.
Flash Gordon
They were still popular in the embedded world the last time I checked.
This may have changed.
--
Flash Gordon
CBFalconer
>
> I have to write a program that asks the user to enter a number of
> dates and then determines which one is the earliest. I solved the
> problem but I think there might be a better way to do it.
Simply use ISO standard date format. Make the user enter dates in
that format. Then you can simply sort the strings resulting.
The format is: YYYY-MM-DD
Note the '-' separators, 4 digit year, etc. MM cannot be 00. Nor
can DD.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
blargg
Ahhh, I had forgotten about the really tiny microcontrollers. I was
thinking that most were 32-bit these days, but there are still the 8- and
16-bit ones that are nowadays being programmed on in C (they used to not
be, which is why I had forgotten them). Still, given the difficulty of
eliminating all implicit uses of int, and testing one's code with a
compiler that supports 16-bit ints, there's little to do than require
32-bit int if you're writing programs for PCs. As an example of where one
can accidentally rely on int being more than 16 bits:
unsigned get_le16( unsigned char const in [] )
{
return in[0] | (in[1]<<8);
}
Keith Thompson
> Felipe Ribeiro wrote:
>>
>> I have to write a program that asks the user to enter a number of
>> dates and then determines which one is the earliest. I solved the
>> problem but I think there might be a better way to do it.
>
> Simply use ISO standard date format. Make the user enter dates in
> that format. Then you can simply sort the strings resulting.
>
> The format is: YYYY-MM-DD
>
> Note the '-' separators, 4 digit year, etc. MM cannot be 00. Nor
> can DD.
That's a great idea -- unless you have a requirement to use a
different date format.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Default User
> blargg said:
>
> > Han from China wrote:
> > [...]
> >>>> date = year * 10000 + month * 100 + day;
> > [...]
> >>> date = year * 366 + month * 32 + day;
> >>
> >> Both versions fail to take into account the fact that INT_MAX
> >> can be 32767 on a conforming implementation. This point would
> >> be largely academic were those implementations not very
> >> popular.
> >
> > Would be? It is, as those implementations AREN'T very popular (or
> > rather, the architectures that favor them aren't).
>
> Turbo C (INT_MAX 32767) is still widely used in educational
> establishments, especially in the third world.
I think it had a resurgence in popularity when Borland made if freely
available for a time in their "museum".
I cut my C programming on that Turbo C 2.0 (and its not too friendly
IDE).
Brian
--
Day 77 of the "no grouchy usenet posts" project
Flash Gordon
> Flash Gordon wrote:
>> blargg wrote:
>>> Han from China wrote:
>>> [...]
>>>>>> date = year * 10000 + month * 100 + day;
>>> [...]
>>>>> date = year * 366 + month * 32 + day;
>>>> Both versions fail to take into account the fact that INT_MAX
>>>> can be 32767 on a conforming implementation. This point would
>>>> be largely academic were those implementations not very
>>>> popular.
>>> Would be? It is, as those implementations AREN'T very popular (or rather,
>>> the architectures that favor them aren't).
>> They were still popular in the embedded world the last time I checked.
>> This may have changed.
>
> Ahhh, I had forgotten about the really tiny microcontrollers. I was
> thinking that most were 32-bit these days, but there are still the 8- and
> 16-bit ones that are nowadays being programmed on in C (they used to not
> be, which is why I had forgotten them).
Nowadays going back to before 1995 which, IIRC, is about when I first
programmed a 16 bit DSP in C, and the compiler was at verion 5.something
or 6.something already.
> Still, given the difficulty of
> eliminating all implicit uses of int, and testing one's code with a
> compiler that supports 16-bit ints,
It is not always difficult. In this instance it was easy. In C99 you can
easily request a fast or a small integer type of at least a specific
size to make it even easier.
> there's little to do than require
> 32-bit int if you're writing programs for PCs.
There is a lot more you *can* do, it just might not be worth the effort.
> As an example of where one
> can accidentally rely on int being more than 16 bits:
>
> unsigned get_le16( unsigned char const in [] )
> {
> return in[0] | (in[1]<<8);
> }
Easy to fix though.
--
Flash Gordon
john
Look, for now, worry about clarity and correctness, as these guys
generally emphasize. Also, you need to realize that scanf is not
usually a part of production code, because it gives the
users too much opportunity for entering crazy data. But you must
consider the edge cases: what's your code going to do when you ask
the user to input a small positive integer, and he or she types
"-3.1415926"? What if the entry is "kneedeep?" or 50000000000000? In
your case, 2/31/1918? Would your code cite February thirty-first,
1918, as the earliest date?
And C is pretty flexible; you can use strings with a dash separator in
one part of your code, then print it out with a slash separator. But
don't worry about performance for a long time. Correctness first.
Clarity second.
John
CBFalconer
> CBFalconer <cbfal...@yahoo.com> writes:
>> Felipe Ribeiro wrote:
>>>
>>> I have to write a program that asks the user to enter a number of
>>> dates and then determines which one is the earliest. I solved the
>>> problem but I think there might be a better way to do it.
>>
>> Simply use ISO standard date format. Make the user enter dates in
>> that format. Then you can simply sort the strings resulting.
>>
>> The format is: YYYY-MM-DD
>>
>> Note the '-' separators, 4 digit year, etc. MM cannot be 00. Nor
>> can DD.
>
> That's a great idea -- unless you have a requirement to use a
> different date format.
He spelled out the formula (different) in his input prompt.
Richard Heathfield
> Felipe Ribeiro wrote:
>>
>> I have to write a program that asks the user to enter a number of
>> dates and then determines which one is the earliest. I solved
>> the problem but I think there might be a better way to do it.
>
> Simply use ISO standard date format.
He could do that, but then he wouldn't be answering the problem he
was set. He would instead be answering a different problem. That's
fine, except that it still leaves the original problem unanswered.
<snip>
Kenny McCormack
CBFalconer <cbfal...@maineline.net> wrote lovingly to her gal pal
Keith:
...
>> That's a great idea -- unless you have a requirement to use a
>> different date format.
>
Chick fight!
Gotta love it...
BartC
"Richard Heathfield" <r...@see.sig.invalid> wrote in message
news:BMCdnXEVbIWvznDU...@bt.com...
> CBFalconer said:
>
>> Felipe Ribeiro wrote:
>>>
>>> I have to write a program that asks the user to enter a number of
>>> dates and then determines which one is the earliest. I solved
>>> the problem but I think there might be a better way to do it.
>>
>> Simply use ISO standard date format.
>
> He could do that, but then he wouldn't be answering the problem he
> was set. He would instead be answering a different problem. That's
> fine, except that it still leaves the original problem unanswered.
The problem was to "enter a number of dates", it didn't mention format.
--
Bartc
Richard Heathfield
That's not how I read it, but it's not entirely clear to me and so I
agree that you may have a point. Clearly, the OP can decide for
himself, based on his reading of the spec.
Richard
> Clearly, the OP can decide for
> himself, based on his reading of the spec.
Indeed.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Keith Thompson
We have the OP's summary of the requirements; we don't have the
requirements themselves.
blargg
> blargg wrote:
> > Still, given the difficulty of
> > eliminating all implicit uses of int, and testing one's code with a
> > compiler that supports 16-bit ints,
>
> It is not always difficult. In this instance it was easy. In C99 you can
> easily request a fast or a small integer type of at least a specific
> size to make it even easier.
Except it'll get promoted to int almost anytime you use it. There's not a
very practical way to avoid the promotion (casts clutter things quickly).
> > there's little to do than require
> > 32-bit int if you're writing programs for PCs.
>
> There is a lot more you *can* do, it just might not be worth the effort.
The point is that it's not easy to systematically find every place where
you depend on int being more than 16 bits, or be sure the code will work
with 16-bit int (except for trivially short code).
Felipe Ribeiro
The problem requires that the date be entered using the format mm/dd/
yy.
Kenny McCormack
Richard <rgr...@gmail.com> wrote:
>Richard Heathfield <r...@see.sig.invalid> writes:
>
>> Clearly, the OP can decide for
>> himself, based on his reading of the spec.
>
>Indeed.
Quite.
>"Avoid hyperbole at all costs, its the most destructive argument on
>the planet" - Mark McIntyre in comp.lang.c
Absolutely!
BartC
> On Apr 21, 6:31 am, "BartC" <ba...@freeuk.com> wrote:
>> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
>>
>> news:BMCdnXEVbIWvznDU...@bt.com...
>>
>>> CBFalconer said:
>>>> Simply use ISO standard date format.
>>
>>> He could do that, but then he wouldn't be answering the problem he
>>> was set. He would instead be answering a different problem. That's
>>> fine, except that it still leaves the original problem unanswered.
>>
>> The problem was to "enter a number of dates", it didn't mention
>> format.
> The problem requires that the date be entered using the format mm/dd/
> yy.
OK. In that case you might be able to just rearrange (as text) into
yyyymmdd. Maybe even compare using strcmp().
But that also introduces an ambiguity when using yy instead of yyyy which I
don't think was addressed in the posts I saw.
For example, is year 97 earlier or later than 07? You have to determine
whether the user intended 19xx or 20xx.
--
Bartc
Richard
You know he wasn't being amusing or funny when he wrote that? Such is
his own self regard. Dwarfed only by Chuck's huge ego which stalks the
corridors of c.l.c hoping to trap a fawning Noob and make them shake
with fear. I had an Electronics teacher like that. Myself and another
student made a pact never to pay any attention to what he said in class
and did our own notes from reputed textbooks. We both got As. Chuck kind
of reminds me him - all bullshit, self regard and failing memories of
past glories and epic achievements, myopic and totally unable to read
the public's reactions to their bumbling incompetence.
--
Richard Heathfield
> On Apr 21, 6:31 am, "BartC" <ba...@freeuk.com> wrote:
>> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
>>
>> news:BMCdnXEVbIWvznDU...@bt.com...
>>
>> > CBFalconer said:
>>
>> >> Felipe Ribeiro wrote:
>>
>> >>> I have to write a program that asks the user to enter a
>> >>> number of dates and then determines which one is the
>> >>> earliest. I solved the problem but I think there might be a
>> >>> better way to do it.
>>
>> >> Simply use ISO standard date format.
>>
>> > He could do that, but then he wouldn't be answering the problem
>> > he was set. He would instead be answering a different problem.
>> > That's fine, except that it still leaves the original problem
>> > unanswered.
>>
>> The problem was to "enter a number of dates", it didn't mention
>> format.
>
> The problem requires that the date be entered using the format
> mm/dd/ yy.
Thanks for confirming. I rest my case.
Kenny McCormack
Richard <rgr...@gmail.com> wrote:
...
>>>"Avoid hyperbole at all costs, its the most destructive argument on
>>>the planet" - Mark McIntyre in comp.lang.c
>>
>> Absolutely!
>>
>
>You know he wasn't being amusing or funny when he wrote that?
Actually, McIntyre/Ambuhl is/are amusing and funny in whatever they write.
It may not be intended as such, but such is the effect. Their posts never
fail to amuse me.
>Such is his own self regard. Dwarfed only by Chuck's huge ego which
>stalks the corridors of c.l.c hoping to trap a fawning Noob and make
>them shake with fear. I had an Electronics teacher like that. Myself
>and another student made a pact never to pay any attention to what he
>said in class and did our own notes from reputed textbooks. We both got
>As. Chuck kind of reminds me him - all bullshit, self regard and
>failing memories of past glories and epic achievements, myopic and
>totally unable to read the public's reactions to their bumbling
>incompetence.
Good story. So apt.
Flash Gordon
> Flash Gordon wrote:
>> blargg wrote:
> [...]
>>> Still, given the difficulty of
>>> eliminating all implicit uses of int, and testing one's code with a
>>> compiler that supports 16-bit ints,
>> It is not always difficult. In this instance it was easy. In C99 you can
>> easily request a fast or a small integer type of at least a specific
>> size to make it even easier.
>
> Except it'll get promoted to int almost anytime you use it. There's not a
> very practical way to avoid the promotion (casts clutter things quickly).
You were talking about code which assumed that int was larger than it
actually is. I.e. int is 16 bits but the code assumes it is 32 bits. So
promoting to int is not a problem here.
>>> there's little to do than require
>>> 32-bit int if you're writing programs for PCs.
>> There is a lot more you *can* do, it just might not be worth the effort.
>
> The point is that it's not easy to systematically find every place where
> you depend on int being more than 16 bits, or be sure the code will work
> with 16-bit int (except for trivially short code).
s/int/int_least32_t/
If you don't know sed, that means replace all instances of int with
int_least32_t. Obviously you also need to include stdint.h or
inttypes.h, and deal with your format specifiers for *printf and *scanf,
but a bit of searching with decent search tools should find most of
those (where the format specifier is data, possibly user entered, you
still have a problem, but that is not the case for a lot of SW).
It may not be neat or what you would like, but it is eminently doable.
As I say, it may well not be worth the effort. If you are targetting
personal computers and are explicitly not concerned with obsolete
implementations for personal computers, then you are fairly safe
assuming that int is at least 32 bits. In which case it may well not be
worth considering smaller systems.
--
Flash Gordon
CBFalconer
> Flash Gordon wrote:
>
>
>> There is a lot more you *can* do, it just might not be worth the
>> effort.
>
> The point is that it's not easy to systematically find every place
> where you depend on int being more than 16 bits, or be sure the
> code will work with 16-bit int (except for trivially short code).
Yes, it is usually easy. Just get and mount Turbo-C v 2.0 (I
think), available from Borland, free. Compile your code on it. If
it compiles and runs, it is suitable for 16 bit operation. TC is
very close to being ISO compliant - the differences are minor. Set
TC to compile standard code.
CBFalconer
> CBFalconer said:
>> Felipe Ribeiro wrote:
>>>
>>> I have to write a program that asks the user to enter a number of
>>> dates and then determines which one is the earliest. I solved
>>> the problem but I think there might be a better way to do it.
>>
>> Simply use ISO standard date format.
>
> He could do that, but then he wouldn't be answering the problem he
> was set. He would instead be answering a different problem. That's
> fine, except that it still leaves the original problem unanswered.
As usual, you didn't bother to read the original, but just went off
beating your gums about nothing. If you bother to look you will
see that Mr. Ribeiro put his own input date format into his code.
He did not try to convert something that he had been supplied. So
he can easily use ISO format, ease his problem, learn something,
etc.
Again, I suggest less silly meandering, and do try to grow up.
Richard Heathfield
> Richard Heathfield wrote:
>> CBFalconer said:
>>> Felipe Ribeiro wrote:
>>>>
>>>> I have to write a program that asks the user to enter a number
>>>> of
>>>> dates and then determines which one is the earliest. I solved
>>>> the problem but I think there might be a better way to do it.
>>>
>>> Simply use ISO standard date format.
>>
>> He could do that, but then he wouldn't be answering the problem
>> he was set. He would instead be answering a different problem.
>> That's fine, except that it still leaves the original problem
>> unanswered.
>
> As usual, you didn't bother to read the original, but just went
> off beating your gums about nothing. If you bother to look you
> will see that Mr. Ribeiro put his own input date format into his
> code. He did not try to convert something that he had been
> supplied. So he can easily use ISO format, ease his problem,
> learn something, etc.
Read the thread. Mr Ribeiro has already clarified that he is working
under precisely the constraint that I suggested.
> Again, I suggest less silly meandering, and do try to grow up.
You mean "stop pointing out Chuck's errors"?
Keith Thompson
> Richard Heathfield wrote:
>> CBFalconer said:
>>> Felipe Ribeiro wrote:
>>>>
>>>> I have to write a program that asks the user to enter a number of
>>>> dates and then determines which one is the earliest. I solved
>>>> the problem but I think there might be a better way to do it.
>>>
>>> Simply use ISO standard date format.
>>
>> He could do that, but then he wouldn't be answering the problem he
>> was set. He would instead be answering a different problem. That's
>> fine, except that it still leaves the original problem unanswered.
>
> Mr. Ribeiro put his own input date format into his code. He did not
> try to convert something that he had been supplied. So he can
> easily use ISO format, ease his problem, learn something, etc.
http://groups.google.com/group/comp.lang.c/msg/8d66a5bec1fb2c6a
Message-ID: <c149c6af-c40b-4e8f...@s16g2000vbp.googlegroups.com>
| The problem requires that the date be entered using the format mm/dd/
| yy.
If you were to suggest converting the mm/dd/yy input to yyyy-mm-dd
internally, that might be a sensible approach -- though IMHO it's more
work than is necessary. If it's only used internally, you might as
well use just yyyymmdd -- and in that case, you might as well just use
an integer (as long as it's sufficiently large) rather than a string.
Richard
> CBFalconer said:
>
>> Richard Heathfield wrote:
>>> CBFalconer said:
>>>> Felipe Ribeiro wrote:
>>>>>
>>>>> I have to write a program that asks the user to enter a number
>>>>> of
>>>>> dates and then determines which one is the earliest. I solved
>>>>> the problem but I think there might be a better way to do it.
>>>>
>>>> Simply use ISO standard date format.
>>>
>>> He could do that, but then he wouldn't be answering the problem
>>> he was set. He would instead be answering a different problem.
>>> That's fine, except that it still leaves the original problem
>>> unanswered.
>>
>> As usual, you didn't bother to read the original, but just went
>> off beating your gums about nothing. If you bother to look you
>> will see that Mr. Ribeiro put his own input date format into his
>> code. He did not try to convert something that he had been
>> supplied. So he can easily use ISO format, ease his problem,
>> learn something, etc.
>
> Read the thread. Mr Ribeiro has already clarified that he is working
> under precisely the constraint that I suggested.
>
>> Again, I suggest less silly meandering, and do try to grow up.
>
> You mean "stop pointing out Chuck's errors"?
Poor Chuck. Years of fawning only to be dealt a back hander from one of
God's own. I almost feel sympathy for the arrogant arsehole.
--
James Kuyper
> blargg wrote:
>> Flash Gordon wrote:
>>
> ... snip ...
>>> There is a lot more you *can* do, it just might not be worth the
>>> effort.
>> The point is that it's not easy to systematically find every place
>> where you depend on int being more than 16 bits, or be sure the
>> code will work with 16-bit int (except for trivially short code).
>
> Yes, it is usually easy. Just get and mount Turbo-C v 2.0 (I
> think), available from Borland, free. Compile your code on it. If
> it compiles and runs, it is suitable for 16 bit operation. TC is
> very close to being ISO compliant - the differences are minor. Set
> TC to compile standard code.
Turbo C will warn me when I write code that contains no syntax errors,
no constraint violations, no undefined behavior, but behaves differently
depending upon whether int is 16 bits or a larger size? It can tell
whether or not I intended it to behave differently? How does it manage that?
CBFalconer
> CBFalconer wrote:
>> blargg wrote:
>>
... snip ...
>>
>>> The point is that it's not easy to systematically find every
>>> place where you depend on int being more than 16 bits, or be
>>> sure the code will work with 16-bit int (except for trivially
>>> short code).
>>
>> Yes, it is usually easy. Just get and mount Turbo-C v 2.0 (I
>> think), available from Borland, free. Compile your code on it.
>> If it compiles and runs, it is suitable for 16 bit operation.
>> TC is very close to being ISO compliant - the differences are
>> minor. Set TC to compile standard code.
>
> Turbo C will warn me when I write code that contains no syntax
> errors, no constraint violations, no undefined behavior, but
> behaves differently depending upon whether int is 16 bits or a
> larger size? It can tell whether or not I intended it to behave
> differently? How does it manage that?
If it needs larger integers it probably won't run correctly. Note
the word 'run'. If you read in values to a long and compare them
to INT_MAX you will probably detect some of the errors early.
James Dow Allen
> Simply use ISO standard date format. Make the user enter dates in
> that format. Then you can simply sort the strings resulting.
>
> The format is: YYYY-MM-DD
Great minds think alike! This is the format I used
in my binary-seconds to date-string converter 40 years ago.
Actually used YYYY/MM/DD HH:MM:SS
Didn't need to write the cumbersome inverse function!
Just did binary search, calling the to-string function
and strcmp(). (Uh... actually used CLC, not strcmp().
C didn't exist then.)
James
James Kuyper
> James Kuyper wrote:
>> CBFalconer wrote:
>>> blargg wrote:
>>>
> ... snip ...
>>>> The point is that it's not easy to systematically find every
>>>> place where you depend on int being more than 16 bits, or be
>>>> sure the code will work with 16-bit int (except for trivially
>>>> short code).
>>> Yes, it is usually easy. Just get and mount Turbo-C v 2.0 (I
>>> think), available from Borland, free. Compile your code on it.
>>> If it compiles and runs, it is suitable for 16 bit operation.
>>> TC is very close to being ISO compliant - the differences are
>>> minor. Set TC to compile standard code.
>> Turbo C will warn me when I write code that contains no syntax
>> errors, no constraint violations, no undefined behavior, but
>> behaves differently depending upon whether int is 16 bits or a
>> larger size? It can tell whether or not I intended it to behave
>> differently? How does it manage that?
>
> If it needs larger integers it probably won't run correctly. Note
> the word 'run'. If you read in values to a long and compare them
> to INT_MAX you will probably detect some of the errors early.
You only said "run", you didn't specify "correctly". In order for the
fact that it runs correctly to provide any reasonable assurance, it
would have to not merely run correctly once, but many different times,
with different inputs carefully chosen to test out all the paths through
the program. Even then, such testing can only suggest that the code does
not depend upon int being more than 16 bits; it can't guarantee the
there isn't some case so obscure that you didn't think to test it, for
which the program runs incorrectly.
James Kuyper
> On Apr 21, 5:47 am, CBFalconer <cbfalco...@yahoo.com> wrote:
>> Simply use ISO standard date format. Make the user enter dates in
>> that format. Then you can simply sort the strings resulting.
>>
>> The format is: YYYY-MM-DD
>
> Great minds think alike! This is the format I used
> in my binary-seconds to date-string converter 40 years ago.
> Actually used YYYY/MM/DD HH:MM:SS
Great minds might think alike, but apparently not identically. ISO 8601
mandates a 'T' rather than a space character between the date and the
time fields. Also, it mandates '-' rather than '/' as delimiters for the
month portion.
The reason it does this is that ISO 8601 reserves '/' for use in time
intervals. For instance, 2009-03-15T15/04-27T12 identifies the time
interval from 2009-03-15T15:00:00 to 2009-04-27T12:00:00.
Richard Bos
> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> > He could do that, but then he wouldn't be answering the problem he
> > was set. He would instead be answering a different problem. That's
> > fine, except that it still leaves the original problem unanswered.
>
> The problem was to "enter a number of dates", it didn't mention format.
All the same, he probably has to use the braindead USAlien date format
for reasons of teacher (and population) idiocy.
Richard
blargg
Where "paths" is more than just execution, but execution of the
calculations with multiple values that test both (or more) limits of each
one.
I used to write code that would work with 16-bit ints, and that involved
using long a lot, and plenty of casts to long for multiplications of
16-bit values that could exceed 16 bits. Since I've given up on supporting
16-bit ints, my code has gotten clearer and has fewer casts; I can just
use int virtually all the time and have it work.
CBFalconer
>
... snip about using 16 bit ints ...
>
> I used to write code that would work with 16-bit ints, and that
> involved using long a lot, and plenty of casts to long for
> multiplications of 16-bit values that could exceed 16 bits. Since
> I've given up on supporting 16-bit ints, my code has gotten
> clearer and has fewer casts; I can just use int virtually all the
> time and have it work.
Casts should have been very rare. They are usually mistakes
anyhow. Correctly typing the actual objects should cover almost
everything, except variadic functions.