Significance of 2020 / 2021 date

Post by issinoho
We have some old 90s VAX C code which rejects any dates after the year 2020 so, as you can imagine this has now kicked in. The system was ported from VAX to IA64 years ago and we've only just discovered this.
Question: is there any inherent architectural or numerical significance behind this, or was this simply 'a date a long time away' when it was coded?
Your wisdom, as always, is appreciated.
TIA

Cute!

My guess is some application code trying to be 'helpful' thinking it is preventing bad date data entry.
Did it start 2021/1/1 ?
What is the failing behaviour?
Some nice error message? System-ish language or native application style message?
Some 'service failed code xyz'

I'm not aware of any numbers running out, rolling over, or similar involving 2021
The world in general has not made observations either -

https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2021

fwiw,
Hein

Andy Burns

2021-01-07 17:33:53 UTC

Post by issinoho
We have some old 90s VAX C code which rejects any dates after the year 2020

Does this use 2 digit years or 4 digit?

Some systems use "date windowing" and assume e.g. yy below 20 means 19yy
otherwise it means 20yy.

Simon Clubley

2021-01-07 18:39:59 UTC

Post by issinoho
We have some old 90s VAX C code which rejects any dates after the year 2020

Does this use 2 digit years or 4 digit?
Some systems use "date windowing" and assume e.g. yy below 20 means 19yy
otherwise it means 20yy.

That's exactly what I thought when I saw the date but I would have
expected the check to be for less than 1-Jan-2020 instead of 1-Jan-2021
unless someone decided to be different.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Stephen Hoffman

2021-01-07 18:51:13 UTC

Post by Simon Clubley

Post by issinoho
We have some old 90s VAX C code which rejects any dates after the year 2020

Does this use 2 digit years or 4 digit?
Some systems use "date windowing" and assume e.g. yy below 20 means
19yy otherwise it means 20yy.

That's exactly what I thought when I saw the date but I would have
expected the check to be for less than 1-Jan-2020 instead of 1-Jan-2021
unless someone decided to be different.

Lots of possibilities.

Have a look at the C code.

Or have somebody look at the C code on your behalf.

Non-leap-year years that begin on Thursday and leap-year years that
begin on Wednesday have 53 weeks.

Which can snarl some applications.

2020 was one such year; with 53 weeks.

Wouldn't be surprised if that triggered a fault somewhere in week-based code.

Migrating from K&R to ANSI C and fixing diagnostics has stabilized a
whole lot of sketchy old apps, too.

--
Pure Personal Opinion | HoffmanLabs LLC

Hein RMS van den Heuvel

2021-01-07 18:40:56 UTC

Post by issinoho
We have some old 90s VAX C code which rejects any dates after the year 2020

Does this use 2 digit years or 4 digit?
Some systems use "date windowing" and assume e.g. yy below 20 means 19yy
otherwise it means 20yy.

Ah yes, I've seen those - OpenVMS has it!

nitpicking - year XX below 20 would 20xx, and above it would be 19xx

Hein

Stephen Hoffman

2021-01-07 18:52:32 UTC

Post by Hein RMS van den Heuvel

Post by issinoho
We have some old 90s VAX C code which rejects any dates after the year 2020

Does this use 2 digit years or 4 digit?
Some systems use "date windowing" and assume e.g. yy below 20 means
19yy otherwise it means 20yy.

Ah yes, I've seen those - OpenVMS has it!
nitpicking - year XX below 20 would 20xx, and above it would be 19xx

The OpenVMS pivot year is 57.

Which also happens to be the year DEC was founded.

--
Pure Personal Opinion | HoffmanLabs LLC

1tim....@gmail.com

2021-01-07 20:38:16 UTC

Post by Hein RMS van den Heuvel

Post by Stephen Hoffman

Post by issinoho
We have some old 90s VAX C code which rejects any dates after the year 2020

Does this use 2 digit years or 4 digit?
Some systems use "date windowing" and assume e.g. yy below 20 means
19yy otherwise it means 20yy.

Ah yes, I've seen those - OpenVMS has it!
nitpicking - year XX below 20 would 20xx, and above it would be 19xx

The OpenVMS pivot year is 57.
Which also happens to be the year DEC was founded.
--
Pure Personal Opinion | HoffmanLabs LLC

am I the only one that saw 2020 as two spaces in hex? (I've been at this too long)

abrsvc

2021-01-07 20:48:50 UTC

Post by issinoho
We have some old 90s VAX C code which rejects any dates after the year 2020

Does this use 2 digit years or 4 digit?

Without seeing any of the code, we can speculate till the cows come home and never uncover the real problem. I too have seen all kinds of trickery to get around 2 digit year storage and the change from 19 to 20. Given that the century remained the same here, I suspect a different issue.

There are many of us here (myself included) that can provide assistance in tracking this down. Just because the code is old does not mean anything. I am working with code now that was last modified in 1988 and is still running fine. Other code written recently has issues (go figure...)

Dan

issinoho

2021-01-07 21:00:24 UTC

Post by issinoho
We have some old 90s VAX C code which rejects any dates after the year 2020

Does this use 2 digit years or 4 digit?

Without seeing any of the code, we can speculate till the cows come home and never uncover the real problem. I too have seen all kinds of trickery to get around 2 digit year storage and the change from 19 to 20. Given that the century remained the same here, I suspect a different issue.
There are many of us here (myself included) that can provide assistance in tracking this down. Just because the code is old does not mean anything. I am working with code now that was last modified in 1988 and is still running fine. Other code written recently has issues (go figure...)
Dan

OK, so the very fact none of you are jumping down my throat with an obvious reason is significant.

For the curious here is the code in question...

if (atoi (date_string + 5) > 2020)
....

where date_string is a char array

Thanks for the continued support.

Arne Vajhøj

2021-01-07 21:06:33 UTC

Post by issinoho
We have some old 90s VAX C code which rejects any dates after the year 2020

Does this use 2 digit years or 4 digit?

OK, so the very fact none of you are jumping down my throat with an obvious reason is significant.
For the curious here is the code in question...
if (atoi (date_string + 5) > 2020)
....
where date_string is a char array

Well - that code seems to intend to change the flow
when going from 2020 to 2021.

So maybe not so surprising that behavior changed.

And next step must be to look at the code that now
get executed which did not get executed before.

Arne

abrsvc

2021-01-07 21:12:12 UTC

Post by issinoho
For the curious here is the code in question...
if (atoi (date_string + 5) > 2020)
....
where date_string is a char array

Well - that code seems to intend to change the flow
when going from 2020 to 2021.
So maybe not so surprising that behavior changed.
And next step must be to look at the code that now
get executed which did not get executed before.
Arne

The code provided shows the path taken and is not the code that failed. As Arne indicated, you need to check the code that is the target of the if statement. Clearly prior to this year, that code was skipped as it was not within the section of the IF that was true. Post that code along with any relevant declarations and we may be able to assist. Otherwise, send along a private message with connection information and we may be able to help further with a direct connection and a mirrored terminal session via Teams or Zoom.

Dan

Chris

2021-01-09 12:15:05 UTC

Post by issinoho

Post by issinoho
We have some old 90s VAX C code which rejects any dates after the year 2020

Does this use 2 digit years or 4 digit?

Without seeing any of the code, we can speculate till the cows come home and never uncover the real problem. I too have seen all kinds of trickery to get around 2 digit year storage and the change from 19 to 20. Given that the century remained the same here, I suspect a different issue.
There are many of us here (myself included) that can provide assistance in tracking this down. Just because the code is old does not mean anything. I am working with code now that was last modified in 1988 and is still running fine. Other code written recently has issues (go figure...)
Dan

OK, so the very fact none of you are jumping down my throat with an obvious reason is significant.
For the curious here is the code in question...
if (atoi (date_string + 5)> 2020)

That code is type unsafe for starters. atoi() requires an ascii string,
but you are trying to add 5 decimal to an ascii string ?. The man
page for atoi() quite clearly states that behaviour is undefined if
you give it bad data. Just yet another example of sloppy programming.
Be fussy about types etc !.

Better to use a later library function, such as strtoul (), or similar,
which is more tightly defined...

Chris

Post by issinoho
....
where date_string is a char array
Thanks for the continued support.

Andy Burns

2021-01-09 12:35:36 UTC

if (atoi (date_string + 5)> 2020)

That code is type unsafe for starters. atoi() requires an ascii string,
but you are trying to add 5 decimal to an ascii string ?.

atoi requires a *pointer* to an asciiz string, presumably in this case
the format is something like DDMMMYYYY, so that the +5 starts the
decimal conversion from the address of the first Y.

Chris

2021-01-09 12:50:11 UTC

Post by issinoho
if (atoi (date_string + 5)> 2020)

That code is type unsafe for starters. atoi() requires an ascii string,
but you are trying to add 5 decimal to an ascii string ?.

atoi requires a *pointer* to an asciiz string, presumably in this case
the format is something like DDMMMYYYY, so that the +5 starts the
decimal conversion from the address of the first Y.

Ok, but I would not be doing pointer arithmetic inside an ancient
library function such as atoi(). Expecting the compiler to a be a
mindreader etc.

Ideally, you get the user input, parse it to verify correct format and
only then, pass the year field to the conversion routine. Only a few
lines of added code needed to do it right.

Chris

Andy Burns

2021-01-09 12:55:38 UTC

Post by Chris
Ideally, you get the user input, parse it to verify correct format and
only then, pass the year field to the conversion routine. Only a few
lines of added code needed to do it right.

Yes, but we're told this is 30 year old code, simpler times.

abrsvc

2021-01-09 13:06:05 UTC

Post by Chris
Ideally, you get the user input, parse it to verify correct format and
only then, pass the year field to the conversion routine. Only a few
lines of added code needed to do it right.

Yes, but we're told this is 30 year old code, simpler times.

Perhaps a different approach is needed here. While the focus thus far has been on the IF statement, perhaps this code has never worked as expected. Can you post the machine code listing for that segment of the code? I have worked with a number of code bases where the code appears to work, but in fact was not and the failure was hidden. That may be the case here as well.

Andy Burns

2021-01-09 13:30:37 UTC

Post by abrsvc
Perhaps a different approach is needed here. While the focus thus
far has been on the IF statement, perhaps this code has never worked
as expected. Can you post the machine code listing for that segment
of the code? I have worked with a number of code bases where the
code appears to work, but in fact was not and the failure was hidden.
That may be the case here as well.

I suspect the code in both 'halves' of the IF statement is working as
expected, if year > 2020 thenreject the date, otherwise accept the date.

The real question is what demon (possibly lurking in a non-obvious part
of the system) will barf if a 2021 date were accepted? There may be no
demon.

Chris

2021-01-09 13:09:54 UTC

Post by Chris
Ideally, you get the user input, parse it to verify correct format and
only then, pass the year field to the conversion routine. Only a few
lines of added code needed to do it right.

Yes, but we're told this is 30 year old code, simpler times.

Simpler times perhaps, but such ambiguous looking code is a nightmare
for maintainers, having spent years trying to just that. Get the onpage
format and code structure right and it should flow like the lines of a
story...

Chris

Stephen Hoffman

2021-01-09 16:35:57 UTC

Post by Chris
Ideally, you get the user input, parse it to verify correct format and
only then, pass the year field to the conversion routine. Only a few
lines of added code needed to do it right.

Yes, but we're told this is 30 year old code, simpler times.

Phrases such as "It's in VAX C" or "It's K&R" is usually sufficient to
indicate derelict C code.

And that code is not ambiguous. It's dependent on the order of
evaluation; on the C operator precedence rules.

https://en.cppreference.com/w/c/language/operator_precedence

Would I write new code that way? No. But long ago, I also once wrote
***foo->bar and ilk. And I'm sorry that I wrote that C code.

Would I refactor that atoi() C code? Maybe. I'd certainly want to, but
that the code is still K&R C implies little or no management support
for that. And I'd want to know more context around the app and its
data, as home-grown parsers tend to be bug farms.

And have I blamed my tools? Absolutely. Having had my (bogus)
blame-the-tools claims rejected a few times in years past, now I use
the universal debugger printf, or the OpenVMS debugger, or occasionally
other tooling, and gather some evidence for the claims.

Aside: got a bug report about a permissions-related error in my code.
Dug into the app code, and found that a lower-level call in a
dependency was mis-coded, and the context where the lower-level code
went awry. Looked up the maintainer of the failing lower-level code,
and it was the bug submitter. Submitter was surprised to discover the
bug report reflected back and assigned to them—with troubleshooting and
a reproducer. Put differently, when the tools go sideways and I want
to blame those lower-level tools, gather or build a reproducer. That'll
then point to a flaw in my code or in the dependency, and it'll mean a
faster fix.

--
Pure Personal Opinion | HoffmanLabs LLC

Arne Vajhøj

2021-01-09 15:40:53 UTC

if (atoi (date_string + 5)> 2020)

That code is type unsafe for starters. atoi() requires an ascii string,
but you are trying to add 5 decimal to an ascii string ?.

atoi requires a *pointer* to an asciiz string, presumably in this case
the format is something like DDMMMYYYY, so that the +5 starts the
decimal conversion from the address of the first Y.

Ok, but I would not be doing pointer arithmetic inside an ancient
library function such as atoi(). Expecting the compiler to a be a
mindreader etc.

It does not need to be a mind reader. It just needs to
follow the C standard.

If you have a char* and add an int then you get another
char* and the expression will be evaluated before the call
and char* is what atoi expects.

It may not be robust code and it may not be super readable
code, but it should not be a problem for the compiler to
do what it is being told.

Arne

Bill Gunshannon

2021-01-09 13:27:17 UTC

if (atoi (date_string + 5)> 2020)

That code is type unsafe for starters. atoi() requires an ascii string,
but you are trying to add 5 decimal to an ascii string ?.

atoi requires a *pointer* to an asciiz string, presumably in this case
the format is something like DDMMMYYYY, so that the +5 starts the
decimal conversion from the address of the first Y.

Am I the only one who things this was fat fingered and the example
should really be: if ((atoi (date_string) + 5) > 2020)

I would have expected the original to generate an error at compile
time.

bill

Bill Gunshannon

2021-01-09 13:38:45 UTC

if (atoi (date_string + 5)> 2020)

That code is type unsafe for starters. atoi() requires an ascii string,
but you are trying to add 5 decimal to an ascii string ?.

atoi requires a *pointer* to an asciiz string, presumably in this case
the format is something like DDMMMYYYY, so that the +5 starts the
decimal conversion from the address of the first Y.

Am I the only one who things this was fat fingered and the example
should really be: if ((atoi (date_string) + 5) > 2020)
I would have expected the original to generate an error at compile
time.

OK, it made me curious enough that I tried a few examples. Apparently
the compiler (at least gcc) doesn't really care what you throw at the
call to atoi(). Interesting to say the least.

bill

John Dallman

1970-01-01 00:00:00 UTC

if (atoi (date_string + 5)> 2020)

atoi requires a *pointer* to an asciiz string, presumably in
this case the format is something like DDMMMYYYY, so that the +5
starts the decimal conversion from the address of the first Y.

I would have expected the original to generate an error at compile
time.

OK, it made me curious enough that I tried a few examples.
Apparently the compiler (at least gcc) doesn't really care what you
throw at the call to atoi().

It takes a char* pointer, and assumes the string is terminated by a zero
byte. The +5 is just moving the pointer along by 5 characters, producing
a new pointer.

This is perfectly legal C code. Not good modern style, but entirely legal.

John

abrsvc

2021-01-09 15:40:11 UTC

Post by John Dallman

if (atoi (date_string + 5)> 2020)

atoi requires a *pointer* to an asciiz string, presumably in
this case the format is something like DDMMMYYYY, so that the +5
starts the decimal conversion from the address of the first Y.

I would have expected the original to generate an error at compile
time.

OK, it made me curious enough that I tried a few examples.
Apparently the compiler (at least gcc) doesn't really care what you
throw at the call to atoi().

It takes a char* pointer, and assumes the string is terminated by a zero
byte. The +5 is just moving the pointer along by 5 characters, producing
a new pointer.
This is perfectly legal C code. Not good modern style, but entirely legal.
John

Please note as well that the initial problem statement indicated that date_string was an array.
I would assume that it is an array of characters and that date_string+5 points to the year portion as John suggested.

Arne Vajhøj

2021-01-09 15:43:02 UTC

if (atoi (date_string + 5)> 2020)

That code is type unsafe for starters. atoi() requires an ascii string,
but you are trying to add 5 decimal to an ascii string ?.

atoi requires a *pointer* to an asciiz string, presumably in this
case the format is something like DDMMMYYYY, so that the +5 starts
the decimal conversion from the address of the first Y.

Am I the only one who things this was fat fingered and the example
should really be: if ((atoi (date_string) + 5) > 2020)

That code makes little sense.

The original code as already noted do a skip of DDMMM.

Post by Bill Gunshannon
I would have expected the original to generate an error at compile
time.

OK, it made me curious enough that I tried a few examples. Apparently
the compiler (at least gcc) doesn't really care what you throw at the
call to atoi(). Interesting to say the least.

char* + int is char*. atoi expects char*. Why should it complain?

Arne

1tim....@gmail.com

2021-01-09 22:20:42 UTC

if (atoi (date_string + 5)> 2020)

That code is type unsafe for starters. atoi() requires an ascii string,
but you are trying to add 5 decimal to an ascii string ?.

atoi requires a *pointer* to an asciiz string, presumably in this
case the format is something like DDMMMYYYY, so that the +5 starts
the decimal conversion from the address of the first Y.

Am I the only one who things this was fat fingered and the example
should really be: if ((atoi (date_string) + 5) > 2020)

That code makes little sense.
The original code as already noted do a skip of DDMMM.

Post by Bill Gunshannon
I would have expected the original to generate an error at compile
time.

OK, it made me curious enough that I tried a few examples. Apparently
the compiler (at least gcc) doesn't really care what you throw at the
call to atoi(). Interesting to say the least.

char* + int is char*. atoi expects char*. Why should it complain?
Arne

You're right! I just re-read it. duh! offset the date string start by 5 chars, do the atoi for the last part of the string and do the compare.

I'm embarrassed :-)

I was reading it as add 5 to the value of the date string and compare. Not offset from the start of the string.

Chris

2021-01-10 00:28:30 UTC

Post by issinoho
if (atoi (date_string + 5)> 2020)

That code is type unsafe for starters. atoi() requires an ascii string,
but you are trying to add 5 decimal to an ascii string ?.

atoi requires a *pointer* to an asciiz string, presumably in this
case the format is something like DDMMMYYYY, so that the +5 starts
the decimal conversion from the address of the first Y.

Am I the only one who things this was fat fingered and the example
should really be: if ((atoi (date_string) + 5)> 2020)

That code makes little sense.
The original code as already noted do a skip of DDMMM.

Post by Bill Gunshannon
I would have expected the original to generate an error at compile
time.

OK, it made me curious enough that I tried a few examples. Apparently
the compiler (at least gcc) doesn't really care what you throw at the
call to atoi(). Interesting to say the least.

char* + int is char*. atoi expects char*. Why should it complain?
Arne

You're right! I just re-read it. duh! offset the date string start by 5 chars, do the atoi for the last part of the string and do the compare.
I'm embarrassed :-)

No reason, as while it may be legal syntax, if you are reviewing for
maintenance, that interrupts the mental flow, pause for a second
while you decode what it means. No excuse for such lazy style, decades
ago or not. Wouldn't last 5 minutes in industry with regular code
reviews. Cryptic hard coded constants in the code as well !.

Ongoing maintenance can take up far more resources that the whole
original project cost, so needs to be done right from the start...

Chris

Post by ***@gmail.com
I was reading it as add 5 to the value of the date string and compare. Not offset from the start of the string.

Bill Gunshannon

2021-01-09 23:33:16 UTC

if (atoi (date_string + 5)> 2020)

That code is type unsafe for starters. atoi() requires an ascii string,
but you are trying to add 5 decimal to an ascii string ?.

atoi requires a *pointer* to an asciiz string, presumably in this
case the format is something like DDMMMYYYY, so that the +5 starts
the decimal conversion from the address of the first Y.

Am I the only one who things this was fat fingered and the example
should really be: if ((atoi (date_string) + 5) > 2020)

That code makes little sense.
The original code as already noted do a skip of DDMMM.

Post by Bill Gunshannon
I would have expected the original to generate an error at compile
time.

OK, it made me curious enough that I tried a few examples. Apparently
the compiler (at least gcc) doesn't really care what you throw at the
call to atoi(). Interesting to say the least.

char* + int is char*. atoi expects char*. Why should it complain?
Arne

I agree. I misunderstood. Probably because I was trying to figure out
what they wanted done rather than what t hey were doing. I can safely
say I would (and to the best of my knowledge never have) do anything
like that.

bill

Arne Vajhøj

2021-01-10 00:20:27 UTC

if (atoi (date_string + 5)> 2020)

That code is type unsafe for starters. atoi() requires an ascii string,
but you are trying to add 5 decimal to an ascii string ?.

atoi requires a *pointer* to an asciiz string, presumably in this
case the format is something like DDMMMYYYY, so that the +5 starts
the decimal conversion from the address of the first Y.

Am I the only one who things this was fat fingered and the example
should really be: if ((atoi (date_string) + 5) > 2020)

That code makes little sense.
The original code as already noted do a skip of DDMMM.

Post by Bill Gunshannon
I would have expected the original to generate an error at compile
time.

OK, it made me curious enough that I tried a few examples. Apparently
the compiler (at least gcc) doesn't really care what you throw at the
call to atoi(). Interesting to say the least.

char* + int is char*. atoi expects char*. Why should it complain?

I agree. I misunderstood. Probably because I was trying to figure out
what they wanted done rather than what t hey were doing.

C

:-)

I can safely
say I would (and to the best of my knowledge never have) do anything
like that.

Such constructs are pretty common in C.

I guess it could have been made more clear by writing:

char *yyyy_ptr = date_string + strlen("DDMMM");
if (atoi(yyyy_ptr) > 2020)

Arne

Dave Froble

2021-01-10 02:15:39 UTC

Post by issinoho
if (atoi (date_string + 5)> 2020)

That code is type unsafe for starters. atoi() requires an ascii string,
but you are trying to add 5 decimal to an ascii string ?.

atoi requires a *pointer* to an asciiz string, presumably in this
case the format is something like DDMMMYYYY, so that the +5 starts
the decimal conversion from the address of the first Y.

Am I the only one who things this was fat fingered and the example
should really be: if ((atoi (date_string) + 5) > 2020)

That code makes little sense.
The original code as already noted do a skip of DDMMM.

Post by Bill Gunshannon
I would have expected the original to generate an error at compile
time.

OK, it made me curious enough that I tried a few examples. Apparently
the compiler (at least gcc) doesn't really care what you throw at the
call to atoi(). Interesting to say the least.

char* + int is char*. atoi expects char*. Why should it complain?
Arne

Playing around with pointers isn't the worst thing one could do. Code
like that without adequate comments deserves tar, feathers, and a rail.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Rich Alderson

2021-01-10 18:06:38 UTC

Post by Dave Froble
Playing around with pointers isn't the worst thing one could do. Code
like that without adequate comments deserves tar, feathers, and a rail.

OK, I've used tar extensively, and I've heard of "rails" in the context of the
Ruby language, but what the hell is "feathers"?

--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Michael Moroney

2021-01-10 19:08:52 UTC

Post by Rich Alderson

Post by Dave Froble
Playing around with pointers isn't the worst thing one could do. Code
like that without adequate comments deserves tar, feathers, and a rail.

OK, I've used tar extensively, and I've heard of "rails" in the context of the
Ruby language, but what the hell is "feathers"?

Umm, no. "Tar and feathers" was a colonial era mob violence punishment,
as was "being run out of town on a rail". The first was to cover the
victim in tar and then cover him in feathers which stuck to the tar.
"Run out of town on a rail" was to tie the victim's arms and legs to a
pole (rail) and then carry the pole/victim to the edge of town/some
remote place and leave him there, after being told never to return.
Sometimes both were used.

Rich Alderson

2021-01-11 21:42:17 UTC

Post by Michael Moroney

Post by Rich Alderson

Post by Dave Froble
Playing around with pointers isn't the worst thing one could do. Code
like that without adequate comments deserves tar, feathers, and a rail.

OK, I've used tar extensively, and I've heard of "rails" in the context of
the Ruby language, but what the hell is "feathers"?

$DEITY, did I really need to hang smilies all over that????

.--._
'. ='-._
'.= =('-.
\ = (( '.
, | =(( _\.___
/=`"--.,_;..--'` _`'.
/ = .------. (o) )>
/_=___,.../= `(( |_.--'`
_.' = (( /
_.-'`= = _(( /
.-'__=___=___((_,.'

Whoosh!

--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Andy Burns

2021-01-09 13:46:21 UTC

Post by Bill Gunshannon
Am I the only one who things this was fat fingered and the example
should really be: if ((atoi (date_string) + 5) > 2020)

If that was intended, why not write it as

if (atoi (date_string) > 2015)

Post by Bill Gunshannon
I would have expected the original to generate an error at compile
time.

<https://onlinegdb.com/BydFQVPCD>

1tim....@gmail.com

2021-01-09 21:38:07 UTC

Post by issinoho

Post by issinoho
We have some old 90s VAX C code which rejects any dates after the year 2020

Does this use 2 digit years or 4 digit?

Without seeing any of the code, we can speculate till the cows come home and never uncover the real problem. I too have seen all kinds of trickery to get around 2 digit year storage and the change from 19 to 20. Given that the century remained the same here, I suspect a different issue.
There are many of us here (myself included) that can provide assistance in tracking this down. Just because the code is old does not mean anything. I am working with code now that was last modified in 1988 and is still running fine. Other code written recently has issues (go figure...)
Dan

OK, so the very fact none of you are jumping down my throat with an obvious reason is significant.
For the curious here is the code in question...
if (atoi (date_string + 5) > 2020)
....
where date_string is a char array
Thanks for the continued support.

you are adding 5 to the ascii value of the first byte of that date string.

code should read

if ((atoi(date_string) + 5) > 2020)

Andy Burns

2021-01-09 21:48:37 UTC

Post by issinoho
if (atoi (date_string + 5) > 2020)

you are adding 5 to the ascii value of the first byte of that date string.

No, indexing 5 bytes into the string.

Stephen Hoffman

2021-01-09 22:11:01 UTC

...
if (atoi (date_string + 5) > 2020).

you are adding 5 to the ascii value of the first byte of that date string.

The cited C code above is not adding 5 to the ASCII value of the first
byte. The date_string + 5 syntax shown is performing pointer math, and
moves the begining of the string by five of whatever the pointer is
pointing to. That'll be 5 characters, if date_string is a character
pointer as would be typical.

A word or longword pointer would be somewhat unusual here, though
pointer math works with that, too. Adding 5 would relocate by 10 or by
20 bytes for a word or longword pointer, respectively. But I digress.

If this is a request to add 5 to the ASCII value of the first byte,
then the code would typically be date_string[0] + 5, or maybe
*date_string + 5, assuming a character pointer. date_string[0] and
*date_string both return the byte value for the specified pointer,
again assuming a character pointer.

Post by ***@gmail.com
code should read
if ((atoi(date_string) + 5) > 2020)'

That C code will convert the contents of the bytes at the specified
address to an integer, then add 5 to the result.

(Valid input for atoi can include an optional leading + or -, then some
number of decimal digits up to the first non-decimal-digit or the first
null byte. Invalid string input gets a 0 as a return from atoi.)

But without more context to the code, it's difficult to determine the
intent of the programmer with absolute certainty.

Hoff

--
Pure Personal Opinion | HoffmanLabs LLC

1tim....@gmail.com

2021-01-09 22:21:34 UTC

Post by Stephen Hoffman