☎ wrote: Using osmo_auth_*() is the recommended API but comp128v*() are also in the installed header files and thus also part of the public API. //Peter

☎ wrote: Even if it is deprecated it would have to stay, otherwise the libosmocore ABI breaks without a very good reason. //Peter

Sylvain Munaut wrote: Ok - great! //Peter

Hi Max, I would like to merge your patch, but: On Tue, Nov 19, 2013 at 12:25:52PM +0100, ☎ wrote: this is space-indented, not tab-indented. those lienes are too long for 80-character wide terminals there's again mixed space and tab indentation. we put the curly braces at the beginning of the line, not at the end of the line. And again the functions are space indented. Furthermore, your patch does not apply on top of master. It's sad to see that valuable contributions are lost due to basic coding style issues not being observed. We had this back in April with your KASUMI related patches, and it was never fixed. Please take the time to fix those issues, thanks. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

22.11.2013 17:59, Jeffrey Walton пишет: I second that. I mean I do understand that nobody wants to do the boring work which could be offloaded to others, and rightfully so. But that's also discouraging - and that's why those patches are stalled since spring: I use patched version locally and keep working on my research. Because it's research project, not some product there's no maintenance burden for me in this setup, while with pushing stuff upstream - there is. Hence the efforts to mainline things are not as ideal as they could be. Of course I would try to fix the patches anyway, so that they will please upstream, but not today - Friday evening, and so on :) I hope I do not sound complaining - just would like to clarify the difference. -- best regards, Max, http://fairwaves.ru

Hi Jeffery, On Fri, Nov 22, 2013 at 11:59:28AM -0500, Jeffrey Walton wrote: well, number one reason is 'because this is the culture'. All (at least most) of the projects I have been involved in have a coding style. It is the duty of every developer to follow that. If I want to get something merged to wireshark, I have to use their coding style, not my personal one, no matter if I like it or not. If an occasional mistake happens, then that is excusable. But if I always post my patches without caring about the rules (including coding style), then it measn that I am perceived as being ignorant towards the project. Having a unified coding style is important for many software developers. Why am I not fixing it up? Because * I might break the code doing so (and I might not have the same test setup and familiarity with that paticular code / functionalty as the original subitter) * maintainers are typically overloaded in all projects. For efficient collaborative development it is important that the work for the maintainers is reduced, as they are single-point-of-failures. * maintainers are developers. They primarily like to write code, and like to be efficient/productive. 'wiping the floor' after other developers/contributors who have been too lazy to care about the rules of the project is tiresome, annoying, and generally not very productive use of their time It is not only the content of your work that matters, but also the style. Many people also consider it as disrespectful, if contributors are not willing to align with a projects style / rules / architecture. As a maintainer [and I'm not saying that I have been maintaining openbsc or related projects during the last year, I'm just generally speaking], I want contributors to learn how to write patches that I can simply apply without having to spend time on it except reading through the code. If I always fix up everyones patches, I will do that for the years to come and will not do anything else (more productive). Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Jeffrey Walton wrote: Because we'd like to have developers share a cohesive culture around the code and code style rather than have developers that are unable to do better than agree to disagree about something so simple as style, and resign to have a computer fix up the differences. If not even agreement about style can be accomplished then it's not very likely that much other agreement can be had either. (Unfortunately I know that all too well from experience.) I think that statement is quite intolerant of you. Learning a culture by slowly immersing oneself in it is never a waste of time, I think it enriches life in more ways than we can know. If developers do not want to work together then they shouldn't pretend; it would be much better to go separate ways. //Peter

Hi Max, On Mon, Nov 25, 2013 at 12:20:33PM +0100, ☎ wrote: thanks. it looks fine to me, and if it was applying to libosmocore/master, I would have merged it today :) Just for sake of completeness, the linux kernel checkpatch.pl script finds the following issues (which I would ignore, but just as a general rule, it is a good way to catch coding style issues): ------------ WARNING: line over 80 characters #45: FILE: include/osmocom/gsm/comp128v23.h:20: +int comp128v2(const uint8_t *ki, const uint8_t *rand, uint8_t *sres, uint8_t *kc); WARNING: line over 80 characters #46: FILE: include/osmocom/gsm/comp128v23.h:21: +int comp128v3(const uint8_t *ki, const uint8_t *rand, uint8_t *sres, uint8_t *kc); WARNING: please, no spaces at the start of a line #225: FILE: tests/comp128/comp128_test.c:18: + }$ WARNING: please, no spaces at the start of a line #234: FILE: tests/comp128/comp128_test.c:27: + }$ ERROR: "foo * bar" should be "foo *bar" #237: FILE: tests/comp128/comp128_test.c:30: +void print_check(int rc, char * res, struct osmo_auth_vector *vec) ERROR: trailing statements should be on next line #251: FILE: tests/comp128/comp128_test.c:44: + else printf("%d OK\n", rc); ERROR: else should follow close brace '}' #251: FILE: tests/comp128/comp128_test.c:44: + } + else printf("%d OK\n", rc); ERROR: "foo * bar" should be "foo *bar" #254: FILE: tests/comp128/comp128_test.c:47: +void test_comp128v3(char * rand, char * res) ERROR: "foo * bar" should be "foo *bar" #254: FILE: tests/comp128/comp128_test.c:47: +void test_comp128v3(char * rand, char * res) ERROR: "foo * bar" should be "foo *bar" #264: FILE: tests/comp128/comp128_test.c:57: +void test_comp128v2(char * rand, char * res) ERROR: "foo * bar" should be "foo *bar" #264: FILE: tests/comp128/comp128_test.c:57: +void test_comp128v2(char * rand, char * res) ------------ Regards, -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

On Mon, Dec 02, 2013 at 11:36:08AM +0100, ☎ wrote: Yes, that is why this is a warning. It can be okay to overflow the line.