Jonas Termansen wrote:
> To recap, my primary requests are:
>
> 1) Categorizing gnulib into three parts (replacement functions for when
> they don't exist, workarounds for bugs, and utility functions).
>
> 2) Making it possible to disable the gnulib bug replacements with a
> configure command
Jonas Termansen wrote:
> > A good example is e.g.
> > cross-compilation. For instance, an old Unix might not have had a broken
> > fork() system call or something. When cross-compiling, gnulib might be
> > pessimistic and default to assuming the system call is broken, which may
> > be handled with
On 9/8/19 2:06 PM, Paul Smith wrote:
Why can't we add
these headers as AC_CONFIG_FILES() and allow them to be generated by
the configure script, instead of requiring makefile rules to do it?
Makefile rules can do things that an Autoconf substitition can't, or at least
can't do easily. For
On 9/8/19 1:58 PM, Bruno Haible wrote:
Well, then we need variants of the *printf functions that return an 'ssize_t'
instead of an 'int'.
Do you happen to know the opinion of the glibc people on this topic?
Sorry, no. I imagine it's come up.
I would suggest ptrdiff_t rather than ssize_t, as
I'm looking at allowing GNU make to use more gnulib facilities, but
I've run into a serious problem.
It seems that a lot of gnulib modules rely on makefile rules added to
Makefile.in to construct files, rather than using traditional configure
replacement .in file conversions.
This is a real
While cross-compiling a gnulib testdir, I see this line in the
configure output:
../configure: line 12368: test: too many arguments
It comes from this line:
if test $gl_cv_func_chown_follows_symlink = no; then
This patch should fix it.
2019-09-08 Bruno Haible
chown: Fix
Paul Eggert wrote:
> The GNU coding standards say to avoid arbitrary limits, and
> on 64-bit platforms we should avoid arbitrary 32-bit limits on the lengths of
> strings.
Well, then we need variants of the *printf functions that return an 'ssize_t'
instead of an 'int'.
Do you happen to know
On 9/8/19 10:08 AM, Bruno Haible wrote:
What do you mean by "asprintf mishandles large buffers"? The fact that an error
occurs if the result is longer than INT_MAX characters? Really, we have data
larger than 2 GB in many places, but *strings* larger than 2 GB?
Sure, in Emacs:
(length
On Sun, 2019-09-08 at 19:48 +0200, Bruno Haible wrote:
> > My suggestion was that BOTH these functions should not assume the CWD
> > if PATH is empty or missing, not that they should behave differently.
>
> OK. But what, do you suggest, should the functions do when confronted to
> an empty path?
Hi Paul,
> > > I find that VERY odd, and possibly a security risk. According to
> > > POSIX, the behavior if PATH is not present or is empty is
> > > implementation-defined and my preference/expectation would be to behave
> > > as if the program is not found. However, that's a different
> > >
On Sun, Sep 8, 2019 at 10:08 AM Bruno Haible wrote:
> So, what we would need is are functions
>
>char * substring (const char *string, size_t length);
>char * concatenated_string2 (const char *string1, size_t length1,
> const char *string2, size_t length2);
On Sun, 2019-09-08 at 16:59 +0200, Bruno Haible wrote:
> Hi Paul,
>
> > > > prog = find_in_path_str ("myprog", lookup_path ());
> > > >
> > > > and if lookup_path() returns NULL it defaults to the environment
> > > > PATH,
> > >
> > > I don't think NULL should be interpreted as "look in the
Jonas Termansen wrote:
> I object to the attitude that code analysis tools should only really be
> supported on glibc systems. A lot of security features are being
> pioneered on other systems and making it easier for everyone to use
> these tools benefits everyone
>
> "Exploit mitigation
Jonas Termansen wrote:
> It's been a while since I looked at the stdio-ext functions, although
> I'm not really sure why they need to exist. At least there is a way to
> satisfy gnulib.
These functions exist
a) to enable important functionality that has been forgotten by the ISO C
Jonas Termansen wrote:
> > Buffer allocation and string production
> > should not be decoupled as it leads to bugs. (Modern languages, such as
> > the one I develop at work, does simply not have these problems.) In C,
> > strdup should be used instead of strlen+malloc+strcpy/memcpy because
> >
Hi Paul,
Here's the implementation I'm committing.
I feel that merging the two functions in a single file would add more
contortions than benefit.
2019-09-08 Bruno Haible
findprog-in: New module.
Suggested by Paul Smith .
* lib/findprog.h (find_in_given_path): New
On Sun, Sep 8, 2019 at 6:06 AM Darshit Shah wrote:
> I just realized that the syntax check rule sc_prohibit_magic_number_exit will
> cause a false positive when it finds the relevant tokens within a string as
> well.
>
> For example, in Wget, we have the following snippet in our tests which trips
Hi Paul,
> > > prog = find_in_path_str ("myprog", lookup_path ());
> > >
> > > and if lookup_path() returns NULL it defaults to the environment
> > > PATH,
> >
> > I don't think NULL should be interpreted as "look in the default
> > PATH". Rather, the convention is that an empty or null
On Sun, 2019-09-08 at 13:38 +0200, Bruno Haible wrote:
> > the path search is done
> > on the _parent's_ PATH environment value not the one passed in to
> > posix_spawnp(). I don't want that, I need the search done in the
> > child's environment. I can't decide if this behavior by
> >
I just realized that the syntax check rule sc_prohibit_magic_number_exit will
cause a false positive when it finds the relevant tokens within a string as
well.
For example, in Wget, we have the following snippet in our tests which trips
this rule:
> WGET_TEST_EXPECTED_FILES, &(wget_test_file_t
Hi Paul,
> I'm addressing https://savannah.gnu.org/bugs/?56834
>
> I want to invoke a child process, and I need the program I'm going to
> invoke to be searched for in a PATH which is (potentially) different
> than the PATH which is active in the parent.
>
> When you use execlp(), you can just
> Le 8 sept. 2019 à 03:17, Paul Eggert a écrit :
>
> Thanks, and your changes all look good to me; please install when you have
> the time. We can worry about the other issues later (if ever...).
Installed, thanks!
22 matches
Mail list logo
