Fwd: Cell_log > gsmmap

[Pierre Pronchery]

			Hi,

On 01/26/2011 21:28, Holger Hans Peter Freyther wrote:
> On 01/26/2011 05:55 PM, Pierre Pronchery wrote:
>> On 01/25/2011 16:34, Holger Hans Peter Freyther wrote:
>>>
>>> 2.) snprintf will not add a '\0' of optarg is of the length of 32 or longer
>>
>> Actually it does, even though it may truncate the resulting string in
>> the process:
>>
>>    « snprintf() and vsnprintf() will write at most size-1 of the
>>      characters printed into the output string (the size'th character
>>      then gets the terminating `\0') »
> 
> The trailing null byte won't be added to str, if the  string  is  truncated.
> 
> from man snprintf on a Linux machine.

first, I have to admit that the manual on Linux is very confusing and
unclear about snprintf(), which is why I pasted an extract from BSD.

Still, if you do:
=== BEGIN PASTE ===
$ cat snprintf.c && make snprintf && ./snprintf
#include <sys/utsname.h>
#include <stdio.h>
#include <string.h>

int main(void)
{
        struct utsname uts;
        char buf[16];
        int res;

        if(uname(&uts) == 0)
                printf("%s %s\n", uts.sysname, uts.release);
        memset(buf, 0xff, sizeof(buf));
        res = snprintf(buf, 4, "%s", "AAAAAAAA");
        printf("snprintf() returned %d, buf[3] = 0x%02x\n", res, buf[3]);
        return 0;
}
cc     snprintf.c   -o snprintf
Linux 2.6.9-023stab052.4-enterprise
snprintf() returned 8, buf[3] = 0x00
=== END PASTE ===

Which would tend to argue in my direction, as this was run on a Debian
Lenny host.

However, as I was kindly reminded by a friend in the meantime, you are
also right. Even though POSIX/SUSv3 itself says:

http://pubs.opengroup.org/onlinepubs/009695399/functions/printf.html

« The sprintf() function shall place output followed by the null byte,
'\0', in consecutive bytes starting at *s; it is the user's
responsibility to ensure that enough space is available.

The snprintf() function shall be equivalent to sprintf(), with the
addition of the n argument which states the size of the buffer referred
to by s. If n is zero, nothing shall be written and s may be a null
pointer. Otherwise, output bytes beyond the n-1st shall be discarded
instead of being written to the array, and a null byte is written at the
end of the bytes actually written into the array. »

(the last sentence is important here)

there are platforms indeed which do not respect this:
http://msdn.microsoft.com/en-us/library/2ts7cx93%28v=vs.80%29.aspx

So on Windows you are right.

Now I guess the question is: is OsmocomBB intended to support non-POSIX
platforms natively?

HTH,
-- 
khorben