Build: respect $CC, $AR, $RM, $CFLAGS, $LDFLAGS

If the user has set a value for CC, AR, or RM, use that value.  GNU make
provides good defaults for all of these.

If the user has set CFLAGS, use that instead of -O2, but preserve the
other build options.

Append the local LDFLAGS to any value from the user.
Build: respect COMPILE.c if set

The default definition from GNU make is more comprehensive.  Switch to
that, and allow an environmental override.
Build: remove redundant -rpath

LDSHFLAGS specifies -rpath, but is only used when LDFLAGS are specified,
and LDFLAGS also set the same -rpath.  Remove the redundant definition
in LDSHFLAGS.
Build: make quiet compilation optional

Switch from always hiding the executed command to hide it only by
default, but let the user request that the commands be shown.  For now,
follow the convention that setting $V requests a verbose compilation.
Mark library functions as "C" linkage

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.
Build: move $LDFLAGS before $OBJS

Move $LDFLAGS to appear earlier, in case the user specifies a
position-sensitive flag.
use size_t for sizes instead of int
made xstrdup a bit faster (theoretically)
removed malloc casts(!), changed sizeof usages

using "foo = malloc(sizeof *foo)" is more change-friendly than
"foo = malloc(sizeof (type*)"
Prevent compiler warning when compiling for 64 bit
Better solution to fix 64 bit compiler warnings

Use the size_t data type where appropriate instead of casting.
Merge pull request #14 from kevin-dot-pyle/master

Build system improvements
Merge pull request #17 from Foxtacles/upstream

Contributions by rmartinjak
Merge pull request #28 from ctourner/topic/compiler_warnings_64bit

Prevent compiler warning when compiling for 64 bit
Makefile fixes: Library build, targets

Changed the build command for the static library to include all objects
and added .PHONY for the targets that do not create files of the same
name.
Merge pull request #34 from marhry/makefile_fix

Makefile fixes: Library build, targets
Fix crash with crafted ini files.

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: Andreas Schneider <asn@samba.org>
Merge pull request #35 from gladiac/master

Fix crash with crafted ini files.
modify iniparser to build unbounded keys & values from multi-line input

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: Noel Power <noel.power@suse.com>
Merge pull request #37 from noelpower/dynamic_string_alloc_v2

modify iniparser to build unbounded keys & values from multi-line input