On 7/27/22 12:27, Bruno Haible wrote:
We had this discussion already in Feb 2020:
Oh, thanks for reminding me; I'd quite forgotten.
what we need is not to add more 'restrict' here and
there, but rather an understandable (and still correct) explanation of
what 'restri
On Wed, 2022-07-27 at 21:27 +0200, Bruno Haible wrote:
> [Removing coreutils from CC.]
> Paul Eggert wrote:
> > Thanks for the bug report. It's clearly a bug in 'touch'. I
> > installed
> > the attached patch into Coreutils master on Savannah.
>
> It&
[Removing coreutils from CC.]
Paul Eggert wrote:
> Thanks for the bug report. It's clearly a bug in 'touch'. I installed
> the attached patch into Coreutils master on Savannah.
It's good to see that the 'restrict' annotations that we discussed in
February
ol parse_datetime (struct timespec *restrict,
char const *,
struct timespec const *);
gnulib/lib/parse-datetime.h should have this:
bool parse_datetime (struct timespec *restrict,
char const *restrict,
struct
Hi everyone,
I'm currently working on new warnings for gcc's -fanalyzer. I've
implemented a version of Wrestrict inside the analyzer, using its
region model to detect more cases of overlapping buffers in memcpy and
aliases to restrict-qualified parameters. While testing my new war
Paul Eggert wrote:
> >https://savannah.gnu.org/bugs/index.php?59276
>
> As I understand it, the problem here is that Gnulib-using C++ code can't use
> 'restrict' as an identifier.
No, that is not even the problem: The groff source code does not use '
On 10/24/20 7:24 AM, Ingo Schwarze wrote:
https://savannah.gnu.org/bugs/index.php?59276
As I understand it, the problem here is that Gnulib-using C++ code can't use
'restrict' as an identifier. This is worth documenting so I installed the
attached patch. It's low pr
Hello,
i'd like to give you a heads-up regarding a swarm of bugs in gnulib
related to the C99 "restrict" keyword. I first sent this report
directly to Bruno Haible because, as far as i can see, he was the
last one to add a new bug to that swarm, in this
Jens Rehsack wrote:
> When cross compiling for a system without getloadavg, do not try add
> additional linker paths unless it's absolutely necessary.
>
> Signed-off-by: Jens Rehsack
> ---
> m4/getloadavg.m4 | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/m4/getloadavg.m4 b/m4/getlo
On 2/22/20 4:51 PM, Bruno Haible wrote:
Here comes the first part: the 'restrict' in the POSIX function declarations.
Note that the POSIX declarations of posix_spawn and posix_spawnp [1] are
incorrect: They lack a 'restrict' for the file_actions argument.
[1] https:
When cross compiling for a system without getloadavg, do not try add
additional linker paths unless it's absolutely necessary.
Signed-off-by: Jens Rehsack
---
m4/getloadavg.m4 | 3 +++
1 file changed, 3 insertions(+)
diff --git a/m4/getloadavg.m4 b/m4/getloadavg.m4
index 3bd2a142e..696c5de90 10
This patch, finally, makes use of 'restrict' also in the libunistring header
files.
2020-02-23 Bruno Haible
uni*/base: Use 'restrict'.
* lib/unitypes.in.h (_UC_RESTRICT): New macro, based on '_Restrict_'
from lib/regex.h.
* li
Here comes the second part: Use of 'restrict' in non-POSIX function
declarations, excluding libunistring code.
2020-02-23 Bruno Haible
crypto/gc: Use 'restrict'.
* lib/gc.h (gc_pbkdf2_hmac, gc_pbkdf2_sha1): Use 'restrict'.
* m4/gc.m4
Here comes the first part: the 'restrict' in the POSIX function declarations.
Note that the POSIX declarations of posix_spawn and posix_spawnp [1] are
incorrect: They lack a 'restrict' for the file_actions argument.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functi
roduce a warning any more:
Interesting. I don't see why GCC doesn't warn there.
GCC's heuristics for generating warnings must be even trickier than what's in
the C standard about 'restrict' - which is another reason not to base code off
when exactly GCC warns.
Ac
Thanks to Paul and all for the enlightening discussion about what 'restrict'
actually means.
What I intend to do it gnulib is:
* In the function *definitions*, do not use 'restrict' at all.
Rationale:
- Gnulib code is not time-critical.
Hi Tim,
> > Yes, and this in turn means that the ability to produce useful warnings via
> > 'restrict' is limited. In this example:
> > ===
> > #include
> > extern void memmcpy (void
Hi Paul,
> > I'm after warnings that point to undefined behaviour, and since passing a
> > 'char *' in place of an 'unsigned char *', 'FILE *', or similar already
> > generates a compiler warning, using 'restrict' here does not offe
On 2/16/20 3:49 PM, Bruno Haible wrote:
I'm after warnings that point to undefined behaviour, and since passing a
'char *' in place of an 'unsigned char *', 'FILE *', or similar already
generates a compiler warning, using 'restrict' here does no
On 2/17/20 4:53 AM, Bruno Haible wrote:
> Paul Eggert wrote:
>> if GCC generated warnings for that sort of thing, the warnings would be false
>> alarms.
>
> Yes, and this in turn means that the ability to produce useful warnings via
> 'restrict
Paul Eggert wrote:
> if GCC generated warnings for that sort of thing, the warnings would be false
> alarms.
Yes, and this in turn means that the ability to produce useful warnings via
'restrict' is limited.
On 2/16/20 4:14 PM, Bruno Haible wrote:
I thought that passing pointers to different elements of the same array
would produce warnings. But I was mistaken: This code does NOT produce warnings.
Yes, and I don't see why such code has undefined behavior, as long as the
function doesn't actually a
Addendum:
> > >- 'restrict' should NOT be used for multiple output parameters of the
> > > same type, when only a single word is written through each parameter.
> > > Example: ssize_t copy_file_range (int ifd, off
Hi Paul,
Thanks a lot for your comments.
> >- If all pointer parameters point to different types, excluding 'void *',
> > ISO C forbids aliasing anyway, therefore 'restrict' is redundant.
>
> The actual ISO C rule is a bit different, sin
On 2/9/20 7:02 PM, Bruno Haible wrote:
- If all pointer parameters point to different types, excluding 'void *',
ISO C forbids aliasing anyway, therefore 'restrict' is redundant.
The actual ISO C rule is a bit different, since it allows aliasing between '
On 2/10/20 4:02 AM, Bruno Haible wrote:
> Tim Rühsen wrote:
>> gcc -Wall tells you so (gcc 8 and upwards):
>> $ gcc -Wall msg.c -o msg
>> msg.c: In function ‘main’:
>> msg.c:11:13: warning: passing argument 1 to restrict-qualified parameter
>> aliases with
On Sun, Feb 9, 2020 at 10:03 PM Bruno Haible wrote:
> ...
> Which function declarations could therefore profit from the 'restrict'
> keyword?
[SNIP ...]
I think the case of interest is subobjects of arrays:
char a[] = "Hello World";
char* b = a+5;
m
Tim Rühsen wrote:
> gcc -Wall tells you so (gcc 8 and upwards):
> $ gcc -Wall msg.c -o msg
> msg.c: In function ‘main’:
> msg.c:11:13: warning: passing argument 1 to restrict-qualified parameter
> aliases with argument 4 [-Wrestrict]
>11 | snprintf (msg, sizeof
The local keyword is very widely supported and used
in tests in coreutils and grep at least. Therefore
restrict to testing with shells that support it.
This mainly excludes /bin/sh on Solaris.
Note standard ksh also doesn't support this keyword,
but that wasn't in the list of conside
On 04/11/2011 12:48 AM, Nikos Mavrogiannopoulos wrote:
> As an unrelated suggestion for memxor.c I had a discussion with
> another project about that and we concluded on a gmp-based
> version that is orders of magnitude faster. It would
> be nice if gnulib included the optimized code by default.
P
On 04/11/2011 12:56 AM, Paul Eggert wrote:
> On 04/10/2011 03:07 PM, Nikos Mavrogiannopoulos wrote:
>> As I understand it AC_C_RESTRICT checks whether restrict
>> is supported by the C compiler. I'm using the C++ compiler.
>
> In that case, AC_C_RESTRICT should repor
you are using.
Paul Eggert wrote:
> In that case, AC_C_RESTRICT should report that your C++
> compiler does not support 'restrict' when compiling C code.
> What goes wrong in that process?
Maybe the problem is that when the same problem occurred in October 2007 [1],
you put
On 04/10/2011 03:07 PM, Nikos Mavrogiannopoulos wrote:
> As I understand it AC_C_RESTRICT checks whether restrict
> is supported by the C compiler. I'm using the C++ compiler.
In that case, AC_C_RESTRICT should report that your C++
compiler does not support 'restrict' when c
_C_RESTRICT, which
> is supposed to arrange for 'restrict' to be #define'd to
> nothing if your compiler doesn't work with 'restrict'.
> Could you please give more details about the problem, and
> explain why the above didn't work?
As I understand it AC_
On 04/10/2011 12:53 AM, Nikos Mavrogiannopoulos wrote:
> Attached is a patch that fixes the time.h compilation under C++.
This shouldn't be needed, since gl_HEADER_TIME_H requires
gl_HEADER_TIME_H_BODY, which requires AC_C_RESTRICT, which
is supposed to arrange for 'restrict'
Attached is a patch that fixes the time.h compilation under C++.
regards,
Nikos
>From 6bdd56fbd4ecad4b00d3bbd76dd343a52622a876 Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos
Date: Sun, 10 Apr 2011 09:51:58 +0200
Subject: [PATCH] Fix compilation issue under C++ due to restrict C qualif
On Sat, 10 Apr 2010, Bruno Haible wrote:
> 2010-04-10 Bruno Haible
>
> * m4/gnulib-common.m4 (AC_C_RESTRICT): Don't define for
> autoconf >= 2.62.
> Reported by Joel E. Denny .
That works for me. Please push. Thanks.
Joel E. Denny wrote:
> That works for me. Please push. Thanks.
Thanks for the confirmation. It's pushed.
Bruno
be assumed.
+m4_if(m4_version_compare(m4_defn([m4_PACKAGE_VERSION]),[2.62]),[-1],[
AC_DEFUN([AC_C_RESTRICT],
[AC_CACHE_CHECK([for C/C++ restrict keyword], [ac_cv_c_restrict],
[ac_cv_c_restrict=no
@@ -169,6 +170,7 @@
*) AC_DEFINE_UNQUOTED([restrict], [$ac_cv_c_restrict]) ;;
esac
])
+])
# gl_BIGENDIAN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok to apply this patch?
>From 44e7c72451c66c1a429bfd24afeabe5b9a9cca64 Mon Sep 17 00:00:00 2001
From: Joel E. Denny
Date: Sat, 10 Apr 2010 02:10:51 -0400
Subject: [PATCH] Fix handling of restrict keyword for newer Sun Studio C++.
* m4/gnu
Hi Simon,
Simon Josefsson wrote:
> Jim Meyering writes:
...
>> I'm using coreutils' maint.mk in 3 or 4 other projects,
>> nearly verbatim. As such, I'm reluctant to remove rules, since
>> that would mean migrating them out to each cfg.mk, which is maintained
>> separately, and thus harder to kee
Jim Meyering writes:
> Simon Josefsson wrote:
>> Reuben Thomas writes:
>>
>>> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>>>
Coreutils doesn't use the gnulib maintainer-makefile module, I believe,
so at minimum it would need a patch that made it use maint.mk from
gnulib.
>>>
>>> O
Simon Josefsson wrote:
> Reuben Thomas writes:
>
>> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>>
>>> Coreutils doesn't use the gnulib maintainer-makefile module, I believe,
>>> so at minimum it would need a patch that made it use maint.mk from
>>> gnulib.
>>
>> Or it could use maintainer-makefile
On Tue, 14 Apr 2009, Simon Josefsson wrote:
So if you have time, please proceed in trying to merge these files. I
am sorry that I have been quite busy and haven't had time to review and
comment. But in general I support your approach.
I'm not bothered about the speed as I'm not in any hurry,
Reuben Thomas writes:
> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>
>> Coreutils doesn't use the gnulib maintainer-makefile module, I believe,
>> so at minimum it would need a patch that made it use maint.mk from
>> gnulib.
>
> Or it could use maintainer-makefile, unless there's some reason why
pretty much reached the end of that particular tedious limitation.
Not even remotely the case.
My request is, please stick to 7-bit ASCII whenever it is all feasible.
Names in ChangeLogs and the like are one thing, but randomly
throwing in UTF-8 (or any other encoding) into email (or source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 4/7/2009 6:32 AM:
>> If you use Bruno's git-merge-changelog program, and attach a
>> .gitattributes notation to your changelog that you do so, then ChangeLog
>> diffs have a high probability of applying correctly,
>
> Tha
Eric Blake wrote:
> According to Jim Meyering on 4/7/2009 2:56 AM:
>> - use ChangeLog-style "* full-relative-name/to-each-affected-file
>> (func,rule,etc.): description..." in the log, because that is what
>> goes into the ChangeLog for gnulib. In coreutils, the log is the
>> primary sour
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 4/7/2009 2:56 AM:
> - use ChangeLog-style "* full-relative-name/to-each-affected-file
> (func,rule,etc.): description..." in the log, because that is what
> goes into the ChangeLog for gnulib. In coreutils, the log i
Reuben Thomas wrote:
...
> Which means I have to configure Emacs specially for writing certain
> files. It's a pain that in a system invented in the last ten years
> (git) UTF-8 is still a second-class citizen.
There's nothing wrong with git's UTF-8 support.
Reuben Thomas wrote:
> On Tue, 7 Apr 2009, Jim Meyering wrote:
>> Didn't you notice how it was harder to read your UTF8-encoded Subject
>> line in what I quoted?
>
> Yes, but that's because you pasted an encoded mail header into your reply.
No, I did not.
You attached the patch as type text/xdiff,
On Tue, 7 Apr 2009, Jim Meyering wrote:
Didn't you notice how it was harder to read your UTF8-encoded Subject
line in what I quoted?
Yes, but that's because you pasted an encoded mail header into your reply. I
normally only read mail headers in an MUA where they are displayed properly.
Are y
Reuben Thomas wrote:
> On Tue, 7 Apr 2009, Jim Meyering wrote:
>> - your summary/subject was needlessly utf8-encoded.
>> That makes it harder to read.
>
> For the sake of one apostrophe. It's a pity, I made Emacs do smart
> quotes in text mode, and now it looks like I need an exception. What'
On Tue, 7 Apr 2009, Jim Meyering wrote:
- your summary/subject was needlessly utf8-encoded.
That makes it harder to read.
For the sake of one apostrophe. It's a pity, I made Emacs do smart quotes in
text mode, and now it looks like I need an exception. What's the problem
with UTF-8 in
Reuben Thomas wrote:
> On Tue, 7 Apr 2009, Jim Meyering wrote:
>> Ok. Post "git format-patch ..." output and I'll push it,
>> unless someone objects in the mean time.
>
> Attached. Let me know if I did something wrong.
>
> (Copyright assignment: I'm assuming that since I didn't write any of
> this
On Tue, 7 Apr 2009, Jim Meyering wrote:
Ok. Post "git format-patch ..." output and I'll push it,
unless someone objects in the mean time.
Attached. Let me know if I did something wrong.
(Copyright assignment: I'm assuming that since I didn't write any of this,
but just made trivial changes,
Reuben Thomas wrote:
> On Mon, 6 Apr 2009, Jim Meyering wrote:
>
>> Ok by me. Though I don't like the use of $(C_SOURCES), as I
>> mentioned. I do understand you're trying to do this gradually. I'd
>> be inclined to make bigger changes ;-) It's only "make
>> syntax-check", after all.
>
> OK, I'm
On Mon, 6 Apr 2009, Jim Meyering wrote:
Ok by me. Though I don't like the use of $(C_SOURCES), as I mentioned.
I do understand you're trying to do this gradually. I'd be inclined to
make bigger changes ;-) It's only "make syntax-check", after all.
OK, I'm just trying to make changes that I
Reuben Thomas wrote:
> On Sat, 4 Apr 2009, Jim Meyering wrote:
>> Reuben Thomas wrote:
>>> On Sat, 4 Apr 2009, Jim Meyering wrote:
>>>
Those buglets were from coreutils' maint.mk.
>>>
>>> Just to be clear, the buglets were from coreutils' maint.mk, but the
>>> patch I sent was a patch to gnuli
On Sat, 4 Apr 2009, Jim Meyering wrote:
Reuben Thomas wrote:
On Sat, 4 Apr 2009, Jim Meyering wrote:
Those buglets were from coreutils' maint.mk.
Just to be clear, the buglets were from coreutils' maint.mk, but the
patch I sent was a patch to gnulib's maint.mk. So your push below:
Subject
Reuben Thomas wrote:
> On Sat, 4 Apr 2009, Jim Meyering wrote:
>
>> Those buglets were from coreutils' maint.mk.
>
> Just to be clear, the buglets were from coreutils' maint.mk, but the
> patch I sent was a patch to gnulib's maint.mk. So your push below:
>
>> Subject: [PATCH] tests: make syntax-che
On Sat, 4 Apr 2009, Jim Meyering wrote:
Those buglets were from coreutils' maint.mk.
Just to be clear, the buglets were from coreutils' maint.mk, but the patch I
sent was a patch to gnulib's maint.mk. So your push below:
Subject: [PATCH] tests: make syntax-checks more robust
is to coreut
Ralf Wildenhues wrote:
> Hello Reuben,
>
> a couple of nits:
Thanks, Ralf.
Those buglets were from coreutils' maint.mk.
Here's what I expect to push in your name:
>From d75bcea4cfc7927535d19d34d8d103621b4a0d6d Mon Sep 17 00:00:00 2001
From: Ralf Wildenhues
Date: Sat, 4 Apr 2009 10:25:18 +0200
Su
Hello Reuben,
a couple of nits:
* Reuben Thomas wrote on Fri, Apr 03, 2009 at 03:57:46PM CEST:
> --- a/top/maint.mk
> +++ b/top/maint.mk
> @@ -38,34 +38,42 @@ GZIP_ENV = '--no-name --best $(gzip_rsyncable)'
> # Doing it here saves us from having to set LC_ALL elsewhere in this file.
> export LC
Reuben Thomas wrote:
> On Fri, 3 Apr 2009, Jim Meyering wrote:
>> I'll take your word that it doesn't change anything.
>> Someone who uses it may want to try it or give it a closer look.
>
> Let me know, and I can do some more work. The next thing I'm
> interested in is adding some more source chec
On Fri, 3 Apr 2009, Jim Meyering wrote:
I'll take your word that it doesn't change anything.
Someone who uses it may want to try it or give it a closer look.
Let me know, and I can do some more work. The next thing I'm interested in
is adding some more source checking rules, particularly thos
Reuben Thomas wrote:
> On Fri, 3 Apr 2009, Reuben Thomas wrote:
>
>> On Wed, 1 Apr 2009, Reuben Thomas wrote:
>>
>>> Would you like to suggest what I should do next to my patch?
>>
>> Not having had a reply, I've come up with my own answer: start with
>> a little bit of merging.
>>
>> What I've don
Reuben Thomas wrote:
> On Wed, 1 Apr 2009, Reuben Thomas wrote:
>
>> Would you like to suggest what I should do next to my patch?
>
> Not having had a reply, I've come up with my own answer: start with a
> little bit of merging.
>
> What I've done so far is to add the macros _prohibit_regexp and
>
On Fri, 3 Apr 2009, Reuben Thomas wrote:
On Wed, 1 Apr 2009, Reuben Thomas wrote:
Would you like to suggest what I should do next to my patch?
Not having had a reply, I've come up with my own answer: start with a little
bit of merging.
What I've done so far is to add the macros _prohibit_
On Wed, 1 Apr 2009, Reuben Thomas wrote:
Would you like to suggest what I should do next to my patch?
Not having had a reply, I've come up with my own answer: start with a little
bit of merging.
What I've done so far is to add the macros _prohibit_regexp and
_header_without_use to gnulib's
Simon Josefsson wrote:
> Reuben Thomas writes:
...
>>> 4. Use of C_SOURCES in sc_* rules.
>>
>> There seems to be a conflict here between coreutils's approach (use a
>> list of exceptions generated from the VCS) and gnulib's (generate a
>> list of files to look at). What do you suggest as a next s
On Wed, 1 Apr 2009, Simon Josefsson wrote:
Coreutils doesn't use the gnulib maintainer-makefile module, I believe,
so at minimum it would need a patch that made it use maint.mk from
gnulib.
Or it could use maintainer-makefile, unless there's some reason why not?
Further, some of the rules in
Reuben Thomas writes:
> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>
>> It will be easier to review if you post patches for gnulib's maint.mk
>> instead of the entire new file.
>
> I'll do that.
Thanks!
>> You may have to patch coreutils maint.mk too, but that could go to
>> bug-coreut...@gnu.o
On Wed, 1 Apr 2009, Simon Josefsson wrote:
It will be easier to review if you post patches for gnulib's maint.mk
instead of the entire new file.
I'll do that.
You may have to patch coreutils maint.mk too, but that could go to
bug-coreut...@gnu.org.
I was hoping to end up with a single file
Reuben Thomas writes:
> On Wed, 1 Apr 2009, Simon Josefsson wrote:
>
>> Reuben Thomas writes:
>>>
>>> Since coreutils' maint.mk seems to be shared with other projects
>>> already, could it not simply be pushed into gnulib as it is? Could
>>> those projects (currently, according to the comments,
On Wed, 1 Apr 2009, Simon Josefsson wrote:
Reuben Thomas writes:
Since coreutils' maint.mk seems to be shared with other projects
already, could it not simply be pushed into gnulib as it is? Could
those projects (currently, according to the comments, "coreutils,
idutils, CPPI, Bison, and Auto
Reuben Thomas writes:
> On Fri, 20 Mar 2009, Simon Josefsson wrote:
>
>> Reuben Thomas writes:
>>
>>> On Fri, 20 Mar 2009, Eric Blake wrote:
>>>
Jim meant coreutil's maint.mk. It is not synced with gnulib's maint.mk,
although several people have expressed interest in resyncing them.
>
On Fri, 20 Mar 2009, Simon Josefsson wrote:
Reuben Thomas writes:
On Fri, 20 Mar 2009, Eric Blake wrote:
Jim meant coreutil's maint.mk. It is not synced with gnulib's maint.mk,
although several people have expressed interest in resyncing them.
Aha! This is surely the sort of rule that sh
Eric Blake wrote:
> According to Reuben Thomas on 3/20/2009 8:10 AM:
>>> Always including first is easy to forget.
>>> You might want to use rules like these from gnulib's maint.mk:
>> I just checked gnulib out from git and I don't find this rule or
>
> Jim meant coreutil's maint.mk.
I sure did.
Reuben Thomas writes:
> On Fri, 20 Mar 2009, Eric Blake wrote:
>
>> Jim meant coreutil's maint.mk. It is not synced with gnulib's maint.mk,
>> although several people have expressed interest in resyncing them.
>
> Aha! This is surely the sort of rule that should be pushed into
> gnulib. Thanks a
On Fri, 20 Mar 2009, Eric Blake wrote:
Jim meant coreutil's maint.mk. It is not synced with gnulib's maint.mk,
although several people have expressed interest in resyncing them.
Aha! This is surely the sort of rule that should be pushed into gnulib.
Thanks anyway.
This problem seems to occ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reuben Thomas on 3/20/2009 8:10 AM:
>> Always including first is easy to forget.
>> You might want to use rules like these from gnulib's maint.mk:
> I just checked gnulib out from git and I don't find this rule or
Jim meant coreutil's ma
On Thu, 19 Mar 2009, Jim Meyering wrote:
Reuben Thomas wrote:
On Wed, 18 Mar 2009, Eric Blake wrote:
Ahh. The bug is in zile, not gnulib.
Ah, thanks very much, and apologies for the noise.
Always including first is easy to forget.
You might want to use rules like these from gnulib's mai
Reuben Thomas wrote:
> On Wed, 18 Mar 2009, Eric Blake wrote:
>
>> Ahh. The bug is in zile, not gnulib.
>
> Ah, thanks very much, and apologies for the noise.
Always including first is easy to forget.
You might want to use rules like these from gnulib's maint.mk:
# Nearly all .c files must incl
Eric Blake wrote:
> That is a no-no when using gnulib. EVERY .c file in your
> project MUST include prior to anything else (or include a
> project-specific .h which in turn includes first).
Yes. This is actually already documented in gnulib's documentation:
http://www.gnu.org/software/gnulib/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 3/18/2009 8:31 PM:
> Ahh. The bug is in zile, not gnulib.
>
> http://git.savannah.gnu.org/cgit/zile.git/tree/src/lists.c
Wow. That was my first experience with cgit instead of gitweb, and I
liked it. When did savannah ad
On Wed, 18 Mar 2009, Eric Blake wrote:
Ahh. The bug is in zile, not gnulib.
Ah, thanks very much, and apologies for the noise.
--
http://rrt.sc3d.org/ | mediate, v.i. to butt in (Bierce)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding bug-zile]
According to Reuben Thomas on 3/18/2009 8:16 PM:
> On Wed, 18 Mar 2009, Eric Blake wrote:
>
>> Did you actually encounter a compilation failure where restrict was
>> improperly defined while using gnulib?
On Wed, 18 Mar 2009, Eric Blake wrote:
Did you actually encounter a compilation failure where restrict was
improperly defined while using gnulib? If so, how do we reproduce it?
It was not on my system, but on a BSD box that Nelson Beebe was kindly
building GNU Zile on for me. A bit of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reuben Thomas on 3/18/2009 7:50 PM:
> string.h uses restrict, which doesn't work if the compiler is C89 (e.g.
> gcc in -std=c89 mode).
>
> regex.h has some code to detect this case and allow for it; should
> string.
string.h uses restrict, which doesn't work if the compiler is C89 (e.g. gcc
in -std=c89 mode).
regex.h has some code to detect this case and allow for it; should string.h
copy this code? Or should it be broken out into a module? (It would be
useful to gnulib users too.)
--
:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Mon, 26 May 2008 19:29:50 +0200
Subject: [PATCH] sha256: do not artificially restrict buffer length to be < 2^32
* lib/sha256.h (struct sha256_ctx) [buflen]: Change type from
uint32_t to size_t.
* lib/sha256.c (sha256_conclude_ctx): Cha
Some modules were using 'restrict' in a declaration in string.h without
ensuring it's properly defined.
2007-05-13 Bruno Haible <[EMAIL PROTECTED]>
* stpcpy.m4 (gl_FUNC_STPCPY): Require AC_C_RESTRICT.
* stpncpy.m4 (gl_FUNC_STPNCPY): Likewise.
* strs
I'm applying this:
2007-03-15 Bruno Haible <[EMAIL PROTECTED]>
* lib/glob.c (glob): Add 'restrict' so that prototype matches the
declared prototype. Needed with cc on OSF/1 5.1.
*** lib/glob.c 22 Feb 2007 23:33:19 - 1.14
--- lib/glob.c 16
Bruno Haible <[EMAIL PROTECTED]> writes:
> Changing the function definition to use ANSI C argument list syntax (without
> adding 'restrict' there) fixes the problem. Changing the function definition
> by adding 'restrict' in the first and fourth argument (keepi
Bruno Haible <[EMAIL PROTECTED]> writes:
> I'm applying this fix. Hope it's ok with you, Simon.
Yup, thanks!
/Simon
Hi Paul,
I didn't know 'restrict' could cause compilation failures, but apparently
it can. On OSF/1 5.1, the 'glob' module gives a compilation failure:
cc -O -DHAVE_CONFIG_H -I. -I.. -c glob.c
cc: Error: glob.c, line 215: In the definition of the function "rp
The declaration of mempcpy() needs 'restrict'. If it's not supported or
defined away, one gets this error on AIX 5.1:
xlc -D_ALL_SOURCE -O -g -o test-alloca-opt test-alloca-opt.o
../gllib/libgnu.a
source='test-argp.c' object='test-argp.o' li
Simon Josefsson <[EMAIL PROTECTED]> writes:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> Hi Simon,
>>
>>> time_.h from the time module uses restrict in the prototypes, but it
>>> doesn't depend on the restrict module. Installed.
>&
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi Simon,
>
>> time_.h from the time module uses restrict in the prototypes, but it
>> doesn't depend on the restrict module. Installed.
>
> The 'restrict' module was removed on 2006-08-09. Now, instead w
1 - 100 of 105 matches
Mail list logo
