manual: Correct type in struct timeval/timespec.

* manual/time.texi (Elapsed Time): tv_sec is of type time_t in both
struct timeval and struct timespec.

This matches the implementation and also the relevant standard (checked
C11 for timespec and opengroup for timeval).

(I have signed the FSF papers)

---
 ChangeLog        | 5 +++++
 manual/time.texi | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

On 02/12/2015 12:23 PM, Rüdiger Sonderfeld wrote:
> * manual/time.texi (Elapsed Time): tv_sec is of type time_t in both
> struct timeval and struct timespec.
> 
> This matches the implementation and also the relevant standard (checked
> C11 for timespec and opengroup for timeval).
> 
> (I have signed the FSF papers)

Applied.

As a user-visible issue it requires a bug, and I've filed one for you.

https://sourceware.org/bugzilla/show_bug.cgi?id=17965

Please review the contribution checklist:
https://sourceware.org/glibc/wiki/Contribution%20checklist

> ---
>  ChangeLog        | 5 +++++
>  manual/time.texi | 4 ++--
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/ChangeLog b/ChangeLog
> index cc8f509..42f50c5 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,8 @@
> +2015-02-12  Rüdiger Sonderfeld  <ruediger@c-plusplus.net>
> +
> +	* manual/time.texi (Elapsed Time): tv_sec is of type time_t in
> +	both struct timeval and struct timespec.
> +
>  2015-02-12  Adhemerval Zanella  <azanella@linux.vnet.ibm.com>
>  
>  	* sysdeps/unix/sysv/linux/powerpc/htm.h [TABORT]: Fix encoding for
> diff --git a/manual/time.texi b/manual/time.texi
> index 8a5f94e..a7bf156 100644
> --- a/manual/time.texi
> +++ b/manual/time.texi
> @@ -104,7 +104,7 @@
>  declared in @file{sys/time.h} and has the following members:
>  
>  @table @code
> -@item long int tv_sec
> +@item time_t tv_sec
>  This represents the number of whole seconds of elapsed time.
>  
>  @item long int tv_usec
> @@ -123,7 +123,7 @@
>  declared in @file{time.h} and has the following members:
>  
>  @table @code
> -@item long int tv_sec
> +@item time_t tv_sec
>  This represents the number of whole seconds of elapsed time.
>  
>  @item long int tv_nsec
>

On 02/12/2015 03:12 PM, Carlos O'Donell wrote:
> 
> As a user-visible issue it requires a bug, and I've filed one for you.

Is that why my patch is rejected Carlos?
https://sourceware.org/ml/libc-alpha/2015-02/msg00008.html

Sorry, I'm new here. I did read the checklist. It didn't sound like
my patch required a bug. Are all changes to the manual considered
"user-visible"? I'm not sure what that term encompasses.

Thank you,
William

I don't think we should require bugs filed for changes to the manual.

On 02/12/2015 07:53 PM, J William Piggott wrote:
> 
> On 02/12/2015 03:12 PM, Carlos O'Donell wrote:
>>
>> As a user-visible issue it requires a bug, and I've filed one for you.
> 
> Is that why my patch is rejected Carlos?
> https://sourceware.org/ml/libc-alpha/2015-02/msg00008.html

Not at all. It simply hasn't been reviewed. Nobody rejected your patch.

If it had been rejected the patcwork instances should have been udpated
to reflect that:

https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow

> Sorry, I'm new here. I did read the checklist. It didn't sound like
> my patch required a bug. Are all changes to the manual considered
> "user-visible"? I'm not sure what that term encompasses.

They are user-visible.

Cheers,
Carlos.

On 02/12/2015 09:52 PM, Roland McGrath wrote:
> I don't think we should require bugs filed for changes to the manual.

You're right, it is kind of useless process isn't it.

I guess it depends on how big the manual change is.

For these small fixes it's pretty trivial to see we don't need a bug filed.

It does nicely inflate our fixed bug counts though :}

Cheers,
Carlos.

On Thu, 12 Feb 2015, Roland McGrath wrote:

> I don't think we should require bugs filed for changes to the manual.

Agreed.  I think the expectation to file bugs should only be for issues 
that were bugs in installed code, not documentation, that were 
user-visible in releases.  Not for new features, not for documentation 
issues, not for non-user-visible issues such as cleanups or testsuite 
defects (as opposed to user-visible bugs that happened to be shown up by a 
testsuite failure).  (It can still be useful to file bugs in some such 
cases - for example, to record that a well-defined cleanup is desired but 
you're not working on it - but not required for cleanups, manual issues 
etc. if you're sending the patch and taking charge of pinging it until it 
gets in.)

On Thursday 12 February 2015 15:12:52 Carlos O'Donell wrote: 
> Applied.

Thanks!
 
> As a user-visible issue it requires a bug, and I've filed one for you.
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=17965
> 
> Please review the contribution checklist:
> https://sourceware.org/glibc/wiki/Contribution%20checklist

Sorry about that!

Regards,
Rüdiger