[chbot] Weirdness in parameter interpretation in C lib function

[Robin Gilks]

You make the same assumption as the library coder - that 'size' is the
length of the output buffer. The man page says otherwise

*The functions snprintf() and vsnprintf() write at most size bytes
(including the terminating null byte ('\0')) to str.*


*This is defining the amount written, not the maximum the outbuffer can
hold - nowhere does it say that 'size' is the length of 'str'*



On Tue, Jul 30, 2024 at 11:12 AM Simeon Pilgrim <simeon.pilgrim at gmail.com>
wrote:

> ```
> char* test(uint8_t index)
> {
> #define DEST_BUF_SIZE 100
>
>   if (index < NUMRESULTS) {
>     static char buf[DEST_BUF_SIZE];
>
>     snprintf(buf, DEST_BUF_SIZE, "SSID %s\n", scandata[index].ssid);
>     return buf;
>   }
>   return "INVALID INDEX";
> }
> ```
>
> On Tue, 30 Jul 2024 at 11:05, Simeon Pilgrim <simeon.pilgrim at gmail.com>
> wrote:
>
>> you have provided a pointer (to memory), AND you have declared it 30
>> bytes long. This is what YOU HAVE done. The compiler is HELPING YOU by
>> pointing out 37 > 30, which it is.
>>
>> If you want the compiler to help you correctly, tell the compiler the
>> length of the data you have, which is 100.
>>
>>
>>
>>
>>
>> On Tue, 30 Jul 2024 at 10:58, Robin Gilks <gb7ipd at gmail.com> wrote:
>>
>>> But I've provided 100 bytes, not 30!!
>>>
>>> On Tue, Jul 30, 2024 at 10:40 AM Simeon Pilgrim
>>> <simeon.pilgrim at gmail.com> wrote:
>>> >
>>> > the second parameter should be the size of the destination buffer,
>>> thus the code should be:
>>> >
>>> > snprintf (buf, 100, "SSID %s\n",
>>> >
>>> > or
>>> >
>>> > snprintf (buf, sizeof(buf), "SSID %s\n",
>>> >
>>> > your format string is 7 tokens (6 + zero termination) + the 30 byte
>>> string ssid, which is larger than 30 you have provided.
>>> >
>>> > The snprintf functions are "safe truncation" functions, not handy
>>> dandy truncation utilities, thus the warning that you might have truncation.
>>> >
>>> > On Tue, 30 Jul 2024 at 10:27, Robin Gilks <gb7ipd at gmail.com> wrote:
>>> >>
>>> >> Since there are a few C programmers in the group I thought I'd ask
>>> >> this (interesting?) question
>>> >>
>>> >> Here is a bit of sample code to illustrate:
>>> >>
>>> >>
>>> ----------------------------------------------------------------------------
>>> >> #include <stdio.h>
>>> >> #include <stdint.h>
>>> >>
>>> >>
>>> >> typedef struct
>>> >> {
>>> >> char ssid[30];
>>> >> int8_t rssi;
>>> >> } ScanResult;
>>> >>
>>> >> #define NUMRESULTS 50 // how many tracked simultaneously
>>> >>
>>> >> static ScanResult scandata[NUMRESULTS];
>>> >>
>>> >> void
>>> >> main (void)
>>> >> {
>>> >> }
>>> >>
>>> >>
>>> >> char * test (uint8_t index)
>>> >> {
>>> >> static char buf[100];
>>> >>
>>> >> snprintf (buf, sizeof (scandata[index].ssid), "SSID %s\n",
>>> >> scandata[index].ssid);
>>> >> return buf;
>>> >>
>>> >> }
>>> >>
>>> ----------------------------------------------------------------------------
>>> >> Save as test.c; compile with gcc test.c
>>> >>
>>> >> The warning indicates that the destination buffer may be too small
>>> >>
>>> >> test.c: In function ‘test’:
>>> >> test.c:25:56: warning: ‘%s’ directive output may be truncated writing
>>> >> up to 29 bytes into a region of size 25 [-Wformat-truncation=]
>>> >>    25 |    snprintf (buf, sizeof (scandata[index].ssid), "SSID %s\n",
>>> >> scandata[index].ssid);
>>> >>       |                                                        ^~
>>> >> test.c:25:4: note: ‘snprintf’ output between 7 and 36 bytes into a
>>> >> destination of size 30
>>> >>    25 |    snprintf (buf, sizeof (scandata[index].ssid), "SSID %s\n",
>>> >> scandata[index].ssid);
>>> >>       |
>>> >>
>>> >> This appear to be treating the size parameter in the snprintf as being
>>> >> the size of the output buffer 'buf' (which is 100 bytes long) but
>>> >> surely it should be applying the restriction on the format string that
>>> >> includes  scandata[index].ssid (which is 30 bytes long)
>>> >>
>>> >> Am I just having brain fade or is that just fundamentally wrong?
>>> >>
>>> >> --
>>> >> Robin Gilks
>>> >>
>>> >> _______________________________________________
>>> >> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
>>> >> https://lists.ourshack.com/mailman/listinfo/chchrobotics
>>> >> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
>>> >> Meetings usually 3rd Monday each month. See http://kiwibots.org for
>>> venue, directions and dates.
>>> >> When replying, please edit your Subject line to reflect new subjects.
>>> >
>>> > _______________________________________________
>>> > Chchrobotics mailing list Chchrobotics at lists.ourshack.com
>>> > https://lists.ourshack.com/mailman/listinfo/chchrobotics
>>> > Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
>>> > Meetings usually 3rd Monday each month. See http://kiwibots.org for
>>> venue, directions and dates.
>>> > When replying, please edit your Subject line to reflect new subjects.
>>>
>>> _______________________________________________
>>> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
>>> https://lists.ourshack.com/mailman/listinfo/chchrobotics
>>> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
>>> Meetings usually 3rd Monday each month. See http://kiwibots.org for
>>> venue, directions and dates.
>>> When replying, please edit your Subject line to reflect new subjects.
>>
>> _______________________________________________
> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/chchrobotics
> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> Meetings usually 3rd Monday each month. See http://kiwibots.org for
> venue, directions and dates.
> When replying, please edit your Subject line to reflect new subjects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20240730/f69ea286/attachment-0001.html>