diff mbox series

newlib: m68k-atari-elf, fixed naming bug in defines

Message ID 1763489228285.7.52370@webmail-backend-production-7f5d966f9d-mjhlf
State New
Headers
Series newlib: m68k-atari-elf, fixed naming bug in defines |

Commit Message

micael@hildenborg.com Nov. 18, 2025, 6:07 p.m. UTC 
  Fix to a reported problem in naming of defines.


/Mikael Hildenborg.

Comments

Corinna Vinschen Nov. 28, 2025, 12:13 p.m. UTC | #1 
Hi Mikael,

On Nov 18 19:07, micael@hildenborg.com wrote:
> Fix to a reported problem in naming of defines.
> 
> 
> /Mikael Hildenborg.
> 
> 

> From 65b71bd50631da48343b97fecdade55e7c1122f4 Mon Sep 17 00:00:00 2001
> From: Mikael Hildenborg <micael@hildenborg.com>
> Date: Tue, 18 Nov 2025 18:40:48 +0100
> Subject: [PATCH] m68k-atari-elf: fixed naming bug in defines.
> 
> ---
>  libgloss/m68k/atari/atari-gettod.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/libgloss/m68k/atari/atari-gettod.c b/libgloss/m68k/atari/atari-gettod.c
> index 75139ed8c..c8227ae5e 100644
> --- a/libgloss/m68k/atari/atari-gettod.c
> +++ b/libgloss/m68k/atari/atari-gettod.c
> @@ -14,8 +14,8 @@
>  	The code below uses that limitation to simplify the code.
>  */
>  
> -#define SEC_1900_TO_1980 315529200
> -#define SEC_1900_TO_MAX 0x7fffffff
> +#define SEC_1970_TO_1980 315529200
> +#define SEC_1970_TO_MAX 0x7fffffff
>  #define SECONDS_IN_A_DAY (24 * 60 * 60)
>  #define SEC_JAN_AND_FEB ((31 + 29) * SECONDS_IN_A_DAY)	// In a leap year
>  #define SECONDS_IN_A_YEAR (365 * SECONDS_IN_A_DAY)

SEC_1900_TO_1980 is set to 2524521600 in git, so this hunk doesn't apply.
Can you check and resend a new patch, please?

Also, if you don't mind, please add a more helpful commit message.
It doesn't even mention the affected macros...


Thanks,
Corinna
micael@hildenborg.com Nov. 29, 2025, 2:48 p.m. UTC | #2 
Hi Corinna,

I'm sorry for causing confusion and taking up unnecessary time. Try to see this as a comical example of my autism spectrum shining through...

The patch was a follow up to a mail from John Johnston on the 17th november, where he found a problem with one out of fixe patches I mailed. So obviously I should have replied to him and not posted it directly on the mailing list.

But while we are at it I might as well ask what the proper procedure is for my case:
I posted a mail containing five pacthes (five commits).
If one of them contains a problem and needs to be fixed, how should that be done?
Adding a patch to the list, making it six patches, where the last fixes the problem?
Or should the problematic patch (commit) be redone correctly?

Again, sorry for taking up your time.

/Mikael.




Den fredag 28 november 2025 kl. 13:13:15 +01:00, skrev Corinna Vinschen <vinschen@redhat.com>:

> Hi Mikael,
> 
> On Nov 18 19:07, <micael@hildenborg.com> wrote:
> 
> > Fix to a reported problem in naming of defines.
> > 
> > 
> > /Mikael Hildenborg.
> > 
> > 
> 
> > From 65b71bd50631da48343b97fecdade55e7c1122f4 Mon Sep 17 00:00:00 2001
> > From: Mikael Hildenborg <<micael@hildenborg.com>>
> > Date: Tue, 18 Nov 2025 18:40:48 +0100
> > Subject: [PATCH] m68k-atari-elf: fixed naming bug in defines.
> > 
> > ---
> > libgloss/m68k/atari/atari-gettod.c | 10 +++++-----
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/libgloss/m68k/atari/atari-gettod.c b/libgloss/m68k/atari/atari-gettod.c
> > index 75139ed8c..c8227ae5e 100644
> > --- a/libgloss/m68k/atari/atari-gettod.c
> > +++ b/libgloss/m68k/atari/atari-gettod.c
> > @@ -14,8 +14,8 @@
> > The code below uses that limitation to simplify the code.
> > */
> > 
> > -#define SEC_1900_TO_1980 315529200
> > -#define SEC_1900_TO_MAX 0x7fffffff
> > +#define SEC_1970_TO_1980 315529200
> > +#define SEC_1970_TO_MAX 0x7fffffff
> > #define SECONDS_IN_A_DAY (24 * 60 * 60)
> > #define SEC_JAN_AND_FEB ((31 + 29) * SECONDS_IN_A_DAY)	// In a leap year
> > #define SECONDS_IN_A_YEAR (365 * SECONDS_IN_A_DAY)
> > 
> SEC_1900_TO_1980 is set to 2524521600 in git, so this hunk doesn't apply.
> Can you check and resend a new patch, please?
> 
> Also, if you don't mind, please add a more helpful commit message.
> It doesn't even mention the affected macros...
> 
> 
> Thanks,
> Corinna
>
Corinna Vinschen Dec. 1, 2025, 3:33 p.m. UTC | #3 
Hi Mikael,

On Nov 29 15:48, micael@hildenborg.com wrote:
> Hi Corinna,
> 
> I'm sorry for causing confusion and taking up unnecessary time. Try to
> see this as a comical example of my autism spectrum shining through...

Naah, no worries. Shit happens.

> The patch was a follow up to a mail from John Johnston on the 17th
> november, where he found a problem with one out of fixe patches I
> mailed. So obviously I should have replied to him and not posted it
> directly on the mailing list.

Ah, ok, that would have been better, perhaps, but it doesn't matter
anymore, so again, no worries.

> But while we are at it I might as well ask what the proper procedure
> is for my case: I posted a mail containing five pacthes (five
> commits).  If one of them contains a problem and needs to be fixed,
> how should that be done?  Adding a patch to the list, making it six
> patches, where the last fixes the problem?  Or should the problematic
> patch (commit) be redone correctly?

It depends on the state of the patch.  If it has been pushed to the repo
already, a followup patch is necessary. But as long as it hasn't been
pushed, just send a v2 of your patch.  `git send-email is pretty helpful
there, having a -v option to add a version number (or "reroll-count" as
it is called officially).  -v 2 results in your subject being called

  [PATCH v2] foo...

and so on.  If only a single patch is affected, it's your call if you
just send a new version of that patch (ideally with a reply-to set to
your original patch), or if you just send the entire series as a v2.
Sending a v2 (or v3, ...) of the full series makes the most sense, if
none of the patches have been applied yet.  Whatever suits you, given
this mailing list hasn't *that* much traffic.


Thanks,
Corinna
diff mbox series

Patch

From 65b71bd50631da48343b97fecdade55e7c1122f4 Mon Sep 17 00:00:00 2001
From: Mikael Hildenborg <micael@hildenborg.com>
Date: Tue, 18 Nov 2025 18:40:48 +0100
Subject: [PATCH] m68k-atari-elf: fixed naming bug in defines.

---
 libgloss/m68k/atari/atari-gettod.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libgloss/m68k/atari/atari-gettod.c b/libgloss/m68k/atari/atari-gettod.c
index 75139ed8c..c8227ae5e 100644
--- a/libgloss/m68k/atari/atari-gettod.c
+++ b/libgloss/m68k/atari/atari-gettod.c
@@ -14,8 +14,8 @@ 
 	The code below uses that limitation to simplify the code.
 */
 
-#define SEC_1900_TO_1980 315529200
-#define SEC_1900_TO_MAX 0x7fffffff
+#define SEC_1970_TO_1980 315529200
+#define SEC_1970_TO_MAX 0x7fffffff
 #define SECONDS_IN_A_DAY (24 * 60 * 60)
 #define SEC_JAN_AND_FEB ((31 + 29) * SECONDS_IN_A_DAY)	// In a leap year
 #define SECONDS_IN_A_YEAR (365 * SECONDS_IN_A_DAY)
@@ -59,7 +59,7 @@  int gettimeofday(struct timeval* tv, void* __tz)
 		}
 
 		// Add it all together
-		tv->tv_sec = (((((days * 24) + hour) * 60) + min) * 60) + sec + SEC_1900_TO_1980;
+		tv->tv_sec = (((((days * 24) + hour) * 60) + min) * 60) + sec + SEC_1970_TO_1980;
 		tv->tv_usec = 0;
 	}
 	return 0;
@@ -70,14 +70,14 @@  int settimeofday(const struct timeval* tv, const struct timezone* tz)
 	// Support for timezone have been removed from linux glibc, so we just ignore it.
 	if (tv != 0)
 	{
-		if (tv->tv_sec < SEC_1900_TO_1980 || tv->tv_sec >= SEC_1900_TO_MAX)
+		if (tv->tv_sec < SEC_1970_TO_1980 || tv->tv_sec >= SEC_1970_TO_MAX)
 		{
 			// Outside the ranges we can handle.
 			gem_error_to_errno(GEM_EBADRQ);
 			return -1;
 		}
 
-		time_t seconds = tv->tv_sec - SEC_1900_TO_1980;
+		time_t seconds = tv->tv_sec - SEC_1970_TO_1980;
 		int year = 0;
 		time_t ysec = SECONDS_IN_A_YEAR;
 		do
-- 
2.43.0