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 lin
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 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 t
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 th
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 (make-st
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);
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 counter-
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
standards
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
> > it's
Thanks for your thoughtful reply. A few points:
Jonas 'Sortie' Termansen wrote:
I object to the notion that truncation is a worse outcome than a buffer
overflow. A buffer overflow is at worst a remote code execution
vulnerability, while a truncation is at worst a program bug (although
that may
Hi Bruno & Paul,
Thanks for your interest in my notes on gnulib. I appreciate your desire
to discuss them. Please excuse some of the resources that I'll link
below for overreacting in jest ("screaming in horror", "usual gnulib
infection"), they weren’t really meant for upstream consumption, but
th
Bruno Haible wrote:
https://gitlab.com/sortix/sortix/wikis/Gnulib
sprintf calls.
What do you mean? sprintf is a standardized libc function.
I imagine Jonas is referring to the practice of avoiding sprintf and using
snprintf instead, under the theory that sprintf can be dangerous. Gnulib does
Dear Jonas,
Just discovered this critique of gnulib, that you wrote in 2016:
https://gitlab.com/sortix/sortix/wikis/Gnulib
It deserves a discussion.
> Gnulib is a portability layer but ironically fails to be portable,
> as it requires knowledge of implementation details of every sup
13 matches
Mail list logo
