[LTP] [PATCH] Remove unneeded time() declaration.

[LTP] [PATCH] Remove unneeded time() declaration.

[Steve Ellcey]

The 'extern long time()' declaration conflicts with time.h which
declares time() to be of type time_t which may or may not be long.
This declaration causes a build failure on x86_64 if the file is
compiled with the -mx32 flag.  The time() function does not appear
to be used anywhere in fcntl14 so I am not sure why the declaration
is there anyway.
---
 testcases/kernel/syscalls/fcntl/fcntl14.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/testcases/kernel/syscalls/fcntl/fcntl14.c b/testcases/kernel/syscalls/fcntl/fcntl14.c
index c61eb24..1799084 100644
--- a/testcases/kernel/syscalls/fcntl/fcntl14.c
+++ b/testcases/kernel/syscalls/fcntl/fcntl14.c
@@ -775,8 +775,6 @@ void dochild(void)
 
 void run_test(int file_flag, int file_mode, int seek, int start, int end)
 {
-	extern long time();
-
 	fail = 0;
 
 	for (test = start; test < end; test++) {
-- 
2.7.4

[LTP] [PATCH] Remove unneeded time() declaration.

[Cyril Hrubis]

Hi!
> The 'extern long time()' declaration conflicts with time.h which
> declares time() to be of type time_t which may or may not be long.
> This declaration causes a build failure on x86_64 if the file is
> compiled with the -mx32 flag.  The time() function does not appear
> to be used anywhere in fcntl14 so I am not sure why the declaration
> is there anyway.

This is obviously correct, but the patch misses the Signed-of-by: line.

Also usually the first line of the patch describes what testcase it
fixes so it should have been something like:

syscalls/fcntl14: Remove unneeded time() declaration.

Can you please resend with fixed commit description?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [PATCH] Remove unneeded time() declaration.

[Steve Ellcey]

On Wed, 2017-03-01 at 13:46 +0100, Cyril Hrubis wrote:
> Hi!
> > 
> > The 'extern long time()' declaration conflicts with time.h which
> > declares time() to be of type time_t which may or may not be long.
> > This declaration causes a build failure on x86_64 if the file is
> > compiled with the -mx32 flag.  The time() function does not appear
> > to be used anywhere in fcntl14 so I am not sure why the declaration
> > is there anyway.
> This is obviously correct, but the patch misses the Signed-of-by:
> line.
> 
> Also usually the first line of the patch describes what testcase it
> fixes so it should have been something like:
> 
> syscalls/fcntl14: Remove unneeded time() declaration.
> 
> Can you please resend with fixed commit description?

I updated the comments and resent the patch using format-patch and
send-email.  I am not sure if that is the right way to do it but I
don't see any way to use format-patch/send-email to resend the patch as
a response to your email so I sent it as a new email/thread.  The
inability (as far as I know) to update the patch and send it as a
response to an existing email thread is one of the reasons I am not a
huge fan of those tools but if that is how you want it done, I will do
it that way.

Steve Ellcey

[LTP] [PATCH] Remove unneeded time() declaration.

[Cyril Hrubis]

Hi!
> I updated the comments and resent the patch using format-patch and
> send-email. ??I am not sure if that is the right way to do it but I
> don't see any way to use format-patch/send-email to resend the patch as
> a response to your email so I sent it as a new email/thread. ??The
> inability (as far as I know) to update the patch and send it as a
> response to an existing email thread is one of the reasons I am not a
> huge fan of those tools but if that is how you want it done, I will do
> it that way.

The usuall way is to send new version of a patchset as new thread,
ideally adding vN to the subject where N is number that increases with
each iteration.

And yes, the git-send-email is tailored to specific workflow so as far
as the workflow works for particular project, everything works great.

But the same goes for GitHub, I do not like the workflow their tools are
tailored for, but I still use them when needed. And quite possibly I do
not like it since I'm still much more used to sending patches by
email...

Anyway all that matters in the end is that patches gets applied :-).

-- 
Cyril Hrubis
chrubis@suse.cz