29 Nov
2012
29 Nov
'12
3:12 p.m.
Hello.
Right now there's no way for user of osmo_a5(..) to understand if particular cipher
(a5/3 for example) is supported or not.
Attached patch adds simple return value to osmo_a5 to fix that.
Of course I would rather see a5/3 included into mainline but in a meantime this patch
might be useful too :)
--
best regards,
Max, http://fairwaves.ru
29 Nov
29 Nov
4:07 p.m.
Hi,
Right now there's no way for user of osmo_a5(..)
to understand if particular cipher
(a5/3 for example) is supported or not.
Indeed ..
Attached patch adds simple return value to osmo_a5 to
fix that.
Of course I would rather see a5/3 included into mainline but in a meantime this patch
might be useful too :)
mmm, the "osmocom" usual way is to return 0 for success and a negative
error, in this case -ENOTSUP would be perfect.
true/false is more a C++ thing :p
Cheers,
Sylvain
30 Nov
30 Nov
5:38 p.m.
29.11.2012 16:07, Sylvain Munaut пишет:
mmm, the "osmocom" usual way is to return 0
for success and a negative
error, in this case -ENOTSUP would be perfect.
Is there common place to define such error codes in osmocom?
git grep -ni ENOTSUP
reveals nothing of a kind.
--
best regards,
Max, http://fairwaves.ru
6:18 p.m.
Hi,
Well we never used that one yet I guess, but those are defined in
errno.h part of POSIX AFAIK.
Cheers,
Sylvain
mmm, the
"osmocom" usual way is to return 0 for success and a negative
error, in this case -ENOTSUP would be perfect.
Is there common place to define such error codes in osmocom?
git grep -ni ENOTSUP
reveals nothing of a kind.
4701
days inactive
4702
days old
baseband-devel@lists.osmocom.org
3 comments
2 participants
participants (2)
-
Sylvain Munaut -
☎