First of all, sorry if someone already asked about this question.
I did search about this first, but couldn't find one.
I used to see some people doing something like this:
if ( // a certain conditions here ) {
error("ERROR: not bla bla bla")
}
what is error(....)? What is the difference with printf()?
Why they aren't using printf("ERROR: not bla bla bla") instead?
Thank you.
As i know, c language has no function name "error". I think that is a function or a macro is coded or defined by user.
To handle error in c, you can read this link. It has some different points with printf function.
http://www.tutorialspoint.com/cprogramming/c_error_handling.htm
Take a look of standard streams, which includes stdin (for input), stdout for output, and stderr for error messages. Usually stdout and stderr are just terminal output, so there are no differences. However, the output can be redirected to a text file while all error messages are still available output.
Also have look at this question perror vs frintf(stderr..), which gives you a better idea as to why perror should be used.
Related
Is there an alternative to the err() family of functions found in <err.h> that displays the program name, a semicolon, a space, and the error message... without exiting the program?
Pseudocode
I want
print "<program name>: <error message>"
and not
print "<program name>: <error message>"
exit program
return <status>
EDIT: I cannot use argv[0] (as the program name) to write out the message myself, as I am writing a library
program_invocation_name works just as well for getting the name of the program, as Erdal Küçük mentioned. From this, we can print the full error message, program name included.
The variable is part of glibc and can be retrieved using:
extern char *program_invocation_name;
Because it is not a part of the C standard library, programs using this variable should not be expected to be portable.
See man error.
error is the same as err but will return if status == 0, exit otherwise.
CONFORMING TO
These functions and variables are GNU extensions, and should not be used in programs intended to be portable.
The warn/warnx functions from err.h will do the same thing as err, but will return.
For example:
warnx("message here");
puts("I'm still running!");
Output:
a.out: message here
I'm still running!
i write a code for tcp connection in c language, and in some place i added two perrors:
perror("FAIL1: ...");
perror("FAIL2: ...");
and the output is:
FAIL1: ..: Success FAIL2: ..: Invalid argument
Just want to understand - what does it mean the "Success"? TNX!
Take a look at the man page below.
http://man7.org/linux/man-pages/man3/perror.3.html
The first two paragraphs have the content you need.
Essentially the string representation of "errno" a global variable is printed out along with your arguments. If you have no errors (errono = 0). This is causing your program to print "SUCCESS".
I was fiddling with the code for an ANSI C parser given here http://www.lysator.liu.se/c/ANSI-C-grammar-y.html and here http://www.lysator.liu.se/c/ANSI-C-grammar-l.html.
Unfortunately, the code isn't working - I modified it a bit to make it print a message upon successfully parsing an input program, but the message is never printed, even if the input program is in C with no syntax errors. I'd be glad if anyone can help me out here.
EDIT:
Just to clarify - I was only testing a publicly available lex + yacc program on a simple input C program that prints "Hello World!". The links are present above. Please just open them to see the code.
It looks like the Yacc file just checks that your input program is correct (by printing an error if not), but it does nothing else.
Add some semantic actions (some code to execute when a rule has been matched), between curly braces just after the rules. See http://dinosaur.compilertools.net/bison/bison_4.html#SEC11
You can start by printing something when a rule is matched, but if you want to build a C compiler, you'll have to build an AST.
EDIT
You also need to add a main method which calls the parser. Just add
void main() {
yyparse();
}
at the end of the yacc file.
The parser will read the inputs from stdin. So, if you're using Linux or MacOSX, you can type
./parser < helloworld.c
or for Windows
parser < helloworld.c
Actually, the parser prints the input file if it is correct.
I have a function that pretty prints a data structure, its function prototype is:
void print_mode(FILE *fp, Mode *mode);
the FILE* allows you to redirect the output to anywhere you want, e.g. stdout, stderr, a file etc. Mode is the data structure
I am trying to call this function from within gdb and want the output to be directed to the gdb console window, stdout?
I have tried:
(gdb) p print_mode(STDOUT,fragment_mode)
No symbol "STDOUT" in current context.
(gdb) p print_mode(stdout,fragment_mode)
$17 = void
neither of which work
any ideas how i can get the output of the function to display in the gdb console?
should add - I am using gdb within emacs 24.2.1 under linux
STDOUT seems to be macro, which is not know to GDB, as handled prior to compilation by the pre-preprocessor.
Using stdout should do the job.
However the function print_mode() simply does not seem to print out anything.
In terms what's being printed to the console by the program being debugged, GDB's commands printand call should not make a difference.
For details on this you might like to read here: https://sourceware.org/gdb/onlinedocs/gdb/Calling.html
An issue might be that stdout by default is line buffered, so output would not occur before detecting a linefeed and print_mode() perhaps does not send a linefeed (\n).
To test this just use stderr as output file, as the latter isn't buffered:
p print_mode(stderr, fragment_mode)
Oh dear - silly mistake. You're right, stdout does do the job.
I forgot that having upgraded from emacs 23 to 24, the way gdb works has changed in as much as it now opens a separate buffer *input/output of program-name* to which it redirects the output of the program being debugged. In the prior version of emacs it was all displayed in the same, single gdb buffer.
So my second attempt was actually working, I was just looking in the wrong place so didn't see the output
I am running a Ruby gem which relies on a C extension (not a call to system).
The C code makes several calls to printf.
I want to silence the output of these calls.
Changing Ruby's STDOUT (example) or STDERR does not prevent the text from being output.
Is it possible to do this without modifying the C code? If so, how?
Someone originally commented on my post suggesting to use IO.reopen. This worked for me. The person has unfortunately since deleted his/her comment, so I'm posting the more detailed function I used in the end:
def silence_stdout(log = '/dev/null')
old = $stdout.dup
$stdout.reopen(File.new(log, 'w'))
yield
$stdout = old
end
Usage:
silence_stdout { foo } # Won't be displayed, won't be logged.
silence_stdout('log.txt') { bar } # Won't be displayed, logged in log.txt.
It is possible that Ruby is printing to stderr instead of stdout, which is why changing Ruby's stdout doesn't fix your problem.
(Both stderr and stdout typically go to the console.)
Try redirecting stderr. As I recall it'd be: myprogram 2> /dev/null
If you have access to the C source code:
#define printf(...)
This macro form is a C99 variadic macro.