Sometimes I will get incorrect error-highlighting on a closing parenthesis or brace. Here is a good example using a function pointer:
Now, unless I have a syntax error that I'm not seeing (please point it out if so!), how would I get rid of this formatting? Is there a particular setting or perhaps syntax file where this can be fixed?
Related
this is an exert of the code foor a game that I am writing.
(for [sprite self.sprites]
(if (!= (type sprite.content) NoneType)
(sprite.content.render)))
it complains about a parse error for pattern macro 'if': got unexpected end of input, expected: some(...), even though thus IS valid Hy code.
Ran with both Hy version 0.25.0 on PyPy, 0.24.0 and 0.25.0 on CPython. Still threw the same error. The code should not have thrown the error at all, because it was working perfectly fine yesterday, I come back today and it'd throw an error, despite no changes.
This is not, in fact, valid Hy code. As suggested by the error message, if requires a third argument. See the manual entry on if.
As for how this code could've been "working perfectly fine yesterday", I have no explanation, unless you were using a different version of Hy yesterday.
I'm trying to get used to Emacs, I'm coding in C for my school. So, I installed flycheck to check for potential compliation errors. However, I encounter several problems. Here's the message I get when I test flycheck with the c/c++-gcc checker : flycheck buffer
I have two issues there : - first, flycheck claims the checker "returned a 1 exit code without errors" depsite the fact it actually did, and it's even displaying it right after ! - secondly, it does not seem to be able to display quotes correctly, the only thing displayed are their unicode escape sequences.
I can't find out why those issues are present. Can anybody help me on this ?
fixed both my problems by setting my environment language to UTF-8.
Sir..
switch (skb->protocol) {
case cpu_to_be16(ETH_P_IP):
this is my code, cpu_to_be16(ETH_P_IP) is the macro name.
after passing it to clang-format-3.4
i got
switch (skb->protocol) {
case cpu_to_be16(ETH_P_IP) :
here i dont want space before colon(in between closing bracket and colon). according to linux coding style it is error. i tried with almost all different configuration(.clang-format file), but it introduces space. how to fix it?
Sir..
There is no compilation error..
According to linux kernel coding style(www.kernel.org/doc/Documentation/CodingStyle) there should not be space before colon in case statement. When I passed code through linux/checkpatch.pl there will be error(ERROR: space prohibited before that ':'). No problem with copilation.
Solved: In clang-format-3.6 problem gets solved. it has not introduced space before colon. Thank you.
I've got a lot of source code in front of me (almost 500 lines) and GCC keeps throwing an error that it didn't expect my brackets at the end of my function declaration because it expected a parenthesis instead. I can't see the unclosed parenthesis myself, and GCC isn't telling me where the expected character's match is on its own (only where the character was expected). What arguments could I pass to GCC to get it to tell me where it is?
You can try to use an auto indenter. When the number of brackets is wrong, the auto indentation will stop to work around that line.
Im trying to compile z/lib on z/OS USS(thats right a mainframe). ive got gmake and the c89 compiler (which im assuming is c89 standards compliant) and USS is supposed to be POSIX compliant.
But zlib seems to be tripping up on
struct internal_state FAR *state; /* not visible by applications */
with the following error(s)
c89 -O3 -DUSE_MMAP -D_XOPEN_SOURCE_EXTENDED=1 -D_POSIX_SOURCE -c -o example.o example.c
ERROR CCN3277 ./zlib.h:92 Syntax error: possible missing ';' or ','?
ERROR CCN3007 ./zlib.h:92 "struct internal_state" is undefined.
ERROR CCN3166 ./zlib.h:103 Definition of function FAR requires parentheses.
ERROR CCN3276 ./zlib.h:103 Syntax error: possible missing '{'?
ERROR CCN3273 ./zlib.h:124 Missing type in declaration of gz_header.
ERROR CCN3166 ./zlib.h:126 Definition of function gz_header requires parentheses.
ERROR CCN3276 ./zlib.h:126 Syntax error: possible missing '{'?
WARNING CCN3137 ./zlib.h:1346 Declaration must declare at least one declarator, tag, or the members of an enumeration.
ERROR CCN3275 ./zlib.h:1350 Unexpected text z encountered.
ERROR CCN3282 ./zlib.h:1350 The type of the parameters must be specified in a prototype.
ERROR CCN3275 ./example.c:95 Unexpected text file encountered.
ERROR CCN3045 ./example.c:95 Undeclared identifier gzFile.
ERROR CCN3046 ./example.c:96 Syntax error.
ERROR CCN3045 ./example.c:98 Undeclared identifier file.
ERROR CCN3019 ./example.c:523 Expecting an array or a pointer to object type.
ERROR CCN3280 ./example.c:527 Function argument assignment between types "const char*" and "int" is not allowed.
CCN0793(I) Compilation failed for file ./example.c. Object file not created.
FSUM3065 The COMPILE step ended with return code 12.
FSUM3017 Could not compile example.c. Correct the errors and try again.
gmake: *** [example.o] Error 3
when i progressively take out the FAR * (i think its a far pointer but im really not that sure) the errors go away. But as this is a library, im not sure what other artifacts are going to be produced by removing this.
has anybody got any ideas?
any old mainframe heads out there?
it turns out there is a previous version of zlib that compiles on USS, version 1.1.4 or close to that. Its a back level, but i presume this works because it is before the implementation of the FAR pointer in the latest code. So atm i think ive got it to work.
thanks for all your help.
Regards
Mark.
FAR is not a C89 keyword, it is a Microsoft/Intelism and is probably #defined somewhere. If not, you need to define it as nothing:
#define FAR
However, this will probably only fix one of many problems. I would guess that the library uses some form of conditional compilation to handle things like FAR pointers - you need to read the docs to find which configuration is most suitabkle for your platform.
I'd use xlc instead of c89 since xlc is your system default compiler but you'll still probably have issues. I'd subscribe to the MVS-OE email list, the people on it are quite helpful. The link to info about the list appears to be down now so send email to
LISTSERV#VM.MARIST.EDU
with the message: INFO MVS-OE
FWIW, IBM provides a prebuilt version of zlib that includes support for the compression hardware (so-called zEDC) available on recent-vintage mainframes. See zlib for zEnterprise Data Compression