Since stdio.in.h no longer uses inline functions, we no longer
need to compile the extern versions.
* lib/stdio.c: Remove.
* modules/stdio (Files): Remove lib/stdio.c.
(lib_SOURCES): Remove.
---
ChangeLog | 7 +++
lib/stdio.c | 3 ---
modules/stdio | 2 --
3 files changed, 7 insertions(+
* lib/unicodeio.c: Do not include ignore-value.h.
(fwrite_success_callback): Use plain fwrite, not ignore_value + fwrite.
* modules/unicodeio (Depends-on): Depend on stdio, not ignore-value.
---
ChangeLog | 5 +
lib/unicodeio.c | 3 +--
modules/unicodeio | 3 +--
3 files changed, 7 i
* lib/strftime.c [FPRINTFTIME]: Do not include ignore-value.h.
(cpy) [FPRINTFTIME]: Use plain fwrite, not ignore_value of fwrite,
since the stdio module arranges to silence that warning now.
* modules/fprintftime (Depends-on): Depend on stdio, not ignore-value.
---
ChangeLog | 8 +++
On 01/03/2013 01:00 PM, Eric Blake wrote:
> in the case libvirt was hitting, multiple files used fwrite,
> which in turn meant multiple linkable entries for rpl_fwrite were
> emitted when linking things together; but because they weren't marked
> 'static', the linker didn't like us.
OK, but surel
On 01/02/2013 07:48 AM, Michael Goffioul wrote:
> On Sun, Dec 23, 2012 at 3:51 PM, Michael Goffioul <
> Someone has finally tested the suggestions under Windows 8. Paolo's
> suggestion works OK, Eli's one does not.
If so, can someone please turn this into an actual git commit, to make
applying it
Simon Josefsson writes:
> Any reason not to do this? I'm unable to reproduce this standalone, but
> this patch resolves a warning from autoreconf in OATH Toolkit.
No objection => pushed.
/Simon
> * modules/stdint-tests (Depends-on): Use AC_REQUIRE.
> ---
> ChangeLog|5 +
>
On 01/03/2013 01:48 PM, Paul Eggert wrote:
> Can't be done in Standard C, as far as I know.
Oh well, not worth it then.
> With GNU C it can be done with __attribute__((__always_inline__)).
>
> Why is it important that it not be a linkable entry point?
At least in the case libvirt was hitting, m
On 01/03/13 12:23, Eric Blake wrote:
> The elided code was not using _GL_EXTERN_INLINE, but _GL_INLINE. They
> have different semantics, but I'm hard-pressed to say _which_ semantics
> are right from just those names.
Standard C semantics. _GL_EXTERN_INLINE is C99/C11 extern inline.
_GL_INILNE
On 01/03/2013 11:16 AM, Paul Eggert wrote:
> Thanks for fixing that. I'm still puzzled about
> why the problem happened with libvirt.
Why libvirt, and not detected elsewhere? Probably because libvirt does
this at configure time:
AH_VERBATIM([FORTIFY_SOURCE],
[/* Enable compile-time and
> "Joel" == Joel Brobecker writes:
Joel> I am not sure I understand what you mean. My suggestion was to
Joel> have libiconv and gnulib use the same value for EILSEQ. As for
Joel> gnulib, it uses an arbitrary value that's fairly large, compared
Joel> to typical values, so it should be distinc
[adding gnulib]
On 01/03/2013 10:10 AM, Burkhardt, Glenn UTAS wrote:
> MINGW32_NT-6.1 BOS0DT-1QLS1R1 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys
> gcc version 4.7.0 (GCC)
> Windows 7 Enterprise SP1
> coreutils-5.97
>
> I noticed this when trying to use the "cp" command in a Clearcase locally
> h
Thanks for fixing that. I'm still puzzled about
why the problem happened with libvirt. It's better now that
stdio doesn't depend on extern-inline, but I worry that whatever
bug the libvirt folks were having with stdio and extern inline
might crop up when extern inline is used in other include fil
The libvirt folks reported[1] a link error of multiple rpl_fwrite
definitions that hits only when optimization and FORTIFY_SOURCE
are both enabled, due to improper use of inline. But since that
particular use of rpl_fwrite exists only to work around a spurious
gcc warning on some versions of glibc
Jim Meyering wrote:
> Joseph S. Myers wrote:
>> On Wed, 2 Jan 2013, Eric Blake wrote:
>>
>>> The original was:
>>>
>>>Copyright (C) 1995,97,99 Free Software Foundation, Inc.
>>>
>>> and that pattern (4-digits followed by 2-digits, with gaps in the years,
>>> but no spaces in the listing) is not
From: "Gary V. Vaughan"
Now, when the new 'Omit-from-ChangeLog: Yes' tag is found in a commit
log entry, after git-log-fix edits have been applied, don't output
anything into the ChangeLog for that entry.
* bulid-aux/gitlog-to-changelog: Omit-from-ChangeLog is
a new log entry tag to skip legitim
From: "Gary V. Vaughan"
Move the code for printing header lines inside the else clause of
the empty commit message warning if... so you either get a warning,
or you get the ChangeLog header followed by the non-empty commit
message.
* build-aux/gitlog-to-changelog: When there is no commit message
On occasions, it's possible to end up with a bunch of duplicate
entries in the git log - which is fine and proper there, but no so
good in the gitlog-to-changelog generated ChangeLog.
Previously I had been removing them from the ChangeLog with, e.g.
9333e74fc7b76a11ed04a19343eb5dd75a1035f3
#
Joseph S. Myers wrote:
> On Wed, 2 Jan 2013, Eric Blake wrote:
>
>> The original was:
>>
>>Copyright (C) 1995,97,99 Free Software Foundation, Inc.
>>
>> and that pattern (4-digits followed by 2-digits, with gaps in the years,
>> but no spaces in the listing) is not currently tested in the
>> up
18 matches
Mail list logo
