| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After recent system upgrade, gcc 9.1.0, I started getting gsm0808_test
failing locally:
Assert failed memcmp(&enc_ct, &dec_ct, sizeof(enc_ct)) == 0 libosmocore/tests/gsm0808/gsm0808_test.c:992
During investigation with gdb, fields of both structures seem to contain
same values. However, closer lookup gives some hints on why it fails:
(gdb) print memcmp(&enc_ct, &dec_ct, sizeof(enc_ct))
$1 = 85
(gdb) print memcmp(&enc_ct, &dec_ct, 12)
$14 = 85
(gdb) print ((uint8_t*)&enc_ct)[11]
$15 = 85 'U'
(gdb) print ((uint8_t*)&dec_ct)[11]
$16 = 0 '\000'
So the 12th byte in struct gsm0808_channel_type is basically an
alignment padding byte added by the compiler (to align perm_spch_len to
4-byte alignment). Since both compared structs are initialized without
memset(0) but using compiler's designated initializers, it seems the compiler
decided it's no longer needed to zero the padding byte, making memcp fail in
this case.
In order to avoid the failure, let's properly check every field instead
of using memcp here.
Change-Id: I17fe7a0a5dc650f050bba1f47d071be749550729
|
|
|
|
| |
Change-Id: I33837f0fac1afe83596fa600916abc05ecb8c356
|
|
|
|
|
|
|
|
| |
Unconditional initialization follows the structure definition,
so there is no need to do it twice. This prevents compiler
from warning about potential errors.
Change-Id: If9fd2826f132dfa203dda62940d93dbdfcfd92ac
|
|
|
|
| |
Change-Id: I1564f4714a33d36792e4982deb8f19d1b740dc0c
|
|
|
|
| |
Change-Id: I5eb17edadf89ac47b4ca86c9e822037f7c0e518e
|
|
|
|
| |
Change-Id: Ib444383d2074ddb89b3fe5bbf198bcbfabd7057f
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ubsan will report undefined behavior due to the SUN_LEN macros interaction with a null pointer,
so let's tell ubsan to ignore this function. After carefully reviewing the final publically
availlable drafts of the C99,C11 and C18 standards I can confirm that dereferencing null pointers
is still undefined behavior, as such ubsan will always warn with absolutely every existing compiler
version. Since the sanitizers are periodically synced between llvm and gcc I'm also fairly confident
that rebuilding everything with compiler_rt to use the integrated sanitizers would result in the same message.
I sincerly hope that this explanation provides to be sufficient, If not I'd be willing to show up at
the next llvm dev meeting to provide quotes from actual sanitizer developers to back up these claims.
Change-Id: I0ff445072f1b46390c9f70b21d61c789e39358d5
|
|
|
|
| |
Change-Id: Id38272ff93fae6d2fdf39df4ffc74856d6c9a898
|
|
|
|
| |
Change-Id: Ie18c291d0cfe3b246d09ac6cfd9591951a2984c8
|
|
|
|
|
| |
Change-Id: I34e465dead179487f7d4508e0e6ecf0e838c6eb7
Closes: CID#177910
|
|
|
|
|
| |
Change-Id: I7a544d2d43b83135def296674f777e48fe5fd80a
Closes: CID#190866
|
|
|
|
|
| |
Change-Id: I0888fbad0f9094ec1b31e2cceecfc9cd372399bd
Closes: CID#202057
|
|
|
|
| |
Change-Id: I1e2c62cb9047648907c91b99f764f6caba8f4493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than having the encoder/decoder library print some log
messages in case of encoding/decoding errors, let's provide something
akin to 'errno', but with a string instead of a numeric error code.
The 'osmo_cbsp_errstr' global variable (if set) contains a
human-readable string describing the most recent encoding/decoding error.
It exists separately for each thread and hence can be used safely in
multi-threaded environments.
Change-Id: Id9a5a595a76ba278647aee9470ded213d8464103
|
|
|
|
|
|
|
|
|
|
| |
This introduces definitions as well as a parser+encoder for the
Cell Broadcast Service Protocol (CBSP) as specified in 3GPP TS 48.049.
CBSP is used on the interface between CBC and BSC.
Related: OS#3537
Change-Id: I5b7ae08f67e415967b60ac4b824db9e22ca00935
|
|
|
|
| |
Change-Id: I9d6f6b66c99c43107d1ad3e80af332e967bb19e8
|
|
|
|
| |
Change-Id: I57a330e16cc2910597672e1b27cf971499cea5bc
|
|
|
|
| |
Change-Id: I56cce5cda0621f5e9f1c28aaad4646e9e267d17d
|
|
|
|
|
| |
Related: OS#3047
Change-Id: Ic147678e7906a8b9ad7fac8367602b656f4172e6
|
|
|
|
|
|
|
|
|
|
|
|
| |
The link quality, defined by C/I (Carrier-to-Interference) ratio,
can be computed from the training sequence of each burst, where we
can compare the "ideal" training sequence with the actual training
sequence and then express that in cB (centiBels, dB * 10).
By analogy with both RSSI and ToA, it can be used to filter out
false-positive detections and ghost Access Bursts.
Change-Id: Ie2a66ebd040b61d6daf49e04bf8a84d3d64764ee
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 4e284b637943980a405a8c44f2712b749ded428f.
Unfortunately, some projects such as OsmoMSC, OsmoBTS and OpenBSC
do contain OSMO_ASSERT statements without a semi colon. Thus,
this change causes compilation errors when building them.
Please note that only the OSMO_ASSERT's definition is reverted,
while changes to other files (adding missing semicolons) are kept.
Change-Id: I6da4d7397d993f6c1af658cb5ae1e49c92a1b350
|
|
|
|
|
|
|
|
|
| |
When using `OSMO_ASSERT(exp);` clang will warn about
an empty expression because the semi colon was superflous.
Use do {} while (0) to enfore the need of a semi colon.
This might break other test.
Change-Id: I2272d29a81496164bebd1696a694383a28a86434
|
|
|
|
|
|
|
|
|
| |
Do not remove the entire doc/vty/ dir during the doxygen generation,
because it contains versioned files.
Fixes: 2fe50ac9511469a587426b80501b2b5da770e3a0 ("doxygen: enable cross referencing everywhere")
Related: OS#3986
Change-Id: I884398c5e834ae2fac0af8c9b52d65bb3ceacb2d
|
|
|
|
|
|
|
| |
Ignore files created during the two-pass doxygen generation that was
introduced in Ib03d0b70d536c8f1386def666c89106a840f7363.
Change-Id: I719bbc968420c462426d2c0ce703c7f3b2c1139e
|
|
|
|
| |
Change-Id: I7df6858bb98abffc1d5bf420f991ae5854b24638
|
|
|
|
|
|
|
|
| |
The timeout is calculated dynamically in t200_by_lchan() based on FN
advance value estimated by bts_get_avg_fn_advance(), so it's informative
to have the final value printed out.
Change-Id: Ib50a9c23de881c66c9218833703cc41101e06bfd
|
|
|
|
| |
Change-Id: Ifb3115c7488fbcf082cc9b92abc25cf7c46064e0
|
|
|
|
|
|
| |
The function allocates x bytes not bits for the vector.
Change-Id: I60fbe9fe9acd11c5d3232207f1bb677e8a98625f
|
|
|
|
| |
Change-Id: I52b9f6b5f3e96d85a390ba2af21d7814df8aaeec
|
|
|
|
|
|
|
|
|
| |
This reverts commit b3f94eb39e19366c3458643ee329a73155d46ff8, that
unfortunately breaks some projects which call osmo_fsm_register()
on DSO load (i.e. using __attribute__((constructor))) before the
logging is initialized.
Change-Id: Idc6fcce7e946c23d48589b920e309d60aa7b6645
|
|
|
|
|
|
|
|
|
|
| |
As suggested by Vadim while reviewing a related fix for ipa_keepalive.c
in libosmo-abis (see https://gerrit.osmocom.org/#/c/libosmo-abis/+/13540/),
it makes sense to print an error message if anyone registers a FSM
that specifies an allstate_action callback but at the same time no
events that would ever end up in that callback.
Change-Id: I9e73f7363ab15a00843e3f0d1e5776f4be7ebc46
|
|
|
|
|
|
|
|
|
|
|
| |
incomplete to vty func
For instance, take command "single0 [one]":
If user executes "single0 on", VTY func will receive argv[0]="one"
instead of argv[0]="on".
Related: OS#4045
Change-Id: I5f4e2d16c62a2d22717989c6acc77450957168cb
|
|
|
|
|
|
|
|
|
|
|
| |
vty func
For instance, take command "multi0 (one|two|three)":
If user executes "multi0 tw", VTY func will receive argv[0]="two"
instead of argv[0]="tw".
Fixes: OS#4045
Change-Id: I91b6621ac3d87fda5412a9b415e7bfb4736c8a9a
|
|
|
|
|
|
|
|
| |
The test shows that in the case were "single0 on" is executed, VTY
function should return complete "single0 one" but it doesn't.
Related: OS#4045
Change-Id: Ib5b9dc07e2b280dc95011b3926afb1d490cadd81
|
|
|
|
|
|
| |
This block will become bigger in forthcoming commits.
Change-Id: Ibc1494014b1e77ce10950f7268a44d2d2091a6f2
|
|
|
|
|
|
|
| |
Check against MAX argc is changed to == since it cannot be incremented
twice without passing the check.
Change-Id: Ia330e475989fda863bedcc3cbf94deaf8dd83037
|
|
|
|
|
|
|
|
| |
It was noticed that multithreaded processes like osmo-trx can crash upon
using ctime().
Related: OS#4055
Change-Id: I19ebf29a2f1fc855bb7d56766b338c7c3432dfd1
|
|
|
|
| |
Change-Id: I697af428a2ea9a0ccd3f04ba8ec4664935ae29f8
|
|
|
|
|
| |
Related: OS#4055
Change-Id: Ief155a76169426a677256e09d3e91751c4e2529f
|
|
|
|
|
|
|
|
|
|
|
| |
the DEBUG macro name and ARRAY_SIZE macro function are frequently
used in other projects. If these projects also use libosmocore,
the macros will be redefined. This also generates a warning message
during compilation.
Not redefining the macros removes the warning message and possible
(but unlikely) mis-redefinition.
Change-Id: I0ba91eae8eacc5542d1647601b372e417ed1713c
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes the following error warnings when cross-compiling using:
./configure --enable-static --prefix=/usr/local/arm-none-eabi --host=arm-none-eabi --enable-embedded --disable-doxygen --disable-shared --disable-pseudotalloc --enable-external-tests CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs -Werror -Wno-error=deprecated -Wno-error=deprecated-declarations -Wno-error=cpp -mthumb -Os -mlong-calls -g3 -mcpu=cortex-m4 -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -Wno-error=format"
utils.c:1002:18: error: array subscript has type 'char' [-Werror=char-subscripts]
1002 | if (!isdigit(in[i]))
gsm23003.c:414:34: error: array subscript has type 'char' [-Werror=char-subscripts]
414 | if (!mnc_str || !isdigit(mnc_str[0]) || strlen(mnc_str) > 3)
Change-Id: Ia13fd5ee79fc6dc3291c0b99958ab3c01afee17d
|
|
|
|
|
|
|
|
| |
Huge conditional block inside for loop is negated in this patch
together with a "continue" keyword, similar to what was already done
recently in 4742526645d6137dd90ef369f0415afdb91736dc.
Change-Id: I803c4ed38e9ab09bf929528c75a60e6f65da3928
|
|
|
|
|
|
|
| |
Makes code easier to follow because enum values no longer look like
variables.
Change-Id: Ib6e9592c5962d047869a280c10f9b557fae6f435
|
|
|
|
| |
Change-Id: I6b486b52a3733d5fd5e8ba18acbc9374e2e8bd7e
|
|
|
|
| |
Change-Id: I085da06f31a0a6862ae2ba041fafc134cc240f7e
|
|
|
|
|
|
|
|
|
|
| |
inner block defined variable "enum match_type ret" was being masking
outter block variable "int ret = 0". The ret variable was being given
non zero values only inside the inner block, so that change was done on
the inner variable and not the outer one, which is returned.
Fixes: 5314c513f23688462d7f7937e5ae5e0d5cd4548e
Change-Id: Iec87d7db49a096d07e38ff8a060b923a52bfd6ba
|
|
|
|
|
|
|
| |
Huge conditional block inside foor loop is negated in this patch
together with a "continue" keyword.
Change-Id: I9715734ed276f002fdc8c3b9742531ad36b2ef9e
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Return ENOSPC if the decoding buffer is one byte too small, instead of
returning 0 and silently truncating the string. Add a new "truncated"
variable to detect if the loop breaks in the final iteration.
The string is not truncated if there is exactly one 0xf ('\0') higher
nibble remaining. This is covered by the existing test case "long
15-digit (maximum) MSISDN, limited buffer".
Related: OS#4049
Change-Id: Ie05900aca50cc7fe8a45d17844dbfcd905fd82fe
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is a result of discussion we had in [1]. The key idea
is that libosmovty should properly auto-complete the commands
containing choice, such as the following one:
multi0 (one|two|three)
[1] If9b0c0d031477ca87786aab5c269d00748e896c8
Right now, sending the following command:
(osmo-foo-bar)# multi0 th
would basically match the following vector:
multi0 three
however the resulting argv would be:
["multi0", "th"]
Moreover, sending the following command:
(osmo-foo-bar)# multi0 t
would basically match the following vectors:
multi0 two
multi0 three
because both start from 't', so the resulting argv would be:
["multi0", "t"]
which is ambiguous!
The expected output is:
(osmo-foo-bar)# multi0 th
ok argc=1 three
(osmo-foo-bar)# multi0 t
% Ambiguous command.
This is going to be fixed in the follow up patches.
Change-Id: I83c3aef813173952641035862c534ef16384780e
|
|
|
|
|
|
|
|
| |
Instead of copy+pasting the same LOGPFSMSRC("State change to " ...)
with slightly different trailer depending on the FSM timer, let's first
snprintf() to a stack variable and then have a single log statement.
Change-Id: I49528c4ca1fa11aef09c2092615dccca450b847c
|