emacs flycheck errors and display issues - c

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.

Related

On MacOS Catalina with latest XCode, __DARWIN_C_LEVEL is too low for String.h... what should I do?

I'm starting a new job. I'm a windows guy that has been working in the Microsoft stack for decades. The new job calls for work to be done on a Mac, and I'll be working in straight C code. It's interesting, and I vaguely remember using it a tiny amount in the mid-90s. But I'm running into a problem. When I try to compile the code ("make" command on the command line tool) it throws an error...
The codebase I'm learning is trying to use the *strdup(const char *__s1) function/method as defined in the string.h include file. When I look at that header, I see where it would be defined, but there's a preprocessor if-block around it that looks like...
#if __DARWIN_C_LEVEL >= 200112L
Looking around for that __DARWIN_C_LEVEL variable online... I see people asking what it is, but I haven't seen anything about what to do if your value is too low. I tried looking for a way to alter a config file or something on my machine so that value would just be high enough, but I can't find that. Is there something I need to update so that the code does what I want?
As an additional note, the only other guy at work that does anything in this code base works on a straight linux machine and edits the code with Vi. He's obviously an expert in the code base and his environment, but doesn't know how to help with trying to get this running on MacOS.
Any help would be appreciated.
Edit 9 November 2020
I'm beginning to believe I don't actually have the latest version of XCode if that would explain the issue. I haven't gotten a response, but I'm asking about help with that piece here at work.
I'm also trying suggestions. When I try the option for std=gnu11...
make -std=gnu11
/Library/Developer/CommandLineTools/usr/bin/make: invalid option -- =
/Library/Developer/CommandLineTools/usr/bin/make: invalid option -- g
/Library/Developer/CommandLineTools/usr/bin/make: invalid option -- u
/Library/Developer/CommandLineTools/usr/bin/make: invalid option -- 1
/Library/Developer/CommandLineTools/usr/bin/make: invalid option -- 1
If I remove the equal sign, it seems to like it better but still has errors...
make -std gnu11
[...]
No implicit rule found for 'gnu11'.
Finished prerequisites of target file 'gnu11'.
Must remake target 'gnu11'.
make: *** No rule to make target `gnu11'. Stop.

Syntastic C make checker not reporting errors

I'm writing C code and was initially using the gcc checker. Errors were reported in the C file. Lots of errors that didn't matter were being reported due to, for instance, no include directory switches on the gcc command line in the checker. Because we're using icc and it feels unwieldy to setup all of the parameters that are already setup in our makefile, I decided to switch over to using the make checker.
Upon switching to the make checker, I did not get any results. Looking at the makeprg command in make.vim, it is make -sk. I realized that our makefile was not setup to do syntax checking, so I created a new target called syntax_check that added the -fsyntax-only and -c flags. I then changed the make.vim makeprg command to make -sk clean syntax-check so that the appropriate target is run.
When I save the file I watched top in another window and saw that the build is occuring. However, I'm still getting no errors. By this, I mean I don't see the green sidebar indicating lines that did not have errors. Running :Errors does not bring up the location list.
Any ideas? And is my understanding of how to look at the generated errors in syntastic wrong (which it may very well be)?
As a side note for the question here, I've also got this question in on the Syntastic github page here.
It turns out that the errorformat was wrong for handling icc. This, of course, makes total sense.
The errorformat for icc that I've got so far is:
let errorformat = '%W%f(%l): %tarning #%n: %m,%E%f(%l): %trror: %m'
I will add more to this as I find errors that aren't covered by this format or find that I need different formatting.

Hard wrap string literals at print margin in Eclipse C/C++

C/C++ Eclipse can automatically format and wrap just about any kind of code and behaviour is very configurable, except for string literals. Here is a made up example where debug output message happens to be longer than what can fit within a printable area:
if (some_kind_of_action() == TOUGH_LUCK) {
system_debug_print("Task name error: some_kind_of_action() failed due to your sloppy design.");
}
Using 79 character print margin the desirable result could be:
if (some_kind_of_action() == TOUGH_LUCK) {
system_debug_print("Task name error: some_kind_of_action() failed due to yo"
"ur sloppy design.");
}
You can do this manually by typing your string literal, then placing cursor at the desirable wrap point and pressing Enter key. Eclipse will automatically add necessary quotation marks. This is all nice, until something in your code changes and you have to manually redo the wrapping. I don't see why wrapping at print margin can't be done fully automatically like any other piece of code.
Is there any way to automate hard wrapping of string literals at print margin in Eclipse for C/C++?
Eclipse does not support this feature in any of its editors (even though it was requested nine years ago). However you may be able to avoid breaking your lines manually by using the following plugin for enabling soft wrap.
http://ahtik.com/blog/projects/eclipse-word-wrap/

How to break words into syllables in LaTeX correctly

I am writing my MSc with LaTeX and I have the problem that sometimes my words are divided in a wrong way.
My language is spanish and I'm using babel package.
How could I solve it?
For example: propuestos appears prop-uestos (uestos in next line). It should be pro-puestos.
Thanks!!
If you only have a small number of hyphenation errors to correct, you can use \hyphenation to fix them. For instance: \hyphenation{pro-puestos}. This command goes after \documentclass and before \begin{document}.
You can put more than one dash in, if you want to give TeX more line-breaking options: \hyphenation{tele-mun-dos}. You can list many words inside the braces; put spaces between them.
If more than a handful of words are wrong, though, TeX is probably using hyphenation patterns for the wrong language -- and if "propuestos" were an English word, it would be hyphenated after "prop", so that's another point in favor of that theory. Do you get a message like this when you run LaTeX?
Package babel Warning: No hyphenation patterns were loaded for
(babel) the language `Spanish'
(babel) I will use the patterns loaded for \language=0 instead.
If so you need to reconfigure your TeX installation with Spanish hyphenation turned on. There should be instructions for that in the manuals that came with the installation. Unfortunately, this is one of the places where TeX's age shows through -- you can't just load a package with the proper hyphenation rules (or Babel would do that); you have to do it when compiling the "base format" with INITEX, which is a maintenance operation. Modern TeX installations have nice utilities for that but they're all different and I don't know which one you're using.

nsinstall: Bad file number error on Vista

I'm attempting to build Firefox on my Windows Vista Ultimate machine. I keep getting the following error:
nsinstall: Bad file number
I've read that this error is caused because of UAC in Vista. Here are the two articles that lead me to this conclusion. https://wiki.mozilla.org/Penelope_Developer_Page#Windows_Vista and http://www.kevinbrosnan.net/mozilla-build-error-nsinstall-bad-file-number
Using the standard "Run as Administrator", I've attempted to redo my build but I get the exact same error. I also started a normal command prompt as admin and then went to the batch file in mozilla-build (start-msvc8.bat) and ran it. Still, same error at the same point.
Any other insights on how I might either get around this error or perhaps something else is causing the error?
Note: I also posted something here in the hopes to get topic-specific help but I've not heard a peep... After I posted that I found the info on nsinstall. Anyway, I prefer SO so I thought I'd try here...
Update: I've attempted to completly disable UAC to correct the problem as is suggested by cnemelkasr. I've received the exact same error. This new knowledge is making me think that a file or folder is missing... Does anyone who has experience with NSInstall know what the given error -- Bad file number -- might mean? I figure it might be referring to a file handle...
If it really is a UAC error, you can try turning off UAC altogether. I've had to do this for several packages. There are numerous places on the web to get the instructions for doing that.
http://www.petri.co.il/disable_uac_in_windows_vista.htm is one of them.
I found the answer to my question. I'm posting the answer here to share the answer with others and to close this question.
After disabling the UAC, it was suggested that the directory depth was interfering with NSInstall. I moved the folder from c:/Users/Frank/Documents/hg-repos/firefox-src-hgRepo/mozilla-fv-expirement/ to C:/mozilla-fv-expirement/. Cleaned all previous build attempts and finally redid my build (with UAC off) and I received a working debug binary.
The suggestion was posted at: mozilla.dev.builds
The "Bad file number" message in the cases I have seen, is caused by too many arguments passed to execvp (command, argv) (or similar) function. But only from some programs. An old bash, sh or a Borland/Watcom program in your PATH is an likely candidate.
So when you shorten the name of the build directory, the total size of the command line (that eventually gets passed to CreateProcess()) gets shorter. I don't think UAC has anything to do with this since I've seen this on Win-XP too. But it's a bit strange Mozilla would not use relative paths while building. I guess it uses some directory prefix value in it's makefiles (I've never tried building it).
If you look at the documentation for _execvp():
http://msdn.microsoft.com/en-us/library/3xw6zy53.aspx
E2BIG is one of the possible errno values:
The space required for the arguments and environment settings exceeds 32 KB.
Now, here is the strange part.
Fact 1:
On Visual-C/MingW (any version), strerror(EBADF) doesn't return "Bad file number" .
(it return "Bad file descriptor").
Fact 2:
On Borland's CBuilder 5.6 and Watcom 1.9 (these do not use the MSVC runtime), strerror(EBADF) does indeed return "Bad file number".
Theory:
Is possible that Borland, Watcom (and other CRTs too?) mixes up the meaning of E2BIG and EBADF. Did that make any sense? Someone please correct me if you have a better theory.
I'm a bit confused myself...
Conclusion: Either shorten the size of your environment (easiest) or shorten the command-line (not always easy).
--gv

Resources