On 12/14/2017 12:25 AM, Tim Rühsen wrote:
Does it fix things to add -Wshorten-64-to-32 to build-aux/gcc-warning.spec and to
build-aux/g++-warning.spec? > No, it doesn't change anything (I am not using
manywarnings.m4).
OK, in that case you should be able to fix the problem by specifying
-Wno-
On 12/13/2017 10:55 PM, Paul Eggert wrote:
> On 12/13/2017 01:32 AM, Tim Rühsen wrote:
>> Now clang throws out an annoying warning about the return value of >
>> timespec_cmp(): > > In file included from wget.c:51: >
> ../lib/timespec.h:94:20: warning: imp
On 12/13/2017 01:32 AM, Tim Rühsen wrote:
Now clang throws out an annoying warning about the return value of > timespec_cmp(): > > In file included from wget.c:51: >
../lib/timespec.h:94:20: warning: implicit conversion loses integer >
precision: 'long' to 'int&
es now (and I expect nobody notices because
>> nobody looks at those warnings any more). So I installed the attached
>> followup.
>
> Oh, yes. Definitely prefer assume. Thanks for the fix.
Now clang throws out an annoying warning about the return value of
timespec_cmp():
In fil
On Sun, Oct 29, 2017 at 4:27 PM, Paul Eggert wrote:
> Jim Meyering wrote:
>>
>> Here's a proposed patch:
>
> I prefer 'assume' to 'assure' here, since it's a low-level time-comparison
> primitive and lots of other code in the module already silently assumes that
> the timestamps are valid. Also, w
untime tests. The rest of the module makes
similar assumptions and there is little point to testing here.
* lib/timespec.h: Include verify.h instead of assure.h.
(timespec_cmp): Use ‘assume’, not ‘assure’.
Also, remove an unnecessary cast to ‘int’, as lots of other
code in this module now causes
On Fri, Oct 27, 2017 at 9:33 PM, Jim Meyering wrote:
> On Mon, Oct 2, 2017 at 6:31 PM, Paul Eggert wrote:
>> On 10/02/2017 06:24 PM, Jim Meyering wrote:
>>>
>>> Given all of the comments on that function, I'd be tempted to suppress
>>> this warning in that function.
>>
>> That would work. Another
se 'assume' calls fancier, to exactly match the
> comments, but I'm not sure it's worth the bother.
Thanks. I prefer that. Here's a proposed patch:
From c587f5cff388417f5c584a7125cc886df9750c9b Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Fri, 27 Oct 2017 21
On 10/02/2017 06:24 PM, Jim Meyering wrote:
Given all of the comments on that function, I'd be tempted to suppress
this warning in that function.
That would work. Another possibility would be to include verify.h and
add something like this to the start of timespec_cmp:
assume (-1 <= a.tv_n
/ls.c: In function 'print_long_format':
./lib/timespec.h:85:11: error: assuming signed overflow does not occur
when simplifying conditional to constant [-Werror=strict-overflow]
return (a.tv_sec < b.tv_sec ? -1
~
: a.tv_
Mats Erik Andersson wrote:
I am now trying to build GNU Shishi with on Debian with gcc-4.7.2
and with the previous gcc-4.4.5. This includes bootstrapping
the source with "manywarnings.m4", etcetera.
However, gcc-4.4.5 fails due to "-Wmissing-prototypes":
Currently, --enable-gcc-warnings requi
d from internal.h:76,
from init.c:23:
../gl/timespec.h:59: warning: no previous prototype for 'timespec_cmp'
../gl/timespec.h:69: warning: no previous prototype for 'timespec_sign'
../gl/timespec.h:84: warning: no previous prototype for 'times
---
ChangeLog |2 +-
lib/timespec.h |7 +++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 31e04e8..0f37252 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,6 +1,6 @@
2011-06-30 Paul Eggert
- * lib/timespec.h (timespec_sign
---
ChangeLog |2 ++
lib/timespec.h |8
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index e68d676..31e04e8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,7 @@
2011-06-30 Paul Eggert
+ * lib/timespec.h (timespec_sign
Paul Eggert <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> Hm, what about modules that use #if constructs in the Include:
>> statement? E.g. mbchar:
>>
>> Include:
>> #if HAVE_WCHAR_H
>> #include "mbchar.h"
>> #endif
>
> Good point.
>
> In that case, perhaps we sho
Simon Josefsson <[EMAIL PROTECTED]> writes:
> Hm, what about modules that use #if constructs in the Include:
> statement? E.g. mbchar:
>
> Include:
> #if HAVE_WCHAR_H
> #include "mbchar.h"
> #endif
Good point.
In that case, perhaps we should be putting "#include" in, consistently?
Paul Eggert <[EMAIL PROTECTED]> writes:
> Is there any rule for whether the Include: sections' lines should
> start with '#include'?
>
> I noticed 34 instances with #include and 276 without, so would it be OK
> to remove the "#include" from those 34 instances, for consistency?
> Here they are:
...
Bruno Haible <[EMAIL PROTECTED]> writes:
> 2007-01-01 Bruno Haible <[EMAIL PROTECTED]>
>
> * modules/settime (Include): Require timespec.h.
> * modules/nanosleep (Include): Likewise.
Thanks, I installed it.
One thing, though:
> Includ
The settime and nanosleep functions are declared in timespec.h; therefore
I think the module descriptions of the corresponding modules should reflect
this. How about this patch, Paul?
2007-01-01 Bruno Haible <[EMAIL PROTECTED]>
* modules/settime (Include): Require time
19 matches
Mail list logo
