Warnings for .NET framework and non-constant format string in OSX application?

When compiling an OSX command-line application I get the warnings below following an otherwise-successful build.

a) Why am I getting a warning about the .NET framework being missing? How can I get this to go away?

b) Why should there be a warning for a format string passed to String.stringWithFormat as a variable rather than as a manifest constant? I’d like to be able to supply the desired format string to my class at runtime.

Warnings:

/Users/jobrien/Source/UnitOOPS/Nougat/ConsoleApplication1/ConsoleApplication1.sln (Build) ->
(Build target) ->
/Users/jobrien/Source/UnitOOPS/Nougat/ConsoleApplication1/ConsoleApplication1/ConsoleApplication1.oxygene (default targets) ->
/Applications/Fire 2.app/Contents/Resources/Mono/lib/mono/4.5/Microsoft.Common.targets (GetReferenceAssemblyPaths target) ->

        /Applications/Fire 2.app/Contents/Resources/Mono/lib/mono/4.5/Microsoft.Common.targets:  warning : Unable to find framework corresponding to the target framework moniker '.NETFramework,Version=v4.0'. Framework assembly references will be resolved from the GAC, which might not be the intended behavior.

/Users/jobrien/Source/UnitOOPS/Nougat/ConsoleApplication1/ConsoleApplication1.sln (Build) ->
(Build target) ->
/Users/jobrien/Source/UnitOOPS/Nougat/ConsoleApplication1/ConsoleApplication1/ConsoleApplication1.oxygene (default targets) ->
/Applications/Fire 2.app/Contents/Resources/XbuildTargets/RemObjects Software/Oxygene/RemObjects.Oxygene.Nougat.targets (CoreCompile target) ->

        /Users/jobrien/Source/UnitOOPS/Nougat/ConsoleApplication1/ConsoleApplication1/uMatrix.pas(147,62): warning NW3: Format string should be a literal
        /Users/jobrien/Source/UnitOOPS/Nougat/ConsoleApplication1/ConsoleApplication1/Program.pas(208,5): warning NW3: Format string should be a literal

         3 Warning(s)
         0 Error(s)

Time Elapsed 00:00:02.6732150

Good Q. its a weird xbuild issue i need to look at

it’s a security thing. stringWithFormat, like printf or NSLog, expects parameters on the stack that exactly match what the string expects. if the string is generated at runtime, you cannot be sure it matches the parameters passed to it. So that’s considered bad practice. Of corse you’re free to hide and ignore the warning, but you really should not.

What is it you are trying to achieve? Where would the format string come from, and how are you planning to ensure it matches the parameters?

—marc

Thanks, logged as bugs://71055

It’s for display in a matrix class I wrote. I want the option of formatting the numbers to a precision I decide at runtime, for example.

IOW Your code has full control over the generated format string? I guess that is a corner case that’s Accra le. I suggest just adding $HIDE around the call, with a comment, and passing the non-static format string.

Thanks. I’ll do that.

I wouldn’t have thought it a corner case, though. Any time you want to let a user decide how an output number should look you’d need it (writing a report, a spreadsheet-like view, etc, etc). I guess it’s no big deal to write an “ftoa” function. Even so, I’m often surprised at the things that are regarded as “unusual” (my background being in scientific and financial computing, rather than in computer science per se).

By the way, I had my String.stringWithFormat(aFormatStringVariable, aFloat) call inside a method AsString of a class. I note that the warning was issued twice - at that line in the implementation of AsString, but also in another file where I called the method AsString. The second case surprised me.

That sounds like a bug. can you send me a small testcase that illustrates this?

I’m looking at this now, and i cannot reproduce :(. but i KNOW i have seen this myself in the past. do you have steps for when this shoes or doesn’t show for you? does it show for EVERY project for you? are you using internal or external compiler?(i tried both ofc, but i don’t get the warning right now :(.)

Sorry about the delay. This isn’t tiny but it does show the issue. The relevant messages from the build log are:

    /Users/jobrien/Source/UnitOOPS/Nougat/ConsoleApplication1/ConsoleApplication1/uMatrix.pas(147,62): warning NW3: Format string should be a literal
    /Users/jobrien/Source/UnitOOPS/Nougat/ConsoleApplication1/ConsoleApplication1/Program.pas(208,5): warning NW3: Format string should be a literal

This project also exhibits the warning about not finding the .NET 4 framework.

Jim.Example for Marc 2.zip (8.9 KB)

I don’t see that one.Can you confirm whether that still shows for you with the next Fire build due tonight?

I do see the double

    /Users/mh/Downloads/ad3d7e34488105cd/ConsoleApplication1/uMatrix.pas(147,62): warning NW3: Format string should be a literal
    /Users/mh/Downloads/ad3d7e34488105cd/ConsoleApplication1/Program.pas(208,5): warning NW3: Format string should be a literal

and will log that.

Thanks, logged as bugs://71153

bugs://71153 got closed with status wontfix.

Actually,both of tnhse are designed, because both times yuo ar not passing literal:

aLine := aLine + ' ' + String.stringWithFormat(aFormat, self[i,j]); // Format string should be a literal
NSLog(a.AsString('%.4f')); // Format string should be a literal

you can avoid the second using the proper technique:

NSLog('%@', a.AsString('%.4f'));

Oh, I see - I wasn’t passing ANY format string, so my a.AsString… was interpreted as a non-constnat format string. Sigh.

I’ll check it against tonight’s build. Is there anything else in my configuration I should look at?

Maybe check what Mono version your using. Aside from that, i can’t imagine what could cause the difference.

Right but since I’m using the internal compiler, isn’t that moot?

But in case it matters:

mono --version
Mono JIT compiler version 3.2.7 ((no/40f92d5 Thu Feb  6 18:29:16 EST 2014)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
    TLS:           normal
    SIGSEGV:       altstack
    Notification:  kqueue
    Architecture:  x86
    Disabled:      none
    Misc:          softdebug
    LLVM:          yes(3.4svn-mono-(no/e656cac)
    GC:            sgen

Oh wow. thats OLD. Try if updating to 3.10 or later fixes the, pls.

OK, but why does it matter? I thought everything in Fire was self-contained to use the internal mono.