Description:add BUILD.gn for iniparser
Team:OTHERS
Feature or Bugfix:Feature
Binary Source:No
PrivateCode(Yes/No):No

Change-Id: I5931108f35c42269fb9b265b923948a1911a4f0f
Reviewed-on: http://mgit-tm.rnd.huawei.com/6219745Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Npengjianxin 00207387 <pengjianxin@huawei.com>

Change iniparser_getint64(...) to iniparset_getlongint(...) and add unittest for iniparser_getlongint(...) and also add interface for longint equal in CuTest.h/CuTest.c.

getseckeys and getsecnkeys were buggy, did not work properly for
non-lowercase section names. Bug fixed.

This fixes invalid write.

Signed-off-by: NNoel Power <noel.power@suse.com>

Signed-off-by: NNoel Power <noel.power@suse.com>

Signed-off-by: NNoel Power <noel.power@suse.com>

Signed-off-by: NNoel Power <noel.power@suse.com>

Signed-off-by: NNoel Power <noel.power@suse.com>

Signed-off-by: NNoel Power <noel.power@suse.com>

Instead of a size limit of ASCIILINESZ for multi-line input now there is no
limit, a multi-line can be *any* size (and hence the key and value now
also have a dynamic size)

* there is a limit still on input line size (since multi lines are built
  from multiple lines where each line part is limited to ASCIILINESZ)
  Note: there is no limit to the size of the multi-line itself (it's
  only limited by available memory)
* all stack & static fixed string usage has been removed with the exception
  of parsing line (or a multi-line portion) input, fgets still reads into
  a fixed string buffer of size ASCIILINESZ.
Signed-off-by: NNoel Power <noel.power@suse.com>

Instead of a size limit of ASCIILINESZ for multi-line input now there is no
limit, a multi-line can be *any* size (and hence the key and value now
also have a dynamic size)

* there is a limit still on input line size (since multi lines are built
  from multiple lines where each line part is limited to ASCIILINESZ)
  Note: there is no limit to the size of the multi-line itself (it's
  only limited by available memory)
* all stack & static fixed string usage has been removed with the exception
  of parsing line (or a multi-line portion) input, fgets still reads into
  a fixed string buffer of size ASCIILINESZ.
Signed-off-by: NNoel Power <noel.power@suse.com>

If the key or value is bigger than 1024 we will end up in a buffer
overflow. The overflow is caught by _FORTIFY_SOURCE, so it's definitely
DoS-only.  Curiously, because of ample space in the stack frame, it does
not result in a crash without _FORTIFY_SOURCE in all cases.
Signed-off-by: NAndreas Schneider <asn@samba.org>

Use the size_t data type where appropriate instead of casting.

using "foo = malloc(sizeof *foo)" is more change-friendly than
"foo = malloc(sizeof (type*)"

The documentation disclaims support for building with a C++ compiler, so
it is reasonable to assume that the library will be built with a plain C
compiler, so the functions will all have plain C linkage.  By default, a
C++ application that wished to use libiniparser would need to wrap the
inclusion of libiniparser headers in 'extern "C" { ... }' to reflect the
C linkage of libiniparser.  Instead, place that marker directly in the
libiniparser headers, so that client applications do not need to care.
This has no effect on normal compilation of libiniparser, since the new
markers are inside a '#ifdef __cplusplus' guard, and straight C
compilers do not define __cplusplus.