Bruno Haible wrote:
>> Before embarking on changes to (or duplication of) infrastructure like
>> the *at functions, please tell us about your motivation. Why do you care
>> about whether openat may abort under unusual circumstances
>
> The reason is so that libposix can offer openat() and getcwd()
On 01/12/2011 03:25 AM, Bastien ROUCARIES wrote:
>> And, rather than checking != ENOTSUP, it might be safer to check ==
>> ENOMEM, so that you are minimizing the impact of your change. The whole
>> point of patch 3 appears to be avoiding the risk of the fchdir()
>> fallback on the rare systems whe
Le mardi 11 janvier 2011 19:36:36, Eric Blake a écrit :
> On 01/11/2011 10:50 AM, Bastien ROUCARIES wrote:
> > I have also corrected a bug openat not testing NULL path. I return EFAULT
> > like my Linux here.
>
> I disagree with this change.
[...]
> :), and we are not in a position to check for
On 01/11/11 12:38, Jim Meyering wrote:
> That looks fine. Thanks!
OK, thanks, on further inspection I found one problem with it:
save-cwd needs to depend on getcwd, for portability to hosts
with inadequate getcwd implementations. So I pushed
this slightly-different patch with that in mind.
>Fro
Paul Eggert wrote:
> On 01/11/11 12:38, Jim Meyering wrote:
>> That looks fine. Thanks!
>
> OK, thanks, on further inspection I found one problem with it:
> save-cwd needs to depend on getcwd, for portability to hosts
> with inadequate getcwd implementations. So I pushed
> this slightly-different
Paul Eggert wrote:
> On 01/11/11 12:16, Jim Meyering wrote:
>> save-cwd uses xgetcwd, which calls xalloc_die.
>
> Thanks for tracking that down. How about this revised patch
> instead? It also fixes the ChangeLog along the lines of your
> previous email.
>
>>From 47ea09cc55b49fa027b7f66e15cb5e70e
On 01/11/11 12:16, Jim Meyering wrote:
> save-cwd uses xgetcwd, which calls xalloc_die.
Thanks for tracking that down. How about this revised patch
instead? It also fixes the ChangeLog along the lines of your
previous email.
>From 47ea09cc55b49fa027b7f66e15cb5e70e7119ee6 Mon Sep 17 00:00:00 200
Eric Blake wrote:
> On 01/11/2011 12:08 PM, Paul Eggert wrote:
>> On 01/11/11 11:03, Eric Blake wrote:
>>> But you should still drop the xmalloc dependency from the module
>>> description.
>>
>> Hmm, sorry, I guess I should have mentioned that I looked for that,
>> and couldn't find the dependency.
Paul Eggert wrote:
> I also don't see the need for all those checks for
> empty strings and the like. Nor do I see the need
> for carefully setting errno = ENOMEM, as the calling
> code will try something else if malloc fails and maybe
> the something else will work and maybe it won't, but
> the c
On 01/11/2011 12:08 PM, Paul Eggert wrote:
> On 01/11/11 11:03, Eric Blake wrote:
>> But you should still drop the xmalloc dependency from the module
>> description.
>
> Hmm, sorry, I guess I should have mentioned that I looked for that,
> and couldn't find the dependency. The only modules that m
On 01/11/11 11:03, Eric Blake wrote:
> But you should still drop the xmalloc dependency from the module
> description.
Hmm, sorry, I guess I should have mentioned that I looked for that,
and couldn't find the dependency. The only modules that mention
lib/openat-proc.c are fdopendir and openat, an
On 01/11/2011 11:58 AM, Eric Blake wrote:
>> char *
>> openat_proc_name (char buf[OPENAT_BUFFER_SIZE], int fd, char const *file)
>> {
>> @@ -98,7 +99,13 @@ openat_proc_name (char buf[OPENAT_BUFFER_SIZE], int fd,
>> char const *file)
>>else
>> {
>>size_t bufsize = PROC_SELF_FD_N
On 01/11/2011 11:54 AM, Paul Eggert wrote:
> So I propose the following patch instead, which I came up
> with before reading Eric's nice review, but which I
> think agrees with his ideas, and adds the abovementioned
> tweaks.
>
> I haven't pushed this.
>
>>From 0c03ad4d899710d851135e1e72f1821e72f
I also don't see the need for all those checks for
empty strings and the like. Nor do I see the need
for carefully setting errno = ENOMEM, as the calling
code will try something else if malloc fails and maybe
the something else will work and maybe it won't, but
the calling code should set errno ap
On 01/11/2011 10:50 AM, Bastien ROUCARIES wrote:
>
> I have also corrected a bug openat not testing NULL path. I return EFAULT
> like my Linux here.
I disagree with this change. EFAULT is not mandated by POSIX; since
anything you can ever do to trigger an EFAULT (that is, any bad pointer,
not j
Regardless of the openat-die issue, it seems to me that
OPENAT_BUFFER_SIZE (currently 512) is too small. I'd like
OPENAT_BUFFER_SIZE to be 4096, because in that case the entire xmalloc
versus malloc issue would be irrelevant in Linux, because
you can't open a file whose name's length is >= 4096, s
Le mardi 11 janvier 2011 17:16:20, Eric Blake a écrit :
> On 01/11/2011 09:05 AM, Jim Meyering wrote:
> >> BTW do you agree with merging my fist two patch?
> >
> > I haven't looked carefully, but this use of sprintf will
> > dereference NULL when malloc fails:
> >
> > - char *result = (bufsi
On Tue, Jan 11, 2011 at 5:41 PM, Jim Meyering wrote:
> Bastien ROUCARIES wrote:
>> This two patches will allow to remove a xmalloc and bail out early in
>> case of ENOMEM
>>
>> I plan to implement a API reusing openat_permissive()
>>
>> If openat_permissive cwd_errno is NULL use the slow but safe
Bastien ROUCARIES wrote:
> This two patches will allow to remove a xmalloc and bail out early in
> case of ENOMEM
>
> I plan to implement a API reusing openat_permissive()
>
> If openat_permissive cwd_errno is NULL use the slow but safe fork variant
> else use the fchdir variant
Is openat_permissi
On 01/11/2011 09:05 AM, Jim Meyering wrote:
>> BTW do you agree with merging my fist two patch?
>
> I haven't looked carefully, but this use of sprintf will
> dereference NULL when malloc fails:
>
> - char *result = (bufsize < OPENAT_BUFFER_SIZE ? buf : xmalloc
> (bufsize));
> + char *
Bastien,
> BTW do you agree with merging my fist two patch?
This question is to be answered by Jim and Eric, since the 'openat' module
is theirs.
I can only give you hints what I would improve before resubmitting the patches:
- The first patch is incomplete: it provokes a NULL pointer access i
Bastien ROUCARIES wrote:
> On Tue, Jan 11, 2011 at 4:30 PM, Bruno Haible wrote:
>> Hi Jim,
>>
>>> As I tried to explain, there does not seem to be a clean way
>>> to solve the problem
>>
>> I believe the stuff with chdir() is only needed in order to handle special
>> cases like
>> - long directo
On Tue, Jan 11, 2011 at 4:30 PM, Bruno Haible wrote:
> Hi Jim,
>
>> As I tried to explain, there does not seem to be a clean way
>> to solve the problem
>
> I believe the stuff with chdir() is only needed in order to handle special
> cases like
> - long directory and file names that would otherwi
Hi Jim,
> Before embarking on changes to (or duplication of) infrastructure like
> the *at functions, please tell us about your motivation. Why do you care
> about whether openat may abort under unusual circumstances
The reason is so that libposix can offer openat() and getcwd() among the
functi
Le mardi 11 janvier 2011 14:21:59, Jim Meyering a écrit :
> Bastien ROUCARIES wrote:
> > Hi,
> >
> > This two patches will allow to remove a xmalloc and bail out early in
> > case of ENOMEM
> >
> > I plan to implement a API reusing openat_permissive()
> >
> > If openat_permissive cwd_errno is NU
Bastien ROUCARIES wrote:
> Hi,
>
> This two patches will allow to remove a xmalloc and bail out early in
> case of ENOMEM
>
> I plan to implement a API reusing openat_permissive()
>
> If openat_permissive cwd_errno is NULL use the slow but safe fork variant
> else use the fchdir variant
>
> Program
26 matches
Mail list logo
