On Sat, Mar 15, 2014 at 01:11:03AM +0100, Andreas Krennmair wrote:
> * Claus Assmann [2014-03-15 01:00]:
> >Oh, you use Linux. Of course they don't have useful man pages and
> >miss important functions. Geez, even SunOS 5.x has these.
>
> Except strlcat() on Solaris has slightly different semant
On Fri, Mar 14, 2014 at 04:52:51PM -0700, Claus Assmann wrote:
> On Fri, Mar 14, 2014, Derek Martin wrote:
>
> > char *a = "foo";
> > char *b = "bar";
> > char c[7];
> > strlcpy(a, c, 7);
> > strlcat(b, c, 7);
>
> I guess you didn't read the man page?
Gee, I wonder why I nev
On 15 March 2014 08:56, Matthias Andree wrote:
>
> Grab it from any BSD's libc of your choice and move on.
The easiest way to get them on GNU/Linux is from libbsd:
http://libbsd.freedesktop.org/wiki/
Am 15.03.2014 00:36, schrieb Derek Martin:
> On Sat, Mar 15, 2014 at 12:21:40AM +0100, Matthias Andree wrote:
>> Am 15.03.2014 00:36, schrieb David Laight:
>>> IIRC the warnings come from a property of the symbol in the linker
>>> not the compiler...
>
> That doesn't make it better. ;)
>
>> There
Am 15.03.2014 00:57, schrieb David Laight:
> They are only 'safe' in that you pass the length of the target buffer.
> There are still plenty of ways things can go wrong.
> To make them 'safe' would need 'fat pointers' and run time checks
> (possibly done by the hardware) to ensure that the code di
* Claus Assmann [2014-03-15 01:00]:
Oh, you use Linux. Of course they don't have useful man pages and
miss important functions. Geez, even SunOS 5.x has these.
Except strlcat() on Solaris has slightly different semantics than the OpenBSD
implementation.
On Fri, Mar 14, 2014, Derek Martin wrote:
> char *a = "foo";
> char *b = "bar";
> char c[7];
> strlcpy(a, c, 7);
> strlcat(b, c, 7);
I guess you didn't read the man page?
> $ gcc -o sj strjunk.c
> [...]/ccW4BTCh.o: In function `main':
> strjunk.c:(.text+0x38): undefined refe
On Sat, Mar 15, 2014 at 12:21:40AM +0100, Matthias Andree wrote:
> Am 15.03.2014 00:36, schrieb David Laight:
> > IIRC the warnings come from a property of the symbol in the linker
> > not the compiler...
That doesn't make it better. ;)
> There are strlcpy and strlcat, which take the output buffe
On Sat, Mar 15, 2014 at 12:21:40AM +0100, Matthias Andree wrote:
>
> > At some point there will be something nasty caused by the silent
> > truncation of strings.
>
> There are strlcpy and strlcat, which take the output buffer capacity,
> and permit checking if truncation happened or no.
>
> > s
Am 15.03.2014 00:36, schrieb David Laight:
> On Fri, Mar 14, 2014 at 05:04:59PM -0500, Derek Martin wrote:
>>
>> I dislike those warnings because any half-competent programmer is
>> aware of the *n* versions of functions, and if you chose not to use
>> one there was probably a reason. Please, Mr.
On Fri, Mar 14, 2014 at 05:04:59PM -0500, Derek Martin wrote:
>
> I dislike those warnings because any half-competent programmer is
> aware of the *n* versions of functions, and if you chose not to use
> one there was probably a reason. Please, Mr. Compiler, please stop
> complaining about someth
On Fri, Mar 14, 2014 at 10:35:11PM +0100, Matthias Andree wrote:
> I figured that the practical result depends on the compiler. clang on
> FreeBSD 9.2 amd64 silently fixes up the b0rked initialization, gcc does
> not. Neither complains, though, because the initialization is legal,
> and the strncm
Am 14.03.2014 20:33, schrieb Derek Martin:
> On Wed, Mar 12, 2014 at 07:36:24PM -0700, Claus Assmann wrote:
>> On Thu, Mar 13, 2014, Moritz Barsnick wrote:
>>
>>> "Release early, release often." ;-)
>>> (Less than six months this time, instead of three years.)
>>
>> Thanks to a buffer overflow...
>
On Fri, Mar 14, 2014 at 12:49:09PM -0700, Claus Assmann wrote:
> On Fri, Mar 14, 2014, Derek Martin wrote:
>
> > Unfortunately, sometimes when old code is updated, the maintainer
> > forgets to re-check that everything is copacetic. This can still
> > happen with the "safe" versions of all these
On Fri, Mar 14, 2014, Derek Martin wrote:
> Unfortunately, sometimes when old code is updated, the maintainer
> forgets to re-check that everything is copacetic. This can still
> happen with the "safe" versions of all these functions too.
Sure, but those functions significantly reduce the risk.
On Wed, Mar 12, 2014 at 07:36:24PM -0700, Claus Assmann wrote:
> On Thu, Mar 13, 2014, Moritz Barsnick wrote:
>
> > "Release early, release often." ;-)
> > (Less than six months this time, instead of three years.)
>
> Thanks to a buffer overflow...
>
> It would have been much better if that didn
On Wed, Mar 12, 2014 at 19:36:24 -0700, Claus Assmann wrote:
> > (Less than six months this time, instead of three years.)
>
> Thanks to a buffer overflow...
Okay, let's introduce some more, if this brings us more releases. ;-)
> muttlib.o(.text+0x38f8): In function `mutt_adv_mktemp':
> muttlib.
On Thu, Mar 13, 2014, Moritz Barsnick wrote:
> "Release early, release often." ;-)
> (Less than six months this time, instead of three years.)
Thanks to a buffer overflow...
It would have been much better if that didn't happen.
Hmm, maybe it's finally time to get rid of strcat(), strcpy(), etc?
18 matches
Mail list logo
