The GNU C manual says that:
Being able to use the same stream for wide and normal operations comes
with a restriction: a stream can be used either for wide operations or
for normal operations.
[...]
It is important to never mix the use of wide and not wide
operations on a stream. There are no diagnostics issued. The
application behavior will simply be strange or the application will
simply crash. The fwide function can help avoiding this.
I have tried on vs2012, a printf followed immediately by a wprintf, and the simple program works properly.
Then my question is, what does the manual mean? When and why we should use fwide function?
The manual says, more fully:
Being able to use the same stream for wide and normal operations comes
with a restriction: a stream can be used either for wide operations or
for normal operations. Once it is decided there is no way back. Only a
call to freopen or freopen64 can reset the orientation. The
orientation can be decided in three ways:
If any of the normal character functions is used (this includes the fread and fwrite functions) the stream is marked as not wide oriented.
If any of the wide character functions is used the stream is marked as wide oriented.
The fwide function can be used to set the orientation either way.
It is important to never mix the use of wide and not wide operations
on a stream. There are no diagnostics issued. The application behavior
will simply be strange or the application will simply crash. The fwide
function can help avoiding this.
Note that the Microsoft documentation says their fwide() is "not implemented" (it's a no-op) and it "does not comply with the standard."
My reading of all this is that programs using glibc must not use both narrow and wide character functions on a single stream without reopening it. Perhaps on Microsoft platforms there is no such restriction; perhaps even other libc implementations are more flexible.
Related
Say input stream (stdin) has "abc" on it. I want to push back, say, 3 '*' chars to stdin to get something like "***abc". I was trying to use ungetc() (I did ungetc('*', stdin)) for this but I realized that it guarantees only 1 character pushback, and then it may fail. Is there any other way I could push 3 (or any known N) amount of characters back to stdin?
There is no portable way to accomplish this.
However, most implementation of the standard C library will allow multiple pushbacks, within reason. So in practice, it may not be a problem.
If you need an absolute guarantee, you'd need to write your own stdio implementation. That's certainly possible, since there are open source implementations which you could modify. But it's a lot of work. Alternatively, you could use the FreeBSD library, if it is available for your platform, since it does guarantee the possibility of repeated ungetc calls. (As far as I know, the GNU implementation also allows arbitrary ungetc calls. But the documentation doesn't guarantee that.)
Some libraries include non-standard interfaces like GNU's fopencookie, which let you create stdio streams with custom low-level read and write functions. Unfortunately, these do not help with this particular use case, which requires the ability to customise the implementation of stdio buffers. So that's a dead-end; I only mention it because it might seem plausible at first glance.
We have a daemon that contains a lot of print messages. Since we are working on an embedded device with a weak CPU and other constraint hardware, we want to minimize any kinds of costs (IO, CPU, etc..) of printf messages in our final version. (Users don't have a console)
My teammate and I have a disagreement. He thinks we can just redirect everything to /dev/null. It won't cost any IO so affections will be minimal. But I think it will still cost CPU and we better define a macro for printf so we can rewrite "printf" (maybe just return).
So I need some opinions about who is right. Will Linux be smart enough to optimize printf? I really doubt it.
Pretty much.
When you redirect the stdout of the program to /dev/null, any call to printf(3) will still evaluate all the arguments, and the string formatting process will still take place before calling write(2), which writes the full formatted string to the standard output of the process. It's at the kernel level that the data isn't written to disk, but discarded by the handler associated with the special device /dev/null.
So at the very best, you won't bypass or evade the overhead of evaluating the arguments and passing them to printf, the string formatting job behind printf, and at least one system call to actually write the data, just by redirecting stdout to /dev/null. Well, that's a true difference on Linux. The implementation just returns the number of bytes you wanted to write (specified by the 3rd argument of your call to write(2)) and ignores everything else (see this answer). Depending on the amount of data you're writing, and the speed of the target device (disk or terminal), the difference in performance may vary a lot. On embedded systems, generally speaking, cutting off the disk write by redirecting to /dev/null can save quite some system resources for a non-trivial amount of written data.
Although in theory, the program could detect /dev/null and perform some optimizations within the restrictions of standards they comply to (ISO C and POSIX), based on general understanding of common implementations, they practically don't (i.e. I am unaware of any Unix or Linux system doing so).
The POSIX standard mandates writing to the standard output for any call to printf(3), so it's not standard-conforming to suppress the call to write(2) depending on the associated file descriptors. For more details about POSIX requirements, you can read Damon's answer. Oh, and a quick note: All Linux distros are practically POSIX-compliant, despite not being certified to be so.
Be aware that if you replace printf completely, some side effects may go wrong, for example printf("%d%n", a++, &b). If you really need to suppress the output depending on the program execution environment, consider setting a global flag and wrap up printf to check the flag before printing — it isn't going to slow down the program to an extent where the performance loss is visible, as a single condition check is much faster than calling printf and doing all the string formatting.
The printf function will write to stdout. It is not conforming to optimize for /dev/null.
Therefore, you will have the overhead of parsing the format string and evaluating any necessary arguments, and you will have at least one syscall, plus you will copy a buffer to kernel address space (which, compared to the cost of the syscall is neglegible).
This answer is based on the specific documentation of POSIX.
System Interfaces
dprintf, fprintf, printf, snprintf, sprintf - print formatted output
The fprintf() function shall place output on the named output stream. The printf() function shall place output on the standard output stream stdout. The sprintf() function shall place output followed by the null byte, '\0', in consecutive bytes starting at *s; it is the user's responsibility to ensure that enough space is available.
Base Definitions
shall
For an implementation that conforms to POSIX.1-2017, describes a feature or behavior that is mandatory. An application can rely on the existence of the feature or behavior.
The printf function writes to stdout. If the file descriptor connected to stdout is redirected to /dev/null then no output will be written anywhere (but it will still be written), but the call to printf itself and the formatting it does will still happen.
Write your own that wraps printf() using the printf() source as a guideline, and returning immediately if a noprint flag is set. The downside of this is when actually printing it will consume more resources because of having to parse the format string twice. But it uses negligible resources when not printing. Can't simply replace printf() because the underlying calls inside printf() can change with a newer version of the stdio library.
void printf2(const char *formatstring, ...);
Generally speaking, an implementation is permitted to perform such optimisations if they do not affect the observable (functional) outputs of the program. In the case of printf(), that would mean that if the program doesn't use the return value, and if there are no %n conversions, then the implementation would be allowed to do nothing.
In practice, I'm not aware of any implementation on Linux that currently (early 2019) performs such an optimisation - the compilers and libraries I'm familiar with will format the output and write the result to the null device, relying on the kernel' to ignore it.
You may want to write a forwarding function of your own if you really need to save the cost of formatting when the output is not used - you'll want to it to return void, and you should check the format string for %n. (You could use snprintf with a NULL and 0 buffer if you need those side-effects, but the savings are unlikely to repay the effort invested).
in C writing 0; does execute and nothing, which is similar to ;.
means you can write a macro like
#if DEBUG
#define devlognix(frmt,...) fprintf(stderr,(frmt).UTF8String,##__VA_ARGS__)
#else
#define nadanix 0
#define devlognix(frmt,...) nadanix
#endif
#define XYZKitLogError(frmt, ...) devlognix(frmt)
where XYZKitLogError would be your Log command.
or even
#define nadanix ;
which will kick out all log calls at compile time and replace with 0; or ; so it gets parsed out.
you will get Unused variable warnings, but it does what you want and this side effect can even be helpful because it tells you about computation that is not needed in your release.
.UTF8String is an Objective-C method converting NSStrings to const char* - you don't need.
Q: I'm trying to update a file in
place, by using fopen mode "r+",
reading a certain string, and writing
back a modified string, but it's not
working.
A: Be sure to call fseek before
you write, both to seek back to the
beginning of the string you're trying
to overwrite, and because an fseek
or fflush is always required between
reading and writing in the read/write
"+" modes.
My question is why fseek or fflush is always required between reading and writing in the read/write "+" modes? Section 5.2 of
Andrew Koenig's
C Traps and Pitfalls (1989) mentioned that it is because of a backward compatibility issue. Can anyone explain in detail?
The library buffers input and output operations. Check out setvbuf() and the _IOFBF, _IOLBF parameters to that function.
fseek() or fflush() require the library to commit buffered operations.
The standard specifies a seek or flush operation (flushing the buffers) as mandatory prior to changing I/O direction to allow the library some shortcuts. Without this restriction, the library would have to check for every I/O operation if the previous operation was the same direction (reading / writing), and trigger a flush by itself if the I/O direction changed. With the restriction as-is, the library may assume the client did the seek / flush before changing I/O direction, and can omit the direction checks.
Because it keeps OS/library code simpler. A file stream may have separate read and write buffers, and extra effort would be required to make sure they are always synchronised. This would cost performance at times when it wasn't needed.
So instead, the programmer needs to do this explicitly when it is needed.
Read Plauger's "The Standard C Library" for some insights into why various features of the (C89) standard library are as they are - and in particular why parts of the standard I/O library are as they are. One reason is that C runs on very diverse systems and with diverse media; devices such as tapes may well need to be handled somewhat differently from the disk drive you're accustomed to thinking of. Also, on Unix, consider your 'tty' device - it connects a keyboard and a mouse to a screen - three quite different bits of hardware. Coordinating between those is tricky enough; the rules in the standard make it easier.
Note that the standard mandates this. This is from the C11 standard, ISO/IEC 9899:2011, but the wording was similar in prior editions:
§7.21.5.3 The fopen function
¶7 When a file is opened with update mode ('+' as the second or third character in the
above list of mode argument values), both input and output may be performed on the
associated stream. However, output shall not be directly followed by input without an
intervening call to the fflush function or to a file positioning function (fseek,
fsetpos, or rewind), and input shall not be directly followed by output without an
intervening call to a file positioning function, unless the input operation encounters end-of-file. Opening (or creating) a text file with update mode may instead open (or create) a
binary stream in some implementations.
I am looking for various ways of reading/writing data from stdin/stdout. Currently I know about scanf/printf, getchar/putchar and gets/puts. Are there any other ways of doing this? Also I am interesting in knowing that which one is most efficient in terms of Memory and Space.
Thanks in Advance
fgets()
fputs()
read()
write()
And others, details can be found here: http://www.cplusplus.com/reference/clibrary/cstdio/
As per your time question take a look at this: http://en.wikipedia.org/wiki/I/O_bound
Stdio is designed to be fairly efficient no matter which way you prefer to read data. If you need to do character-by-character reads and writes, they usually expand to macros which just access the buffer except when it's full/empty. For line-by-line text io, use puts/fputs and fgets. (But NEVER use gets because there's no way to control how many bytes it will read!) The printf family (e.g. fprintf) is of course extremely useful for text because it allows you to skip constructing a temporary buffer in memory before writing (and thus lets you avoid thinking about all the memory allocation, overflow, etc. issues). fscanf tends to be much less useful, but mostly because it's difficult to use. If you study the documentation for fscanf well and learn how to use %[, %n, and the numeric specifiers, it can be very powerful!
For large blocks of text (e.g. loading a whole file into memory) or binary data, you can also use the fread and fwrite functions. You should always pass 1 for the size argument and the number of bytes to read/write for the count argument; otherwise it's impossible to tell from the return value how much was successfully read or written.
If you're on a reasonably POSIX-like system (pretty much anything) you can also use the lower-level io functions open, read, write, etc. These are NOT part of the C standard but part of POSIX, and non-POSIX systems usually provide the same functions but possibly with slightly-different behavior (for example, file descriptors may not be numbered sequentially 0,1,2,... like POSIX would require).
If you're looking for immediate-mode type stuff don't forget about Curses (more applicable on the *NIX side but also available on Windows)
Q: I'm trying to update a file in
place, by using fopen mode "r+",
reading a certain string, and writing
back a modified string, but it's not
working.
A: Be sure to call fseek before
you write, both to seek back to the
beginning of the string you're trying
to overwrite, and because an fseek
or fflush is always required between
reading and writing in the read/write
"+" modes.
My question is why fseek or fflush is always required between reading and writing in the read/write "+" modes? Section 5.2 of
Andrew Koenig's
C Traps and Pitfalls (1989) mentioned that it is because of a backward compatibility issue. Can anyone explain in detail?
The library buffers input and output operations. Check out setvbuf() and the _IOFBF, _IOLBF parameters to that function.
fseek() or fflush() require the library to commit buffered operations.
The standard specifies a seek or flush operation (flushing the buffers) as mandatory prior to changing I/O direction to allow the library some shortcuts. Without this restriction, the library would have to check for every I/O operation if the previous operation was the same direction (reading / writing), and trigger a flush by itself if the I/O direction changed. With the restriction as-is, the library may assume the client did the seek / flush before changing I/O direction, and can omit the direction checks.
Because it keeps OS/library code simpler. A file stream may have separate read and write buffers, and extra effort would be required to make sure they are always synchronised. This would cost performance at times when it wasn't needed.
So instead, the programmer needs to do this explicitly when it is needed.
Read Plauger's "The Standard C Library" for some insights into why various features of the (C89) standard library are as they are - and in particular why parts of the standard I/O library are as they are. One reason is that C runs on very diverse systems and with diverse media; devices such as tapes may well need to be handled somewhat differently from the disk drive you're accustomed to thinking of. Also, on Unix, consider your 'tty' device - it connects a keyboard and a mouse to a screen - three quite different bits of hardware. Coordinating between those is tricky enough; the rules in the standard make it easier.
Note that the standard mandates this. This is from the C11 standard, ISO/IEC 9899:2011, but the wording was similar in prior editions:
§7.21.5.3 The fopen function
¶7 When a file is opened with update mode ('+' as the second or third character in the
above list of mode argument values), both input and output may be performed on the
associated stream. However, output shall not be directly followed by input without an
intervening call to the fflush function or to a file positioning function (fseek,
fsetpos, or rewind), and input shall not be directly followed by output without an
intervening call to a file positioning function, unless the input operation encounters end-of-file. Opening (or creating) a text file with update mode may instead open (or create) a
binary stream in some implementations.