Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
Can someone explain me this format in C language?
fscanf(file_name,"%20[^\n]%*20c%ld%*c%d%*16c",name,&idE,&cod);
I don't understand what %20[^\n] means.
As noted in the comments, the %20[^\n]scan set conversion specification means that the code will read not more than 20 characters that aren't a newline, null terminating the string (using the 21st byte if necessary). The scan set conversion is complete at the ] — there are special rules when you need to include ] in the scan set. See the POSIX scanf() manual for the full details.
Note that there are various scenarios. First, the scan set won't skip leading white space (and it plus %c and %n are the only three conversion specifications that don't skip white space).
Suppose that the next character is a newline: the conversion fails because there must be at least one character that matches for it to succeed.
Suppose instead that the next few characters are not newlines, but there is a newline before 20 characters are read. Those characters will be read into the string, which will be null terminated.
Alternatively, suppose that the next few characters are not newlines, but there is a newline (immediately) after the 20th character. There will be 20 characters in the string that's read, plus a null terminator, and the newline will be processed by the next part of the format string. In the question, that's %*20c, which means "read 20 characters, including white space, but do not assign to any variable". If, instead of %*20c, the character was c, then the match of the c would fail; the next character is a newline. You'd know because scanf() would return just 1, not 2 or more.
The other alternative is that there are more than 20 non-newlines to read; 20 of them will be saved into the variable associated with the scan set, and the following characters will be matched (or not) by the subsequent characters or conversion specifications in the format string.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 10 months ago.
Improve this question
So I have a string char *str = someString(); and I want to print the string and retain any formatting that may be present in the string with printf("%s", str); So for instance, if str were equal to "\033[32mPassed!\n\033[0m", I would want it to print Passed! in green followed by a new line. But currently, it prints the string literally.
Is this something printf can do or is it not designed for this? I understand that this could cause issues if the string contained something like %d without actually having a number passed.
Sending ␛[32mPassed!␊␛[0m to the terminal is what causes the desired effect.[1]
You are asking how convert the string "\033[32mPassed!\n\033[0m" into the string ␛[32mPassed!␊␛[0m, just like the C compiler does when provided the C code (C string literal) "\033[32mPassed!\n\033[0m".
printf does not provide a way to convert a C string literal into the string it would produce.
And nothing else in the standard library does either. The functionality of parsing C code is entirely located in the compiler, not in the executable it produces.
You will need to write your own parser. At the very least, you will need to do the following:
Remove the leading and trailing quotes.
Replace the four character sequence \033 with character 0x1B.
Replace the two character sequence \n with character 0x0A.
Footnotes
Assuming the terminal understands these ANSI escape sequences.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm currently learning strings in C, and a question arose: why doesn't the C developers make strncpy null terminated automatically?
For example in the implementation of strncpy, why didn't people who make C language add this line:
// dest denotes the destination string
dest[n - 1] = '\0';
in order to make strncpy safer?
strncpy was never intended to be a "safe alternative" to strcpy, though that is the impression a lot of new C programmers get since it does take a "size" parameter. The third argument is for the number of characters to be read from the source buffer, not the maximum capacity of the destination buffer.
There are few use cases today for which strncpy is the best choice for copying data from one buffer to another. If you do require a safe alternative to strcpy, you could use snprintf like so:
snprintf(dest, len_dest, "%s", src);
Its done this way, because you may want to overwrite just the first words of a sentence.
It is null terminated if you don't reach the count. See quote below (https://en.cppreference.com/w/c/string/byte/strncpy)
Copies at most count characters of the character array pointed to by
src (including the terminating null character, but not any of the
characters that follow the null character) to character array pointed
to by dest.
It is only unterminated if you reach count before terminating null character. You can't add terminating null character at the capacity because that would be outside of array bounds.
You may want to look into strlcpy which will do what you want but is not part of the standard library.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
scanf is a function which takes user inputs. But according to the code in the picture the compiler understands 34 as the value for "y", but it is only the neglected input of x, so can anyone explain this?
Scanning for the %2d directive stops when the two digits 12 have been read. That leaves "3" as the next character in the input stream.
Then the space character in the format string says to skip white space characters (spaces, tabs, and so on), if there are any. There are not, so “3” remains the next character in the input stream.
Then the %d specifier causes a decimal integer to be read, so 34 is assigned to y.
If you wish to skip the digits remaining after x is scanned, you can use %*[0-9] to scan and ignore digits until a non-digit is seen., as in %2d%*[0-9] %d %*f %5s.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
I am trying to print the characters from a text file using C in CodeBlock terminal. I use getc and printf. But the terminal shows unwanted characters as well. For example,
when I read,
CAAAAATATAAAAACAGGTTTATGATATAAGGTAAAGTATGGGAGATGGGGACAAAAGT
It shows,
CΘA A A A A T A T A A A A A C A G G T T T A T G A T A T A A G GT A A A G T A T$GhGêG╝A G<AöT G#GñG<G AxC A A A A G T
Can any one please state what can be done to avoid this situation.
Your text file obviously uses a 2byte character encoding. If this is on windows, it's very likely UTF-16.
char in C is a single byte, so a single-byte encoding is assumed. There are many ways to solve this, e.g. you could use iconv. On windows, you can use wchar_t(*) to read the characters of this file (together with functions for wide characters like getwc() and if you need it in an 8byte encoding, windows API functions like WideCharToMultiByte() can help.
wchar_t is a type for "wide" characters, but it's implementation-defined how many bytes a wide character has. On windows, wchar_t has 16 bits and typically holds UTF-16 encoded characters. On many other systems, wchar_t has 32 bits and typically holds UCS-4 encoded characters.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
Consider this thread What is EOF in the C programming language?
The answer was that EOF (Ctrl-D) results in that getchar returns -1
My question is what does Ctrl-J and Ctrl-M represent in c on OSX and why does getchar return 10 for both using the same code as in link above?
What other shortcuts (Ctrl-somthing / Cmd-something) results in that getcharturns a static predefined number?
Ctrl-J is the shortcut for the line feed control character, having the character code 10. Here is a page with other control characters
I as of this time do not know why Ctrl-M (ASCII value 13) returns 10 but assume it is due to it being similar in function to the line feed.
The reason EOF returns -1 is because its value is -1 on most systems.
Some other defined characters:
Ctrl-G: 7
Ctrl-I: 9
...
Ctrl-V: 22
stdin is typically in text mode. Various conversions occur per OS concerning line endings when reading/writing in text mode. Crtl-M is one of them - it is converted to 10. Had IO been in binary mode, no conversion would be expected.
Consoles map various keyboard combinations to various char and actions (like Ctrl-D --> EOF). The various char created certainly include most of the values 0 to 127. As these values are typically mapped to ASCII, the first 32 values (Ctrl-#, CTRL-A, CTRl-B, ... Ctrl-_), they may have no graphical representation
Note: Notice what is returned when getchar() is called again after it returned EOF. Expect it to immediately return EOF again without waiting for any additionally key presses. (Ctrl-D) set a condition, not a char.