[PATCH 1/3] checkpatch: Check for use of disallowed macros

[PATCH 1/3] checkpatch: Check for use of disallowed macros

[Rasmus Villemoes]

Since fe7c36c7 ("Makefile: Build with -Werror=date-time if the
compiler supports it"), use of __DATE__, __TIME__, __TIMESTAMP__ has
been disallowed. This hasn't prevented a few new users from creeping
in. Make checkpatch complain.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
 scripts/checkpatch.pl | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f0bb6d60c07b..7fafd3b45539 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3008,6 +3008,12 @@ sub process {
 		$line =~ s@//.*@@;
 		$opline =~ s@//.*@@;
 
+
+# Use of __DATE__, __TIME__, __TIMESTAMP__ is not allowed
+		if ($line =~ m/\b__(?:DATE|TIME|TIMESTAMP)__\b/) {
+		    ERROR("DATETIME", "Do not use the macros __DATE__, __TIME__ and __TIMESTAMP__\n" . $herecurr)
+		}
+
 # EXPORT_SYMBOL should immediately follow the thing it is exporting, consider
 # the whole statement.
 #print "APW <$lines[$realline_next - 1]>\n";
-- 
2.1.3

[PATCH 2/3] staging: unisys: remove leftover __DATE__

[Rasmus Villemoes]

Commit 836bee9eee6d ("Staging: unisys: remove references to __DATE__
and __TIME__") removed most; this seems to be an accidental
leftover. VERSIONDATE is not used anywhere.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
 drivers/staging/unisys/common-spar/include/version.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/unisys/common-spar/include/version.h b/drivers/staging/unisys/common-spar/include/version.h
index f25208fc3ed1..83d1da7a2f81 100644
--- a/drivers/staging/unisys/common-spar/include/version.h
+++ b/drivers/staging/unisys/common-spar/include/version.h
@@ -30,7 +30,6 @@
 #define SPARVER4 "0"
 
 #define  VERSION        SPARVER1 "." SPARVER2 "." SPARVER3 "." SPARVER4
-#define  VERSIONDATE    __DATE__
 
 /* Here are various version forms needed in Windows environments.
  */
-- 
2.1.3

[PATCH 3/3] ACPICA: Remove use of __DATE__ macro

[Rasmus Villemoes]

The macro __DATE__ and friends is not allowed in the kernel. Also,
including the build time in output doesn't seem to provide any value.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
 drivers/acpi/acpica/acapps.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/acpica/acapps.h b/drivers/acpi/acpica/acapps.h
index 3d2c88289da9..f72826176ebe 100644
--- a/drivers/acpi/acpica/acapps.h
+++ b/drivers/acpi/acpica/acapps.h
@@ -64,15 +64,15 @@
 /* Macros for signons and file headers */
 
 #define ACPI_COMMON_SIGNON(utility_name) \
-	"\n%s\n%s version %8.8X%s [%s]\n%s\n\n", \
+	"\n%s\n%s version %8.8X%s\n%s\n\n", \
 	ACPICA_NAME, \
-	utility_name, ((u32) ACPI_CA_VERSION), ACPI_WIDTH, __DATE__, \
+	utility_name, ((u32) ACPI_CA_VERSION), ACPI_WIDTH, \
 	ACPICA_COPYRIGHT
 
 #define ACPI_COMMON_HEADER(utility_name, prefix) \
-	"%s%s\n%s%s version %8.8X%s [%s]\n%s%s\n%s\n", \
+	"%s%s\n%s%s version %8.8X%s\n%s%s\n%s\n", \
 	prefix, ACPICA_NAME, \
-	prefix, utility_name, ((u32) ACPI_CA_VERSION), ACPI_WIDTH, __DATE__, \
+	prefix, utility_name, ((u32) ACPI_CA_VERSION), ACPI_WIDTH, \
 	prefix, ACPICA_COPYRIGHT, \
 	prefix
 
-- 
2.1.3

RE: [PATCH 3/3] ACPICA: Remove use of __DATE__ macro

[Zheng, Lv]

Hi,

> From: Rasmus Villemoes [mailto:linux@rasmusvillemoes.dk]
> Sent: Friday, December 12, 2014 6:51 PM
> To: Zheng, Lv
> Cc: Rasmus Villemoes; linux-acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org
> Subject: [PATCH 3/3] ACPICA: Remove use of __DATE__ macro
> 
> The macro __DATE__ and friends is not allowed in the kernel. Also,
> including the build time in output doesn't seem to provide any value.
> 

Could you confirm that it is not useful even for the user tools?
Please perform the following commands in the kernel source tree
1. stay in tools folder
2. type "make acpi"
3. type "./power/acpi/acpidump -v"

Thanks and best regards
-Lv

> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
>  drivers/acpi/acpica/acapps.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/acpi/acpica/acapps.h b/drivers/acpi/acpica/acapps.h
> index 3d2c88289da9..f72826176ebe 100644
> --- a/drivers/acpi/acpica/acapps.h
> +++ b/drivers/acpi/acpica/acapps.h
> @@ -64,15 +64,15 @@
>  /* Macros for signons and file headers */
> 
>  #define ACPI_COMMON_SIGNON(utility_name) \
> -	"\n%s\n%s version %8.8X%s [%s]\n%s\n\n", \
> +	"\n%s\n%s version %8.8X%s\n%s\n\n", \
>  	ACPICA_NAME, \
> -	utility_name, ((u32) ACPI_CA_VERSION), ACPI_WIDTH, __DATE__, \
> +	utility_name, ((u32) ACPI_CA_VERSION), ACPI_WIDTH, \
>  	ACPICA_COPYRIGHT
> 
>  #define ACPI_COMMON_HEADER(utility_name, prefix) \
> -	"%s%s\n%s%s version %8.8X%s [%s]\n%s%s\n%s\n", \
> +	"%s%s\n%s%s version %8.8X%s\n%s%s\n%s\n", \
>  	prefix, ACPICA_NAME, \
> -	prefix, utility_name, ((u32) ACPI_CA_VERSION), ACPI_WIDTH, __DATE__, \
> +	prefix, utility_name, ((u32) ACPI_CA_VERSION), ACPI_WIDTH, \
>  	prefix, ACPICA_COPYRIGHT, \
>  	prefix
> 
> --
> 2.1.3

Re: [PATCH 3/3] ACPICA: Remove use of __DATE__ macro

[Rasmus Villemoes]

On Mon, Jan 05 2015, "Zheng, Lv" <lv.zheng@intel.com> wrote:

> Hi,
>
>> From: Rasmus Villemoes [mailto:linux@rasmusvillemoes.dk]
>> Sent: Friday, December 12, 2014 6:51 PM
>> To: Zheng, Lv
>> Cc: Rasmus Villemoes; linux-acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org
>> Subject: [PATCH 3/3] ACPICA: Remove use of __DATE__ macro
>> 
>> The macro __DATE__ and friends is not allowed in the kernel. Also,
>> including the build time in output doesn't seem to provide any value.
>> 
>
> Could you confirm that it is not useful even for the user tools?
> Please perform the following commands in the kernel source tree
> 1. stay in tools folder
> 2. type "make acpi"
> 3. type "./power/acpi/acpidump -v"
>

Yeah, it's part of the output, but for what reason? What can userspace
possibly use that information for? I can see some utility in printing a
version number, since that may tell something about the features
present or absent. The compilation date, on the other hand, seems
completely useless. Different distros may ship different versions which
happened to be compiled on the same day, or older versions compiled later.

Note that -Werror=date-time was added to the kernel's default build
flags in fe7c36c7bde12. It doesn't currently show because tools/ uses
its own flags, and the ACPI_COMMON_SIGNON macro is not used within the
kernel. 

Rasmus

RE: [PATCH 3/3] ACPICA: Remove use of __DATE__ macro

[Zheng, Lv]

Hi,

> From: Rasmus Villemoes [mailto:linux@rasmusvillemoes.dk]
> Sent: Monday, January 05, 2015 6:27 PM
> 
> On Mon, Jan 05 2015, "Zheng, Lv" <lv.zheng@intel.com> wrote:
> 
> > Hi,
> >
> >> From: Rasmus Villemoes [mailto:linux@rasmusvillemoes.dk]
> >> Sent: Friday, December 12, 2014 6:51 PM
> >> To: Zheng, Lv
> >> Cc: Rasmus Villemoes; linux-acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org
> >> Subject: [PATCH 3/3] ACPICA: Remove use of __DATE__ macro
> >>
> >> The macro __DATE__ and friends is not allowed in the kernel. Also,
> >> including the build time in output doesn't seem to provide any value.
> >>
> >
> > Could you confirm that it is not useful even for the user tools?
> > Please perform the following commands in the kernel source tree
> > 1. stay in tools folder
> > 2. type "make acpi"
> > 3. type "./power/acpi/acpidump -v"
> >
> 
> Yeah, it's part of the output, but for what reason? What can userspace
> possibly use that information for?

I also want to know.

> I can see some utility in printing a
> version number, since that may tell something about the features
> present or absent. The compilation date, on the other hand, seems
> completely useless. Different distros may ship different versions which
> happened to be compiled on the same day, or older versions compiled later.

If the deletion was done for this reason, IMO, it's acceptable.
So let's wait to see others' feedback.

Thanks and best regards
-Lv

> Note that -Werror=date-time was added to the kernel's default build
> flags in fe7c36c7bde12. It doesn't currently show because tools/ uses
> its own flags, and the ACPI_COMMON_SIGNON macro is not used within the
> kernel.
> 
> Rasmus

Re: [Devel] [PATCH 3/3] ACPICA: Remove use of __DATE__ macro

[David E. Box]

On Tue, Jan 06, 2015 at 12:30:05AM +0000, Zheng, Lv wrote:
> Hi,
> 
> > From: Rasmus Villemoes [mailto:linux@rasmusvillemoes.dk]
> > Sent: Monday, January 05, 2015 6:27 PM
> > 
> > On Mon, Jan 05 2015, "Zheng, Lv" <lv.zheng@intel.com> wrote:
> > 
> > > Hi,
> > >
> > >> From: Rasmus Villemoes [mailto:linux@rasmusvillemoes.dk]
> > >> Sent: Friday, December 12, 2014 6:51 PM
> > >> To: Zheng, Lv
> > >> Cc: Rasmus Villemoes; linux-acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org
> > >> Subject: [PATCH 3/3] ACPICA: Remove use of __DATE__ macro
> > >>
> > >> The macro __DATE__ and friends is not allowed in the kernel. Also,
> > >> including the build time in output doesn't seem to provide any value.
> > >>
> > >
> > > Could you confirm that it is not useful even for the user tools?
> > > Please perform the following commands in the kernel source tree
> > > 1. stay in tools folder
> > > 2. type "make acpi"
> > > 3. type "./power/acpi/acpidump -v"
> > >
> > 
> > Yeah, it's part of the output, but for what reason? What can userspace
> > possibly use that information for?
> 
> I also want to know.

I don't see a reason for userspace to know the build date.

> 
> > I can see some utility in printing a
> > version number, since that may tell something about the features
> > present or absent. The compilation date, on the other hand, seems
> > completely useless. Different distros may ship different versions which
> > happened to be compiled on the same day, or older versions compiled later.
> 
> If the deletion was done for this reason, IMO, it's acceptable.
> So let's wait to see others' feedback.
> 

I'm okay with removing it (the build date) in Linux and ACPICA as well. However
the version, which is essentially the release date, is important for the exact
reasons already stated.

Dave

RE: [Devel] [PATCH 3/3] ACPICA: Remove use of __DATE__ macro

[Zheng, Lv]

Hi,

I've added this patch into the 201501 ACPICA materials for review:
https://github.com/acpica/acpica/pull/61
If it is merged, it will appear in Linux kernel after 201501 ACPICA release.
Thanks for reporting.

Best regards
-Lv

> From: David E. Box [mailto:david.e.box@linux.intel.com]
> Sent: Wednesday, January 07, 2015 3:36 AM
> 
> On Tue, Jan 06, 2015 at 12:30:05AM +0000, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Rasmus Villemoes [mailto:linux@rasmusvillemoes.dk]
> > > Sent: Monday, January 05, 2015 6:27 PM
> > >
> > > On Mon, Jan 05 2015, "Zheng, Lv" <lv.zheng@intel.com> wrote:
> > >
> > > > Hi,
> > > >
> > > >> From: Rasmus Villemoes [mailto:linux@rasmusvillemoes.dk]
> > > >> Sent: Friday, December 12, 2014 6:51 PM
> > > >> To: Zheng, Lv
> > > >> Cc: Rasmus Villemoes; linux-acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org
> > > >> Subject: [PATCH 3/3] ACPICA: Remove use of __DATE__ macro
> > > >>
> > > >> The macro __DATE__ and friends is not allowed in the kernel. Also,
> > > >> including the build time in output doesn't seem to provide any value.
> > > >>
> > > >
> > > > Could you confirm that it is not useful even for the user tools?
> > > > Please perform the following commands in the kernel source tree
> > > > 1. stay in tools folder
> > > > 2. type "make acpi"
> > > > 3. type "./power/acpi/acpidump -v"
> > > >
> > >
> > > Yeah, it's part of the output, but for what reason? What can userspace
> > > possibly use that information for?
> >
> > I also want to know.
> 
> I don't see a reason for userspace to know the build date.
> 
> >
> > > I can see some utility in printing a
> > > version number, since that may tell something about the features
> > > present or absent. The compilation date, on the other hand, seems
> > > completely useless. Different distros may ship different versions which
> > > happened to be compiled on the same day, or older versions compiled later.
> >
> > If the deletion was done for this reason, IMO, it's acceptable.
> > So let's wait to see others' feedback.
> >
> 
> I'm okay with removing it (the build date) in Linux and ACPICA as well. However
> the version, which is essentially the release date, is important for the exact
> reasons already stated.
> 
> Dave

RE: [Devel] [PATCH 3/3] ACPICA: Remove use of __DATE__ macro

[Zheng, Lv]

Hi, Rasmus

Just for your information.

There is also a known bug related to the application header printing.
The fix is:
https://github.com/zetalog/acpica/commit/79e75432
But this bug can only be seen for EFI ports of ACPICA utilities, it won't be detected in the kernel source tree.
Hope this is not the motivation that has caused you to try to remove the __DATE__ usages.

Thanks and best regards
-Lv

> From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Zheng, Lv
> Sent: Tuesday, January 13, 2015 10:33 AM
> 
> Hi,
> 
> I've added this patch into the 201501 ACPICA materials for review:
> https://github.com/acpica/acpica/pull/61
> If it is merged, it will appear in Linux kernel after 201501 ACPICA release.
> Thanks for reporting.
> 
> Best regards
> -Lv
> 
> > From: David E. Box [mailto:david.e.box@linux.intel.com]
> > Sent: Wednesday, January 07, 2015 3:36 AM
> >
> > On Tue, Jan 06, 2015 at 12:30:05AM +0000, Zheng, Lv wrote:
> > > Hi,
> > >
> > > > From: Rasmus Villemoes [mailto:linux@rasmusvillemoes.dk]
> > > > Sent: Monday, January 05, 2015 6:27 PM
> > > >
> > > > On Mon, Jan 05 2015, "Zheng, Lv" <lv.zheng@intel.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > >> From: Rasmus Villemoes [mailto:linux@rasmusvillemoes.dk]
> > > > >> Sent: Friday, December 12, 2014 6:51 PM
> > > > >> To: Zheng, Lv
> > > > >> Cc: Rasmus Villemoes; linux-acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org
> > > > >> Subject: [PATCH 3/3] ACPICA: Remove use of __DATE__ macro
> > > > >>
> > > > >> The macro __DATE__ and friends is not allowed in the kernel. Also,
> > > > >> including the build time in output doesn't seem to provide any value.
> > > > >>
> > > > >
> > > > > Could you confirm that it is not useful even for the user tools?
> > > > > Please perform the following commands in the kernel source tree
> > > > > 1. stay in tools folder
> > > > > 2. type "make acpi"
> > > > > 3. type "./power/acpi/acpidump -v"
> > > > >
> > > >
> > > > Yeah, it's part of the output, but for what reason? What can userspace
> > > > possibly use that information for?
> > >
> > > I also want to know.
> >
> > I don't see a reason for userspace to know the build date.
> >
> > >
> > > > I can see some utility in printing a
> > > > version number, since that may tell something about the features
> > > > present or absent. The compilation date, on the other hand, seems
> > > > completely useless. Different distros may ship different versions which
> > > > happened to be compiled on the same day, or older versions compiled later.
> > >
> > > If the deletion was done for this reason, IMO, it's acceptable.
> > > So let's wait to see others' feedback.
> > >
> >
> > I'm okay with removing it (the build date) in Linux and ACPICA as well. However
> > the version, which is essentially the release date, is important for the exact
> > reasons already stated.
> >
> > Dave
> _______________________________________________
> Devel mailing list
> Devel@acpica.org
> https://lists.acpica.org/mailman/listinfo/devel

Re: [PATCH 1/3] checkpatch: Check for use of disallowed macros

[Joe Perches]

On Fri, 2014-12-12 at 11:51 +0100, Rasmus Villemoes wrote:
> Since fe7c36c7 ("Makefile: Build with -Werror=date-time if the
> compiler supports it"), use of __DATE__, __TIME__, __TIMESTAMP__ has
> been disallowed. This hasn't prevented a few new users from creeping
> in. Make checkpatch complain.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -3008,6 +3008,12 @@ sub process {
>  		$line =~ s@//.*@@;
>  		$opline =~ s@//.*@@;
>  
> +
> +# Use of __DATE__, __TIME__, __TIMESTAMP__ is not allowed
> +		if ($line =~ m/\b__(?:DATE|TIME|TIMESTAMP)__\b/) {
> +		    ERROR("DATETIME", "Do not use the macros __DATE__, __TIME__ and __TIMESTAMP__\n" . $herecurr)

I'd probably add that adjacent to the existing __FUNCTION__
test near line 5000 and make the test show the specific macro
used.

Maybe add __LINE__ and __FILE__ as a separate --strict test too.

Also the error message should should show the specific macro and
if __DATE__ and __TIME__ are on the same line, the error should
be emitted twice.

Maybe:
		while ($line =~ /\b(__(?:DATE|TIME|TIMESTAMP)__)\b/g) {
			ERROR("DATETIME",
			      "Do not use the $1 macro\n" . $herecurr);
		}
 

Re: [PATCH 1/3] checkpatch: Check for use of disallowed macros

[Rasmus Villemoes]

On Fri, Dec 12 2014, Joe Perches <joe@perches.com> wrote:

> On Fri, 2014-12-12 at 11:51 +0100, Rasmus Villemoes wrote:
>> Since fe7c36c7 ("Makefile: Build with -Werror=date-time if the
>> compiler supports it"), use of __DATE__, __TIME__, __TIMESTAMP__ has
>> been disallowed. This hasn't prevented a few new users from creeping
>> in. Make checkpatch complain.
>> +
>> +# Use of __DATE__, __TIME__, __TIMESTAMP__ is not allowed
>> +		if ($line =~ m/\b__(?:DATE|TIME|TIMESTAMP)__\b/) {
>> +		    ERROR("DATETIME", "Do not use the macros __DATE__, __TIME__ and __TIMESTAMP__\n" . $herecurr)
>
> I'd probably add that adjacent to the existing __FUNCTION__
> test near line 5000 and make the test show the specific macro
> used.

Yeah, that makes sense. I didn't really know where to put it.

> Maybe add __LINE__ and __FILE__ as a separate --strict test too.

Are those also disallowed, or is it just that new users shouldn't be
added?

> Also the error message should should show the specific macro and
> if __DATE__ and __TIME__ are on the same line, the error should
> be emitted twice.
>
> Maybe:
> 		while ($line =~ /\b(__(?:DATE|TIME|TIMESTAMP)__)\b/g) {
> 			ERROR("DATETIME",
> 			      "Do not use the $1 macro\n" . $herecurr);
> 		}

Looks good to me. I could resend, but can't really claim
authorship. Joe, mind taking it from here?

Rasmus

Re: [PATCH 1/3] checkpatch: Check for use of disallowed macros

[Joe Perches]

On Thu, 2014-12-18 at 22:15 +0100, Rasmus Villemoes wrote:
> On Fri, Dec 12 2014, Joe Perches <joe@perches.com> wrote:
> > On Fri, 2014-12-12 at 11:51 +0100, Rasmus Villemoes wrote:
> >> Since fe7c36c7 ("Makefile: Build with -Werror=date-time if the
> >> compiler supports it"), use of __DATE__, __TIME__, __TIMESTAMP__ has
> >> been disallowed. This hasn't prevented a few new users from creeping
> >> in. Make checkpatch complain.
> >> +
> >> +# Use of __DATE__, __TIME__, __TIMESTAMP__ is not allowed
> >> +		if ($line =~ m/\b__(?:DATE|TIME|TIMESTAMP)__\b/) {
> >> +		    ERROR("DATETIME", "Do not use the macros __DATE__, __TIME__ and __TIMESTAMP__\n" . $herecurr)
> >
> > I'd probably add that adjacent to the existing __FUNCTION__
> > test near line 5000 and make the test show the specific macro
> > used.
> 
> Yeah, that makes sense. I didn't really know where to put it.
> 
> > Maybe add __LINE__ and __FILE__ as a separate --strict test too.
> 
> Are those also disallowed, or is it just that new users shouldn't be
> added?

I'm not advocating removing existing __FILE__/__LINE__ uses.

I do think __FILE__ and __LINE__ aren't particularly useful.
__FILE__ in particular is overly verbose.

> > Also the error message should should show the specific macro and
> > if __DATE__ and __TIME__ are on the same line, the error should
> > be emitted twice.
> >
> > Maybe:
> > 		while ($line =~ /\b(__(?:DATE|TIME|TIMESTAMP)__)\b/g) {
> > 			ERROR("DATETIME",
> > 			      "Do not use the $1 macro\n" . $herecurr);
> > 		}
> 
> Looks good to me. I could resend, but can't really claim
> authorship. Joe, mind taking it from here?

Your idea, your patch.

I'll add an "original-patch-by:" signature tag
and I'll forward something to Andrew later.

checkpatch: Emit an error when using predefined timestamp macros

[Joe Perches]

Since commit fe7c36c7bde1 ("Makefile: Build with -Werror=date-time if
the compiler supports it"), use of __DATE__, __TIME__, and __TIMESTAMP__
has not been allowed.

As this test is gcc version specific (> 4.9), it hasn't prevented a few
new uses from creeping into the kernel sources.

Make checkpatch complain about them.

Original-patch-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Joe Perches <joe@perches.com>
---
 scripts/checkpatch.pl | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f0bb6d6..501c286 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5089,6 +5089,12 @@ sub process {
 			}
 		}
 
+# check for uses of __DATE__, __TIME__, __TIMESTAMP__
+		while ($line =~ /\b(__(?:DATE|TIME|TIMESTAMP)__)\b/g) {
+			ERROR("DATE_TIME",
+			      "Use of the '$1' macro makes the build non-deterministic\n" . $herecurr);
+		}
+
 # check for use of yield()
 		if ($line =~ /\byield\s*\(\s*\)/) {
 			WARN("YIELD",