Remove unneeded time() declaration.

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(-)

index c61eb24..1799084 100644
@@ -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

Hi!

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
[email protected]

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

Hi!

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
[email protected]