[PATCH 3/4] Refactor cgit_parse_snapshots_mask()
Use Git string lists instead of str{spn,cspn,ncmp}() magic. This
significantly improves readability.
Signed-off-by: Lukas Fleischer c...@cryptocrack.de
---
shared.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/shared.c b/shared.c
index 1f6310a..01197f1 100644
--- a/shared.c
+++ b/shared.c
@@ -404,28 +404,29 @@ void cgit_diff_commit(struct commit *commit, filepair_fn
fn, const char *prefix)
int cgit_parse_snapshots_mask(const char *str)
{
+ struct string_list tokens = STRING_LIST_INIT_DUP;
+ struct string_list_item *item;
const struct cgit_snapshot_format *f;
- static const char *delim = ;
- int tl, sl, rv = 0;
+ int rv = 0;
/* favor legacy setting */
if (atoi(str))
return 1;
- for (;;) {
- str += strspn(str, delim);
- tl = strcspn(str, delim);
- if (!tl)
- break;
+
+ string_list_split(tokens, str, ' ', -1);
+ string_list_remove_empty_items(tokens, 0);
+
+ for_each_string_list_item(item, tokens) {
for (f = cgit_snapshot_formats; f-suffix; f++) {
- sl = strlen(f-suffix);
- if ((tl == sl !strncmp(f-suffix, str, tl)) ||
- (tl == sl - 1 !strncmp(f-suffix + 1, str, tl -
1))) {
+ if (!strcmp(item-string, f-suffix) ||
+ !strcmp(item-string, f-suffix + 1)) {
rv |= f-bit;
break;
}
}
- str += tl;
}
+
+ string_list_clear(tokens, 0);
return rv;
}
--
1.8.5.2
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Re: RESEND: syntax-highlighting.py
Am 08.01.2014 16:19, schrieb Jason A. Donenfeld:
Okay reading this closer, it seems what the one in-tree could benefit from is:
- Expanded list of filename mappings, made more generic than what you
have in your script, but basically the same idea. -- { pkgbuild:
bashlexer, cmakelists.txt, cmakelexer }. Is there a way to do
this that ties directly into pygment's guess_lexer_for_filename? If
not, could you submit a patch upstream?
I have created an upstream pull request and it got merged after 30
seconds [1]. Moreover it seems like the cmakelists.txt thing was also
fixed [2].
Should I remove the filename mapping thing in my patch according to
upstream or should I keep this until the next pygments release?
[1]
https://bitbucket.org/birkenfeld/pygments-main/commits/7cc1e6d0143445302445360fb8b963a7644f1912
[2]
https://bitbucket.org/birkenfeld/pygments-main/src/8fda165f5da04bdf5040fc7b8d3e1589d8fc1b4f/pygments/lexers/text.py?at=default#cl-1609
signature.asc
Description: OpenPGP digital signature
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
[PATCH 2/2] cgit.c: Fix comment on bit mask hack
* Formatting and spelling fixes.
* A bit mask with the size of one byte only allows for storing 8 (not
255!) different flags.
Signed-off-by: Lukas Fleischer c...@cryptocrack.de
---
cgit.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/cgit.c b/cgit.c
index f4262d8..d74b0f3 100644
--- a/cgit.c
+++ b/cgit.c
@@ -885,14 +885,16 @@ static void cgit_parse_args(int argc, const char **argv)
ctx.qry.ofs = atoi(argv[i] + 6);
} else if (!prefixcmp(argv[i], --scan-tree=) ||
!prefixcmp(argv[i], --scan-path=)) {
- /* HACK: the global snapshot bitmask defines the
-* set of allowed snapshot formats, but the config
-* file hasn't been parsed yet so the mask is
-* currently 0. By setting all bits high before
-* scanning we make sure that any in-repo cgitrc
-* snapshot setting is respected by scan_tree().
-* BTW: we assume that there'll never be more than
-* 255 different snapshot formats supported by cgit...
+ /*
+* HACK: The global snapshot bit mask defines the set
+* of allowed snapshot formats, but the config file
+* hasn't been parsed yet so the mask is currently 0.
+* By setting all bits high before scanning we make
+* sure that any in-repo cgitrc snapshot setting is
+* respected by scan_tree().
+*
+* NOTE: We assume that there aren't more than 8
+* different snapshot formats supported by cgit...
*/
ctx.cfg.snapshots = 0xFF;
scan++;
--
1.8.5.2
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
[PATCH 1/2] cgit.c: Use else for mutually exclusive branches
When parsing command line arguments, no pair of command line options can
ever match simultaneously. Use else if blocks to reflect this. This
change improves both readability and speed.
Signed-off-by: Lukas Fleischer c...@cryptocrack.de
---
Based on the patches I sent earlier today.
cgit.c | 29 ++---
1 file changed, 10 insertions(+), 19 deletions(-)
diff --git a/cgit.c b/cgit.c
index e31962d..f4262d8 100644
--- a/cgit.c
+++ b/cgit.c
@@ -865,35 +865,26 @@ static void cgit_parse_args(int argc, const char **argv)
for (i = 1; i argc; i++) {
if (!prefixcmp(argv[i], --cache=)) {
ctx.cfg.cache_root = xstrdup(argv[i] + 8);
- }
- if (!strcmp(argv[i], --nocache)) {
+ } else if (!strcmp(argv[i], --nocache)) {
ctx.cfg.nocache = 1;
- }
- if (!strcmp(argv[i], --nohttp)) {
+ } else if (!strcmp(argv[i], --nohttp)) {
ctx.env.no_http = 1;
- }
- if (!prefixcmp(argv[i], --query=)) {
+ } else if (!prefixcmp(argv[i], --query=)) {
ctx.qry.raw = xstrdup(argv[i] + 8);
- }
- if (!prefixcmp(argv[i], --repo=)) {
+ } else if (!prefixcmp(argv[i], --repo=)) {
ctx.qry.repo = xstrdup(argv[i] + 7);
- }
- if (!prefixcmp(argv[i], --page=)) {
+ } else if (!prefixcmp(argv[i], --page=)) {
ctx.qry.page = xstrdup(argv[i] + 7);
- }
- if (!prefixcmp(argv[i], --head=)) {
+ } else if (!prefixcmp(argv[i], --head=)) {
ctx.qry.head = xstrdup(argv[i] + 7);
ctx.qry.has_symref = 1;
- }
- if (!prefixcmp(argv[i], --sha1=)) {
+ } else if (!prefixcmp(argv[i], --sha1=)) {
ctx.qry.sha1 = xstrdup(argv[i] + 7);
ctx.qry.has_sha1 = 1;
- }
- if (!prefixcmp(argv[i], --ofs=)) {
+ } else if (!prefixcmp(argv[i], --ofs=)) {
ctx.qry.ofs = atoi(argv[i] + 6);
- }
- if (!prefixcmp(argv[i], --scan-tree=) ||
- !prefixcmp(argv[i], --scan-path=)) {
+ } else if (!prefixcmp(argv[i], --scan-tree=) ||
+ !prefixcmp(argv[i], --scan-path=)) {
/* HACK: the global snapshot bitmask defines the
* set of allowed snapshot formats, but the config
* file hasn't been parsed yet so the mask is
--
1.8.5.2
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
[PATCH] Disallow downloading disabled snapshot formats
We did only display enabled snapshot formats but we did not prevent from
downloading disabled formats when requested. Fix this by adding an
appropriate check.
Also, add a test case that checks whether downloading disabled snapshot
formats is denied, as expected.
Signed-off-by: Lukas Fleischer c...@cryptocrack.de
---
tests/t0107-snapshot.sh | 5 +
ui-snapshot.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/tests/t0107-snapshot.sh b/tests/t0107-snapshot.sh
index 6cf7aaa..01e8d22 100755
--- a/tests/t0107-snapshot.sh
+++ b/tests/t0107-snapshot.sh
@@ -79,4 +79,9 @@ test_expect_success UNZIP 'verify unzipped file-5' '
test_line_count = 1 master/file-5
'
+test_expect_success 'try to download a disabled snapshot format' '
+ cgit_url foo/snapshot/master.tar.xz |
+ grep Unsupported snapshot format
+'
+
test_done
diff --git a/ui-snapshot.c b/ui-snapshot.c
index 8f82119..ab20a4a 100644
--- a/ui-snapshot.c
+++ b/ui-snapshot.c
@@ -205,7 +205,7 @@ void cgit_print_snapshot(const char *head, const char *hex,
}
f = get_format(filename);
- if (!f) {
+ if (!f || (snapshots f-bit) == 0) {
show_error(Unsupported snapshot format: %s, filename);
return;
}
--
1.8.5.2
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Re: [PATCH] Disallow downloading disabled snapshot formats
On Fri, Jan 10, 2014 at 03:38:06PM +0100, Lukas Fleischer wrote:
We did only display enabled snapshot formats but we did not prevent from
downloading disabled formats when requested. Fix this by adding an
appropriate check.
Also, add a test case that checks whether downloading disabled snapshot
formats is denied, as expected.
Signed-off-by: Lukas Fleischer c...@cryptocrack.de
---
tests/t0107-snapshot.sh | 5 +
ui-snapshot.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/tests/t0107-snapshot.sh b/tests/t0107-snapshot.sh
index 6cf7aaa..01e8d22 100755
--- a/tests/t0107-snapshot.sh
+++ b/tests/t0107-snapshot.sh
@@ -79,4 +79,9 @@ test_expect_success UNZIP 'verify unzipped file-5' '
test_line_count = 1 master/file-5
'
+test_expect_success 'try to download a disabled snapshot format' '
+ cgit_url foo/snapshot/master.tar.xz |
+ grep Unsupported snapshot format
I really dislike seeing pipes in the test suite. Can we redirect to
file instead and then grep the file? This helps ensure that the exit
code from CGit is correct (I don't know if we expect it to be zero or
non-zero here, but if the latter then at least test_must_fail checks
that the process didn't segfault - I suspect it should be zero though).
+'
+
test_done
diff --git a/ui-snapshot.c b/ui-snapshot.c
index 8f82119..ab20a4a 100644
--- a/ui-snapshot.c
+++ b/ui-snapshot.c
@@ -205,7 +205,7 @@ void cgit_print_snapshot(const char *head, const char
*hex,
}
f = get_format(filename);
- if (!f) {
+ if (!f || (snapshots f-bit) == 0) {
show_error(Unsupported snapshot format: %s, filename);
return;
}
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Re: RFE: .so filters
On Fri, Jan 10, 2014 at 10:06 AM, John Keeping j...@keeping.me.uk wrote: This seems drastically over complicated. So here's the situation. There's a lot of state that we're taking advantage of in using processes that terminate, that needs to be replicated: *a* Sending arguments to the program, and distinguishing these arguments from data [via argv in main] *b* When we are finished sending data to the filter [via a closed file descriptor] *c* When the filter is finished sending data to cgit [via the filter process terminating / waitpid] If we skim on any one of these requirements, we introduce either limited functionality or race conditions. To fully replicate these required state transitions, we must either: *1* Use an out of band messaging mechanism, such as unix signals (what I've implemented in jd/longfilters, for example) *2* Use two file descriptors (which then would require the filter to select() or similar) *3* Come up with an encoding scheme that would separate these messages from the data (which would then require the client to know about it) I don't really like any of these possibilities. I've implemented *1* already, and while it works, it's a hassle to implement the signal handling without races in the filter because of the *b* requirement above. *2* is even harder to implement in simple scripts, so that's out. And *3* is a full blown disaster, which would be so invasive that we might as well use shared libraries if we're going to use this. So that's out. What all of this points to is the fact that persistent filters are not going to wind up being a general thing available for all filter types. I'm going to implement specifically email filters using it, and it's going to have a domain specific encoding scheme: * the filter receives the email address on one line * the filter receives the data to filter on the next line * the filter then spits out its filtered data on a single line This specificity is obviously unsuitable for any multiline filtering or filtering of binary data. But it is simple enough to implement in scripts that I'm fine with it. It will require these changes: *a* Allowing persistent filter processes, with proper start-up / tear-down times and pipe preservation (already implemented in jd/longfilters) *b* Not dup2()ing the pipe to stdin/stdout, so that the filter close function can read from the pipe itself, and block until it receives its output (which is a bit of a different way of doing things from how we're doing it now) I'm not too pumped about *b*, but that's the only way unless we're to use signals or some other OOB mechanism. I'll code this up and report back. ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: [PATCH 1/4] Replace most uses of strncmp() with prefixcmp()
Looks good, merged. ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: [PATCH 1/2] cgit.c: Use else for mutually exclusive branches
Seems reasonable. Merged. ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: [PATCH] Disallow downloading disabled snapshot formats
On Fri, Jan 10, 2014 at 3:38 PM, Lukas Fleischer c...@cryptocrack.de wrote: We did only display enabled snapshot formats but we did not prevent from downloading disabled formats when requested. Fix this by adding an appropriate check. Previously: http://lists.zx2c4.com/pipermail/cgit/2012-June/000641.html http://lists.zx2c4.com/pipermail/cgit/2012-October/000792.html ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
sendfile patch revival?
Looking through the archives, I stumbled across this neglected patch: http://lists.zx2c4.com/pipermail/cgit/2012-June/000642.html Anybody want to investigate and brush this up for merging currently? ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: RFE: .so filters
On Fri, Jan 10, 2014 at 06:12:25PM +0100, Florian Pritz wrote:
On 10.01.2014 16:57, Jason A. Donenfeld wrote:
On Fri, Jan 10, 2014 at 10:06 AM, John Keeping j...@keeping.me.uk wrote:
This seems drastically over complicated.
So here's the situation. There's a lot of state that we're taking
advantage of in using processes that terminate, that needs to be
replicated:
Isn't this (fast scripting with lots of features) when people normally
start using lua?
I would have no problem including LuaJIT for this sort of thing. There
was even a PoC for using Lua to format Git log messages a year or so
ago.
I was also wondering if supporting unix:/path/to/socket would be
useful, then the filter would connect on a Unix socket, run and
disconnect, on the assumption that the administrator has a daemon
running to do the filtering.
If we're introducing this type:spec support then it would be good
to do it in a reasonably generic way so that any types that add new
dependencies can be compiled out easily. Maybe a table like this?
struct filter_handler handlers[] = {
{ unix, open_unix_socket_filter, close_unix_socket_filter },
{ persistent, open_persistent_filter, close_persistent_filter },
#ifndef NO_LUA
{ lua, open_lua_filter, close_lua_filter },
#endif
};
I might have a look at the Lua case over the weekend if no one beats me
to it.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Re: RFE: .so filters
On Fri, Jan 10, 2014 at 6:20 PM, John Keeping j...@keeping.me.uk wrote:
I was also wondering if supporting unix:/path/to/socket would be
useful, then the filter would connect on a Unix socket, run and
disconnect, on the assumption that the administrator has a daemon
running to do the filtering.
This has few benefits, and you still have the out of band signaling
issues. Sysadmins don't want to run more daemons.
If we're introducing this type:spec support then it would be good
to do it in a reasonably generic way so that any types that add new
dependencies can be compiled out easily. Maybe a table like this?
struct filter_handler handlers[] = {
{ unix, open_unix_socket_filter, close_unix_socket_filter },
{ persistent, open_persistent_filter, close_persistent_filter },
#ifndef NO_LUA
{ lua, open_lua_filter, close_lua_filter },
#endif
};
This would make more sense. Look at the commit I just merged to master
where I split filters out into filter.c. This would be the place for
such a function pointer table.
I might have a look at the Lua case over the weekend if no one beats me
to it.
Cool. Please take in mind the design considerations in the email I
just sent to Florian with the tree functions... Before you begin, take
a peak at jd/gravatar and jd/persistent. Can't wait to see what you
come up with!
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Re: RFE: .so filters
On 10.01.2014 18:57, Jason A. Donenfeld wrote: On Fri, Jan 10, 2014 at 6:12 PM, Florian Pritz bluew...@xinu.at wrote: Isn't this (fast scripting with lots of features) when people normally start using lua? This would have the same challenges as using .so files, w.r.t. hooking write() (or the html functions), but would be very interesting indeed, because Lua... How about using the current fork approach but instead of calling execvp use lua. I believe forks are pretty cheap on linux, it's the exec that's costly. If we do it like that we could reuse stdin/stdout, we could pass arguments via lua tables (like command line arguments now), but we should have little overhead for the script loading/executing. signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: RFE: .so filters
On Fri, Jan 10, 2014 at 09:03:24PM +0100, Florian Pritz wrote: On 10.01.2014 18:57, Jason A. Donenfeld wrote: On Fri, Jan 10, 2014 at 6:12 PM, Florian Pritz bluew...@xinu.at wrote: Isn't this (fast scripting with lots of features) when people normally start using lua? This would have the same challenges as using .so files, w.r.t. hooking write() (or the html functions), but would be very interesting indeed, because Lua... How about using the current fork approach but instead of calling execvp use lua. I believe forks are pretty cheap on linux, it's the exec that's costly. If we do it like that we could reuse stdin/stdout, we could pass arguments via lua tables (like command line arguments now), but we should have little overhead for the script loading/executing. Forking and using Lua in the child is an interesting idea. I need to investigate how Lua generally deals with I/O, but it feels like it will be simpler to use a simple function interface than deal with slurping in the input in Lua. So it may be simpler to swap out the write function in CGit while the filter is active and collect the output in a buffer instead, then call a Lua function and pass whatever comes back from that to the real write(2). ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: RFE: .so filters
On 10.01.2014 21:11, John Keeping wrote: Forking and using Lua in the child is an interesting idea. I need to investigate how Lua generally deals with I/O, but it feels like it will be simpler to use a simple function interface than deal with slurping in the input in Lua. Looks rather easy to slurp stdin (from http://www.lua.org/pil/21.1.html): t = io.read(*all) -- read the whole file t = string.gsub(t, ...) -- do the job io.write(t) -- write the file signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
