On 01/04/13 18:25, Eric Blake wrote:
> On 01/04/2013 05:47 PM, Bruce Korb wrote:
>> You may have been thinking you were using "memcpy", but you were
>> using "bcopy" instead. Please apply the patch to md5.c. Thanks!
>
> Rather than fixing the call site of memcpy, we should instead fix the
> real
On 01/04/2013 05:47 PM, Bruce Korb wrote:
> You may have been thinking you were using "memcpy", but you were
> using "bcopy" instead. Please apply the patch to md5.c. Thanks!
>
Rather than fixing the call site of memcpy, we should instead fix the
real bug, the fact that you are even doing *ifnd
You may have been thinking you were using "memcpy", but you were
using "bcopy" instead. Please apply the patch to md5.c. Thanks!
$ gcc -c shar-i.c
shar-i.c: In function 'md5_process_bytes':
shar-i.c:3087:13: error: invalid use of void expression
1034 extern void bcopy (__const void *__src,
>>
>> There's no particular reason for having a nested call there anyway.
>
> But there's also no particular reason why we should avoid it, unless we
> know more about which environment is broken if we don't avoid it, since
> as written, it is standards-compliant code.
P.S. Just because code i
On 01/04/13 16:17, Bruce Korb wrote:
>>> This fixes it:
>>>
>>> 261 memcpy (ctx->buffer, buffer, 64);
>>> 262 md5_process_block (ctx->buffer, 64, ctx);
>>>
>>> There's no particular reason for having a nested call there anyway.
$ gcc --version ; uname -a ; /lib/glib
On 01/04/13 15:38, Bruce Korb wrote:
> On 01/04/13 15:27, Bruce Korb wrote:
>> This fixes it:
>>
>> 261 memcpy (ctx->buffer, buffer, 64);
>> 262 md5_process_block (ctx->buffer, 64, ctx);
>>
>> There's no particular reason for having a nested call there anyway.
>>
>
[adding gnulib]
On 01/04/2013 04:39 PM, Karl Berry wrote:
> (Continuing on from 13358).
>
> It seems you're using an older version,
>
> So I was. Argh.
>
> as Jim already did this:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=26db95c
>
> He replaced @acronym. @sc s
On 01/04/2013 04:27 PM, Bruce Korb wrote:
> In file included from shar.c:55:0:
> ../lib/md5.c: In function 'md5_process_bytes':
> ../lib/md5.c:261:13: error: invalid use of void expression
What platform and compiler produced this message? Do you have a bug
where your platform's memcpy() returns
On 01/04/13 15:21, Bruce Korb wrote:
> On 01/04/13 12:47, Paul Eggert wrote:
>> On 01/03/2013 08:30 AM, Petr Písař wrote:
>>> 4.13.1 release replaced SWAP() macro with function.
>>
>> The 4.13.1 release shipped with an obsolete version of md5.c and md5.h,
>> which (as you saw) has some problems. I
On 01/04/13 15:27, Bruce Korb wrote:
> This fixes it:
>
> 261 memcpy (ctx->buffer, buffer, 64);
> 262 md5_process_block (ctx->buffer, 64, ctx);
>
> There's no particular reason for having a nested call there anyway.
>
>From 200eb0ed19376b71f4ca8706c1db83be21a5937
On 01/04/2013 11:52 AM, Jim Meyering wrote:
> I would be happy with that.
OK, I pushed this:
---
ChangeLog | 3 +++
lib/strftime.c | 9 -
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index da4a068..f036ac1 100644
--- a/ChangeLog
+++ b/ChangeLog
On 01/04/2013 08:44 AM, Eric Blake wrote:
> Do we even
> know of platforms where fwrite will fail on ENOMEM without setting the
> error indicator?
I don't know of any, no. I am assuming Jim ran into one
at some point, but if we don't know of any, perhaps we should
leave the code alone, and just
Paul Eggert wrote:
> On 01/04/2013 08:44 AM, Eric Blake wrote:
>
>> Do we even
>> know of platforms where fwrite will fail on ENOMEM without setting the
>> error indicator?
>
> I don't know of any, no. I am assuming Jim ran into one
> at some point, but if we don't know of any, perhaps we should
On 01/04/2013 09:36 AM, Paul Eggert wrote:
> Instead of putting back that comment about the bug,
> how about fixing the bug? Something like the following.
>
> Or perhaps a fix should be put into stdio.in.h so that
> all gnulib programs can assume glibc behavior here,
> for fwrite? Though this wo
Instead of putting back that comment about the bug,
how about fixing the bug? Something like the following.
Or perhaps a fix should be put into stdio.in.h so that
all gnulib programs can assume glibc behavior here,
for fwrite? Though this would mean using an extern
function, something that cause
On 01/04/2013 07:58 AM, Christian Egli wrote:
> Hi all
>
> The liblouis[1] project uses the getopt-gnu, progname and version-etc
> modules from gnulib.
>
> We have a developer on CentOS 5.8 who can no longer compile. Make fails
> in getopt.h with the following error message:
>
>> In file include
Hi all
The liblouis[1] project uses the getopt-gnu, progname and version-etc
modules from gnulib.
We have a developer on CentOS 5.8 who can no longer compile. Make fails
in getopt.h with the following error message:
> In file included from /usr/include/unistd.h:837,
> from ./uni
Paul Eggert wrote:
> On 01/04/2013 12:58 AM, Jim Meyering wrote:
>> AFAIK, that comment is still valid
>
> I can put the comment back but I'd like to word it
> so that I understand it -- currently I don't.
>
> Could you explain a bit more about the problem?
> First, I just now reread the C99 stand
On 01/04/2013 12:58 AM, Jim Meyering wrote:
> AFAIK, that comment is still valid
I can put the comment back but I'd like to word it
so that I understand it -- currently I don't.
Could you explain a bit more about the problem?
First, I just now reread the C99 standard as well
as POSIX-1.2008, and
Paul Eggert wrote:
> * 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.
...
> -
20 matches
Mail list logo
