Yes.
2018-06-26 02:28, Richard Hipp:
> On 6/24/18, Dingyuan Wang wrote:
>>
>> I just got 50 exactly same "[fossil-src] activity alert" emails
>> describing 5 check-ins in three minutes. What's happening to the server?
>>
>
> Did today's digest arrive successfully, and only once?
>
David Mason:
> Fossil appears to be careful with memory allocation too, with very few
> raw calls to malloc, so memory allocations can be unwound.
SQLite has the "Zero-malloc" and "Application-supplied memory
allocators" options [0], which may be helpful for cases without proper
db engine
On 25 June 2018 at 14:51, Richard Hipp wrote:
> On 6/25/18, jungle Boogie wrote:
>> If I inadvertently forward my email along
>> to someone/group without modifying the footer, the person/group would
>> be able to alter my subscription.
>
> How can I fix that?
>
I don't know, but maybe that idea
On 6/25/18, jungle Boogie wrote:
> If I inadvertently forward my email along
> to someone/group without modifying the footer, the person/group would
> be able to alter my subscription.
How can I fix that?
--
D. Richard Hipp
d...@sqlite.org
___
On 23 June 2018 at 13:07, Richard Hipp wrote:
> Just FYI:
>
> I have opened up email notifications on the canonical Fossil
> repository. To subscribe, visit:
>
> https://fossil-scm.org/fossil/subscribe
>
> Your help in finding creative ways of breaking the new system is appreciated.
>
This
On 6/24/18, Dingyuan Wang wrote:
>
> I just got 50 exactly same "[fossil-src] activity alert" emails
> describing 5 check-ins in three minutes. What's happening to the server?
>
Did today's digest arrive successfully, and only once?
--
D. Richard Hipp
d...@sqlite.org
There is nothing wrong with a C library handling its internal processing
using setjmp/longjmp, as long as there's no C++ callbacks or any other way
that C++ code that might use throw/catch can be executed from within calls
to that library.
It's a little bit more work than just replacing the calls
On Mon, Jun 25, 2018 at 2:30 PM Warren Young wrote:
> On Sun, Jun 24, 2018 at 4:48 PM, Stephan Beal
> wrote:
>
>> Isn't adding hundreds (literally) of gotos just as fraught with
>> opportunities for failure ;)?
>>
>
> #ifdef LIBFOSSIL
> # define FOSSIL_EXIT(n) longjmp(blabla)
> #else
> #
I was thinking it would be a little more than this, but perhaps:
# define FOSSIL_EXIT(n) (api_exit_status-=n,longjmp(blabla))
would actually be enough.
And a similar setjmp-calling macro at the beginning of each API function
would be all that would be required there.
../Dave
On 25 June
On Mon, Jun 25, 2018 at 2:30 PM Warren Young wrote:
> On Sun, Jun 24, 2018 at 4:48 PM, Stephan Beal
> wrote:
>
>> Isn't adding hundreds (literally) of gotos just as fraught with
>> opportunities for failure ;)?
>>
>
> #ifdef LIBFOSSIL
> # define FOSSIL_EXIT(n) longjmp(blabla)
> #else
> #
Actually, setjmp/longjmp isn't goto, it's try-catch/throw.
It unwinds the stack, so you can only (correctly) longjmp to a point that
is in the current call-chain. Of course, this is C, so you can screw it up,
but said screw-ups are not subtle! And subtle bugs are the ones to worry
about.
I count
On 6/25/18, bytevolc...@safe-mail.net wrote:
> Ping.
https://www.fossil-scm.org/fossil/fdiff?v1=c05a6e30cd4e0324=04e654b0d8ae6f74
>
> On Thu, 21 Jun 2018 22:18:37 +1000
> wrote:
>
>> It appears the "show-version-diffs" setting was abandoned in commit
>> 0a1f4ed6aa.
>>
>> Index: src/setup.c
>>
Ping.
On Thu, 21 Jun 2018 22:18:37 +1000
wrote:
> It appears the "show-version-diffs" setting was abandoned in commit
> 0a1f4ed6aa.
>
> Index: src/setup.c
> ==
> --- src/setup.c
> +++ src/setup.c
> @@ -1463,19 +1463,10 @@
>@
On Mon, 25 Jun 2018 05:08:53 +0200, Andy Goth
wrote:
On 06/24/18 05:27, j. van den hoff wrote:
additionally, mabye shorten the footer separation line to exactly two
`--', treating the footer as the sender's "affiliation/identity" (which
usually leads to a less prominent display by the
14 matches
Mail list logo
