Il 02/09/20 14:23, dietmar.schind...@manrolandgoss.com ha scritto:
>> -Original Message-
>> From: busybox On Behalf Of Tito
>> Sent: Monday, July 20, 2020 1:58 PM
>> To: busybox@busybox.net
>>
>> …
>> I for myself decided for being defensive and this until today
>> payed off for my little
> -Original Message-
> From: busybox On Behalf Of Tito
> Sent: Monday, July 20, 2020 1:58 PM
> To: busybox@busybox.net
>
> …
> I for myself decided for being defensive and this until today
> payed off for my little personal codebase.
How have you been able to determine that this "payed
On 20/07/2020 05:46, Lauri Kasanen wrote:
> On Sun, 19 Jul 2020 22:31:09 +0200
> Tito wrote:
>
>> please don't do this, this will bite us further up the road,
>> similarly as all string functions that save a check and break
>> havoc afterwards.
>
> The param should be marked with the nonnull
Le 20/07/2020 à 09:22, Laurent Bercot a écrit :
> When writing and using a function that takes pointers, a C programmer
> should always be very aware of the kind of pointer the function expects.
> It is a programming error to pass NULL to a function expecting a pointer
> that cannot be NULL, and
On Monday, July 20, 2020, Tito wrote:
>
>
> On 7/20/20 9:22 AM, Laurent Bercot wrote:
>>> The param should be marked with the nonnull attribute, just like the
>>> libc string functions. Then the compiler will warn you if you try to
>>> pass NULL (may need higher optimization, warning levels, or
On 7/20/20 9:22 AM, Laurent Bercot wrote:
>> The param should be marked with the nonnull attribute, just like the
>> libc string functions. Then the compiler will warn you if you try to
>> pass NULL (may need higher optimization, warning levels, or the
>> analyzer mode in complex cases).
>
>
The param should be marked with the nonnull attribute, just like the
libc string functions. Then the compiler will warn you if you try to
pass NULL (may need higher optimization, warning levels, or the
analyzer mode in complex cases).
Indeed.
A function that takes a pointer that *cannot* be
On Sun, 19 Jul 2020 22:31:09 +0200
Tito wrote:
> please don't do this, this will bite us further up the road,
> similarly as all string functions that save a check and break
> havoc afterwards.
The param should be marked with the nonnull attribute, just like the
libc string functions. Then the
On 7/19/2020 2:48 PM, Denys Vlasenko wrote:
strrchr(s,c) will first find the end of s, then go backwards looking for c.
The second part is wasted work, we only need to check the*last* char == c.
Maybe a naive implementation, but why wouldn't they just record the last
occurrence on a forward
On 7/19/20 8:48 PM, Denys Vlasenko wrote:
> On Tue, Jul 7, 2020 at 9:17 PM Tito wrote:
>> Hi,
>> attached you will find a patch that shrinks libbb's last_char_is function.
>> bloatcheck is:
>>
>> function old new delta
>> last_char_is
On Tue, Jul 7, 2020 at 9:17 PM Tito wrote:
> Hi,
> attached you will find a patch that shrinks libbb's last_char_is function.
> bloatcheck is:
>
> function old new delta
> last_char_is 53 42 -11
>
On Thu, Jul 16, 2020 at 7:53 AM Stefan Seyfried
wrote:
>
> Am 09.07.20 um 21:13 schrieb Tito:
> > On 7/9/20 9:56 PM, Martin Lewis wrote:
> >> Please note that my original patch is still smaller:
> >> http://lists.busybox.net/pipermail/busybox/2020-June/088026.html
> >
> > Hi,
> > yes I know. This
Am 09.07.20 um 21:13 schrieb Tito:
> On 7/9/20 9:56 PM, Martin Lewis wrote:
>> Please note that my original patch is still smaller:
>> http://lists.busybox.net/pipermail/busybox/2020-June/088026.html
>
> Hi,
> yes I know. This is smaller than what is in git now.
> I understood that Denis rejected
On 7/9/20 9:13 PM, Tito wrote:
> On 7/9/20 9:56 PM, Martin Lewis wrote:
>> Please note that my original patch is still smaller:
>> http://lists.busybox.net/pipermail/busybox/2020-June/088026.html
>
> Hi,
> yes I know. This is smaller than what is in git now.
> I understood that Denis rejected
On 7/9/20 9:56 PM, Martin Lewis wrote:
> Please note that my original patch is still smaller:
> http://lists.busybox.net/pipermail/busybox/2020-June/088026.html
Hi,
yes I know. This is smaller than what is in git now.
I understood that Denis rejected your patch:
"This scans the string twice,
Please note that my original patch is still smaller:
http://lists.busybox.net/pipermail/busybox/2020-June/088026.html
I'm not sure whether it's faster, it would be interesting to compare them.
On Tue, 7 Jul 2020 at 14:17, Tito wrote:
> Hi,
> attached you will find a patch that shrinks libbb's
Hi,
attached you will find a patch that shrinks libbb's last_char_is function.
bloatcheck is:
function old new delta
last_char_is 53 42 -11
17 matches
Mail list logo
