LStrPrintf signedness warning in CIN app

[BearFlag]

I am running Xcode on Mac OS 10.5, and Labview 8.6 i get a warning error, but it compiles and executes it appears to have something to do with an undefined 'char' bit field, but I think I am using the LStrPrintf command properly... but the error persists, and it is the type that makes one suspect danger if you let it be.

The warning is following:

LStrPrintf(arg1,"Insert whatever text you want\n");
!warning: pointer targets in passing argument 2 of "LStrPrintf" differ in signedness

[zou]

On Windows, I would do sth like this:

char     arg1[256];

LStrPrintf(arg1, "%s", "Insert whatever text you want\n");

No error or warning.

Not sure about MacOS.

George Zou

http://webspace.webring.com/people/og/gtoolbox/

[BearFlag]

... this did not help  

char arg2[256];
   

LStrPrintf(arg2,"%s","Insert any text you want\n");

!warning: passing argument 1 of 'LStrPrintf' from incompatible pointer type

!warning: pointer targets in passing argument 2 of 'LStrPrintf' differ in signedness

[RavensFan]

If you have a type char for arg2, how can you pass it the integer 256?  Wouldn't it have to be between 0 and 255?

[zou]

---

Ravens Fan wrote:
If you have a type char for arg2, how can you pass it the integer 256?  Wouldn't it have to be between 0 and 255?

---

char arg2[256];        //declare a string, max 256 characters.

[zou]

Oops.  My mistake.

It should be:

LStrHandle      arg2;          // LabVIEW string

LStrPrintf(arg2, "%s\n", "Insert any text you want.");

George

[BearFlag]

negatory, that just gets me back to where I started. In the original funtion arg1 came thru CIN in the main appication function call. This program is the epitome of complicated. hahahah

#include "extcode.h"
#include <stdlib.h>

CIN MgErr CINRun(LStrHandle arg1);


CIN MgErr CINRun(LStrHandle arg1) {
       
    LStrPrintf(arg1,"Any text you want\n");
   
    return noErr;
}
 

[BearFlag]

My guess is that the Windows compiler is not ANSI compatible and therefore is unaware of this problem. Also My guess it is just err for loss of better words "sloppy" programming on NI's part ofr LStrHandle type data. I imagine it throws similar warnings in GCC

I am going to try this. Though it doens't seem to adress why ---->"Any text you want"<---- sees it as an undefined sign data type.

INT12-C. Do not make assumptions about the type of a plain int bit-field when used in an expression: https://www.securecoding.cert.org/confluence/display/seccode/INT12-C.+Do+not+make+assumptions+about+... 

Noncompliant Code Example

This noncompliant code depends on implementation-defined behavior.  It prints either -1 or 255 depending on whether a plain int bit-field is signed or unsigned.

struct {
  int a: 8;
} bits = {255};

int main(void) {
  printf("bits.a = %d.\n", bits.a);
  return 0;
}

Compliant Solution

This compliant solution uses an unsigned int bit-field and does not depend on implementation-defined behavior.

struct {
  unsigned int a: 8;
} bits = {255};

int main(void) {
  printf("bits.a = %d.\n", bits.a);
  return 0;
}

Risk Assessment

Making invalid assumptions about the type of a bit-field or its layout can result in unexpected program flow.

[BearFlag]

following the notes from my previous post.... I included a code segment.

struct {
    unsigned int a: 1;
} bits = {255};

!warning: large integer implicitly truncated to unsigned type

CIN MgErr CINRun(LStrHandle arg1);

CIN MgErr CINRun(LStrHandle arg1) {

     LStrPrintf(arg1,"How many LabJacks are connected\t%i\n", bits.a);

    !warning: pointer targets in passing argument 2 of "LStrPrintf" differ in signedness

    return noErr;
}

[rolfk]

The prototype for LStrPrintf is MgErr LStrPrintf(LStrHandle t, CStr fmt, ...)

CStr again is defined as uChar *CStr and uChar is specifically defined as unsigned char.

So the LStrPrintf() function expects as its second argument a pointer to unsigned char. This has nothing to do with the LStrHandle but with the fact that some modern compilers are very particular about what type they assign to literal string constants and even more picky about any mismatch between a parameter type and the actual type of that variable assigned to it. In the case of literal string constants one could argue that this pickiness is simply ridiculous but it is nevertheless the case.

Most C compilers come with a compile switch that tells the compiler to use unsigned character type as default for strings type and that is how LabVIEW is programmed and its external code header file therefore is written. This could be a problem if you use other libraries too that prefer signed character strings but there is simply no solution that fits all. LabVIEW assumes unsigned strings by default and that is how things are. LabVIEW string functions are also fully 8 bit aware so unsignedness makes sense too. Signed strings could be considered 7 bit ASCII strings only if you take it strictly.