Quite right, I believe I said at one point that it boils down to style and however protective you wish to write your code. But I do think the OP was exploring the language. Yep, they're probably in overload on the subject, but at least they have some excellent points. I personally would use a "per character" parser, and therefore only have acceptable exits designed to be the correct answers, or an escape condition; such as SIGINT.

I do understand that the definition of your input buffer is defined in the kernel build. I didn't dig deeply into Spect73's posting, except to compile and run that code and change the definition from 1024 to other values to assure myself that the result of 1024 wasn't conveniently due to that #define. Still, isn't 1024 potentially too small? For instance that affects things when you run make and gcc and if you have a very lengthy path; along with a number of arguments to your line, you may hit 1024. I have an embedded system where the serial buffer max values are 4096, because I was using 65535 as my PIPE size and then realized by code inspection that receives from serial USB could never exceed 4096. It makes me curious to look at the kernel and see the prevailing definition for the stdin size. Where I ended was limits.h:

Not sure if that means that the max would then be 4096, PIPE_BUF.

SIGINT would have to be handled completely differently, since it is a signal. It is way outside of the topic of this thread and in most simple applications one doesn't have to worry about it at all.

It isn't. What the C library uses is dependent on the library, and standard does not impose any limits.

I'm sorry, but I have no idea what you're talking about. Too small for what? To hold a line? It might, since there are no limits to the length of a single line read from standard input.

PIPE_BUF is what it says in the comment – maximum number of bytes you can write to a pipe in an atomic way. I.e. such that the reader will be able to receive that data using a single read call. It has nothing to do with the length of a line on standard input.

Yes, I meant too small for a line. Years ago I think the command line would accept say 256 characters and people would create makes based on a local directory. Eventually you'd run into a problem, for instance if the original author used a short path like /home/mylogin and that was it, things worked fine. But if you copied and used a root path like /home/temporary-login/releases-of-that-demo/january-17-2014-version/first-pass and when the Make ran it would include that path in most of the gcc lines, there would be problems. One had to alter their command line capabilities to allow for more than what it originally allowed or not use so extensive of a home directory size. Eventually that got fixed either by having a much larger number or making it unlimited by some technique other than a fixed array. I do think that 1024 may be too short for some of the Make lines which may occur. I'm not up to date on how the command parser works and therefore when you say there are no limits to the length of a single line read; then maybe there is no longer any risk of some shell command offered by a Make process which could ever exceed what a command shell could take.

Sorry for any confusion due to my lack of clarity or knowledge on some of that.

1 members found this post helpful.