I unintentionally compiled the following statement:
manager.groupName - lastGroupName;
Instead of:
manager.groupName = lastGroupName;
I am trying to understand why the compiler does not even provide a warning for the former statement I unintentionally provided. The statement has no effect, even it if is legal to subtract pointers from one another.
Both groupName and lastGroupName are of type (NSString *).
The groupName property is declared as:
#property (nonatomic, retain) NSString *groupName;
Wondering if I should visit bugreporter or if there is a reason that XCode isn't providing a diagnostic.
This is a legal statement in C and thus also in Objective-C, so the compiler doesn’t have to warn about it. You could add the warning flag -Wunused-value to the compiler settings. This warns about statements without effect like this.
Generally there are lots of flags to tell the compiler what exactly to warn about. Everybody has different ideas what is OK, and what should be warned about. If the compiler emits too many warnings they become useless.
Also note that clang does indeed produce better warning and error messages it doesn’t mean that it will automatically produce more warnings. It also has the same flags for enabling and disabling certain warnings that gcc has.
XCode doesn't have the best syntax checking, although it's supposed to be much better in the version coming out soon (4.0 I believe, in beta now).
Registered developers can download XCode 4 beta which improves syntax checking in the "clang" 2.0 front-end. You can get some of that now by selecting "llvm" with clang 1.5 as your compiler instead of GCC. Apple's current recommendation is the GCC front-end and LLVM 1.5 back-end, but then you'll still be stuck with GCC's awful error messages.
I'd recommend downloading XCode 4 and trying the code out on that. You might find some significant bugs that you can go back and fix in XCode 3 before release.
In addition, periodically doing a "Clean All" and "Compile and Analyze" will find a lot of common mistakes. Highly recommended, especially if you're stuck on something.
This is legal syntax, so no error should be expected. It does seem useless, and a high quality compiler might issue a warning.
At runtime the result is a different matter. Unless I'm misremembering this is undefined behavior unless the two pointers are the same or at least point into the same array.
Related
In this line of code:
NSInteger answer = 3; NSString *s = [NSString
stringWithFormat:#"%ld",answer];
In Xcode 10.3, under a debug build there is no error.
Under release builds I get this error:
values of type 'NSInteger' should not be used as format arguments; add
an explicit cast to 'long' instead [-Werror,-Wformat]
I understand the why on the error, that I should also cast answer to (long), and the compiler will complain and fix the issue if I start with #"%d". But when the ld is there the compiler in debug builds keeps quiet, but in release it raises a flag.
Any ideas as to what setting would cause this to happen?
Thanks in advance!
The answer to your question is pretty broad, but I think you should get an idea. Like the above comment there's a whole bunch of factors that filter the changes its going to take when building for debug and building for production release. For performance and compatibility apple is very strict on releases. Thus the default values for some of the build configs in the Build settings is pretty different from Building for debug and release.
Take a look at the images attached below:
Note : Most of them can be customized for your preference but it does effect the building process as well as the delivery!
With a snippet like
perl6 -e 'loop { FIRST say "foo"; last }'
I get
WARNINGS for -e:
Useless use of LOOP_BLOCK_1 symbol in sink context (line 1)
foo
I know how to work around the warning. I'm wondering about what the source of the warning is. I found this open ticket, but it doesn't seem to have received any attention.
What is this warning about?
And what about this is useless?
Version
$ perl6 --version
This is Rakudo version 2018.06 built on MoarVM version 2018.06
implementing Perl 6.c.
It's a bug, a bogus warning.
I know how to work around the warning.
That's the main thing.
I'm wondering about what the source of the warning is.
It's a bogus warning from the compiler.
I found this open ticket, but it doesn't seem to have received any attention.
I think it got some attention.
bbkr, who filed the bug, linked to another bug in which they showed their workaround. (It's not adding do but rather removing the FIRST phaser and putting the associated statement outside of the loop just before it.)
If you follow the other links in bbkr's original bug you'll arrive at another bug explaining that the general "unwanted" mechanism needs to be cleaned up. I imagine available round tuits are focused on bigger fish such as this overall mechanism.
Hopefully you can see that it's just a bizarre warning message and a minor nuisance in the bigger scheme of things. It appears to come up if you use the FIRST phaser in a loop construct. It's got the very obvious work around which you presumably know and bbkr showed.
What is this warning about?
Many languages allow you to mix procedural and functional paradigms. Procedural code is run for its side effects. Functional code for its result. Some constructs can do both.
But what if you use a construct that's normally used with the intent of its result being used, and the compiler knows that, but it also knows it's been used in a context in which its value will be ignored?
Perls call this "useless use of ... in sink context" and generally warn the coder about it. ("sink" is an alternative/traditional term for what is often called "void" context in other language cultures.)
This error message is one of these warnings, albeit a bogus one.
And what about this is useless?
Nothing.
The related compiler warning mechanism has gotten confused.
The "Useless use of ... in sink context" part of the message is generic and hopefully self-explanatory.
But there's no way it should be saying things like "LOOP_BLOCK_1 symbol". That's internal mumbo-jumbo.
It's a warning message bug.
Its driving me crazy, I spend soo much time getting it wrong, and then fixing it wrong.
I'm thinking of using -= and =- as delineators, but it probably means a lot of hours in learning how to fool the compiler into a substitution. Is this a quixotic quest? can such be done? has it been done already, albeit with different keystrokes?
I work alone. I don't collaborate.
So I don't mind a non-standard work environment
If I need to in the future i could make a scheme whereby both could work.
Not without building your own custom version of the preprocessor. Comment syntax is an inherent part of the language and is not designed to be configurable.
(Incidentally, -= is already a token in Objective-C — it means "assign to LHS the result of subtracting RHS from LHS.")
It should be possible to extend clang, then modify your Xcode builds to include your clang extensions. I have no personal experience with writing complier extension for clang, but I did work on a tool that extended cl.exe. Warning: this would be a very deep dive into the internals of the build system.
Extending Clang
Good Luck
I know that I can ignore compiler warnings with -w on a given file in Xcode.
I would like to similarly ignore analyze warnings on a given file (JSONKit.m in this case, which has two potential leaks). I trust that the developer of that library knows what they're doing, and I don't want to maintain a fork of it. Not to mention that I have no clue what's going on in there anyway.
Any ideas?
Don't trust the developer. Figure out why the potential leaks exist and fix them (ideally, sending a patch back to the developer).
If you want to take the lazy way out (j/k ;), you can add code to fix the problem under the analyzer only using:
#ifdef __clang_analyzer__
... release the offending variable here ...
#endif
I prefer this solution to whole-file-disabling because it both exactly identifies the problem area with an easily searchable identifier and it allows the rest of the file to be vetted by the constantly improving analyzer.
I'm working on an iPhone with a group of people over github. I was added to the project late and just started today. I am unable to build the project which I find extremely annoying. The reason is that Arc forbids synthesizing a property of an objective-c object with unspecified ownership or storage attribute. There 8 errors like this preventing building and over 300 warnings that turn into errors as I fix the errors, i.e. if I were to fix 3 of the 8 errors 3 of the 300 warnings would replace them as errors. So while I could go through and add weak or strong to all these many properties throughout the project it'd be a tad tedious and I'm not entirely sure that it'd be good for the project. The other people I'm working with are surprised I'm having errors and are able to build it. My question is how the heck can they build it? is there a setting somewhere that changes the default from assign to strong or something? thanks in advance this is driving me crazy.
For posterity, this issue is resolved in Xcode 4.4.