On 08/03/10 17:00, Giuseppe Scrivano wrote:
> + if (alloc_off - (off_t) (size_t) alloc_off
> + || (size_t) alloc_off + 1 < (size_t) alloc_off)
> +break;
It would be clearer without the casts. (Casts are often
overkill in C; they disable too much checking.) Also, I'm still
On 07/29/10 13:54, Eric Blake wrote:
>> +trap remove_tmp_ 0
>
> Good catch. I'll apply your patch upstream in gnulib soon.
Thanks for doing that. I installed this into the gzip source code.
Bruno, Paul,
I have followed your suggestions and amended them in the patch.
It rollbacks to the previous code and reads from the stream on
overflows.
Also, as suggested, I have added another check for overflow in the
existing code.
Thanks,
Giuseppe
>From c0f45017bded0d958ec430a54b1fb1b29098
On 4 August 2010 00:17, Karl Berry wrote:
>
> two real arguments in favour
> of regex.texi are:
> - It less Makefile rules to use it directly, and regex.h changes rarely
> enough.
>
> These days, I agree with that. I think the simplicity of having the doc
> not be generated outw
Hi Paul,
> > Here is the generalization of 'strxfrm' to strings with embedded NUL bytes.
>
> Sorry, I didn't really notice this email until just now. As it happens,
> coreutils has had an memxfrm implementation since 2006, which
> it never exported to gnulib.
And I'm sorry that I overlooked you
On 08/03/10 15:17, Bruno Haible wrote:
>> > and errno should be set to ENOMEM if overflow occurs.
> I disagree. In this case there's likely something fishy with the fstat
> results, and it's better to start reading from the stream, like for
> non-regular files.
Hmm, well, it could happen when read
two real arguments in favour
of regex.texi are:
- It less Makefile rules to use it directly, and regex.h changes rarely
enough.
These days, I agree with that. I think the simplicity of having the doc
not be generated outweighs the automatic sync-ing. (Back in time, Kathy
an
[resent because the gnu.org mail server was not working right for a short
while yesterday]
Hello Reuben,
Paolo Bonzini wrote:
> But Bruno is the doc guru.
Actually, Karl is in a much better position to comment here: He is the doc
guru, and he wrote part of the regex manual himself.
> The first
Hi Giuseppe,
> + long pos = ftell (stream);
> + if (pos < 0)
> +return NULL;
Not every regular file is seekable (think of files under /proc
on Linux). Therefore, of 'ftello' fails, it's better to not pre-allocate
a buffer but start reading from the stream, like for non-regular f
On 08/03/10 13:05, Giuseppe Scrivano wrote:
> + long pos = ftell (stream);
This isn't reliable on modern 32-bit hosts. Please use
ftello rather than ftell, as ftell is obsolete. You'll
need to alter the module to depend on the ftello module.
> + alloc = st.st_size - pos + 1;
The assi
Hi Paul,
Paul Eggert writes:
> Surely this would be much, much slower if the file seeks slowly,
> for example, if it is a tape drive.
>
> It might be helpful to use fstat to find the file's type and size,
> and to subtract the current file offset from its size
> (for file types where st_size is
On 2009-03-07 Bruno Haible wrote:
> Paul Eggert has written the module 'memcoll', which generalizes the 'strcoll'
> function to work on strings with embedded NULs.
> Here is the generalization of 'strxfrm' to strings with embedded NUL bytes.
Sorry, I didn't really notice this email until just no
On 08/03/10 06:50, Giuseppe Scrivano wrote:
> if ((pos = fseek (stream, 0, SEEK_CUR)) == 0)
Surely this would be much, much slower if the file seeks slowly,
for example, if it is a tape drive.
It might be helpful to use fstat to find the file's type and size,
and to subtract the current file offs
Hi,
while using the read-file module, I found it can be optimized on
seekable files using the the file length as the initial buffer size; it
avoids some unnecessary reallocations.
Cheers,
Giuseppe
>From 41bc1ff07e437f524cf6cf235b9017aca1ed8a6a Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
14 matches
Mail list logo
