Does C programming stdin standard input stream have a size limit of 512 characters and can it be increased?

There is no limit to an input stream. There is; however, a limit to the size of the IO buffer, which can be drained quicker than it can be filled. Are you sure this isn't just an IO buffering/timing issue? Maybe you are draining the input buffer quicker than the scanner can feed it? Maybe you need to perform a retry or implement some handshaking mechanism?

When you ask where am I storing the characters....I'm doing simular to what you listed in your comment.
The below statements are what I'm using to retrieve from stdin:
int InputChar = ' ';
fflush(stdin);
InputChar = getch();
After I scan in a 2D barcode that is 954 length in characters the program terminates without ever returning to the next statement after the getch().
I get the error:
  error code: 114, pc=0, call=1, seg=0  Attempt to access item beyond bounds of memory (Signal 11).
It appears this occurs when I attempt to scan 2D barcodes that are over about 500 characters which is why my thinking is there may be a 512 maximum length on what stdin can handle at one time.
If stdin is associated with the pipe size of the operating system some googling on the internet returned a possible 512 maximum characters that a pipe could handle.

thanks,
etjuseraskq

This article looks like it discusses issues of IO starvation.
http://www.pixelbeat.org/programming/stdio_buffering/

Regarding the response about the IO buffer being the problem.....I am using the getch() command to retrieve data from stdin and this command does not buffer the data but returns it immediately after the user presses each key.
int InputChar = ' ';
InputChar = getch();

The problem is occuring at scan time before control ever returns back from the getch().
Using a symbol hand held RF device (MC909x).

thanks,
etjuseraskq

>> InputChar = getch();

Yes, but what do you do with InputChar after this line ?

So if I follow you correctly you are saying the possiblity exists that stdin could be empty when a getch command is performed? I am not currently checking the response for ERR after performing the
InputChar = getch(): The getch is contained within a while(1) loop and we breack out whenever the user hits PF3(exit) or someother special key. The loop checks the keypress returned against all PF keys,backspace, etc and takes an appropiate action. Not sure if I follow your reasoning as to why the stdin could be empty after scanning over 500+ characters as oppose to under 500 characters where there is no problem so don't know how the draining of the stdin is done. I currently do a fflush(stdin) before every getch within the While loop.
This logic has been in place and worked successfully at our company for 1D or linear barcodes so not sure if I want to use a different stdin retrieval command at this point since the problem appears to be related to only 2D barcode data over 500+ characters.
I'll try doing a test and checking for ERR during the getch call. Do not believe we are using nodelay mode since we don't want to force the user to press a key within any time limits so since we are not using nodelay...not sure if ERR is returned if stdin is empty as you stated.
Have not tried running the C program with gdb debugger since I'm fairly new to C and would have to find out how to get to it for the backtrace. The error message I stated in my question regarding going beyond bounds of memory....does that indicate anything to you?

thanks,
etjuseraskq

>> does that indicate anything to you?

That's why I would like to see what you actually do with the read characters.

In response to the question of what is done after the InputChar = getch() command.
The following code uses the Switch statement to examine the content of InputChar and perform the required action. There are cases for Enter, Up key, Down key, tab, backspace, etc.
If no PF key or other special keypress was done we take the character datra and put it into an array.
This array data is then passed back to the calling C program whick in turn call a cobol program based on the current form id that is being processed. When I have the problem I'm never getting passed the getch after the 2D data is scanned from the RF device...the program either hangs or terminates.

thanks,
etjuseraskq

>> So if I follow you correctly you are saying the possiblity exists that stdin could be empty when a getch command is performed?
Yes it is possible, reads from streams can fail if the stream buffer is empty. Most of the C IO functions (all in fact as far as I recall) block if the buffer is empty but getch() may not.

>> reasoning as to why the stdin could be empty after scanning over 500+ characters as oppose to under 500 characters where there is no problem
Purely a timing issue (race condition) if you read quicker than the buffer fills you may eventually run out of data before scanner has finished sending it because it cannot send as quick as you read. I'm not saying thi is the problem, just suggesting it might be so you need to ensure you code to protect against this.

>> Have not tried running the C program with gdb debugger since I'm fairly new to C and would have to find out how to get to it for the backtrace.
This is likely to prove useful if we can't nail it down with conjecture :)

>> does that indicate anything to you?
Nothing specific to reading from a stream, no

>> If no PF key or other special keypress was done we take the character datra and put it into an array.

And are you sure that array is big enough to hold all data you put in it ?

>> >> If no PF key or other special keypress was done we take the character datra and put it into an array.
>>
>> And are you sure that array is big enough to hold all data you put in it ?

Or in other words ... Is it by any chance 500 characters (or 512 maybe) wide, while you're trying to put in 900 ?

The array I'm reading into is defined with a size of 3000 characters so over 900 should not be a problem.

thanks,
etjuseraskq

What happens if you put a printf inside the loop, and show each character as it's read ? At what point does it start showing the wrong value ?

Previously when I put in a printf within the loop it never makes it to the printf statement before the program hangs or terminates. I then tried putting the printf right after the getch statement and it never gets to the printf before the problem. This is why I originally believed the problem is happening at scan time after the console is paused from the getch. When the problem occurs it never makes it passed the getch statement.
Regarding checking for ERR...since I am not using the nodelay option I don't believe checking for ERR will work....after looking thru the internet it looks like the ERR check is done in conjuction with the nodelay option which I don't want to use for the program.
I am trying the ioctl command to check for input waiting before performing the getch. I was already doing this but only after it is determined in the program the data length read in is equal to or greater than the defined field length of the field defined on the form.
So there is currently the getch that normally retrieves data from stdin and then as part of the 2D barcode logic I added a special routine that contains a getch to get the rest of the data when a 2D barcode is scanned....I know when this occurs because i'm chekcing field length of characters retrieved from the 1st getch against what the defined field length is for the field currently being scanned on our RF form. This worked for getting the rest of the data when a 2D is scanned but I had to add the ioctl statement so the console (RF device) would not pause but only do the getch for 2D when there was input waiting.
Ex. int KeyIO;
     ioctl(0, FIONREAD, &KeyIO);
    if (KeyIO)
       then do a getch.....

i'm going to add this code prior to the original getch in the while loop and see what happens.

thanks,
etjuseraskq

I think the explanation can be found in the fact that getch is not a standard function, and there are some peculiarities with the non-line-based input on your system.

What if you make it line-based ? Ie. make use of standard functions like getc ?

>> I think the explanation can be found in the fact that getch is not a standard function
Agreed, I eluded to this much earlier. The getch() function has no guaranteed way to behave as it is platform dependent

It is true that getch is not the standard but the current C program I've been modifying has used it without any issues over the last 10 years. At this point to change how it is doing the retrieval would change the way it has been working thus may introduce issues outside of the 2D modifications. What I don't want to do at this point is change the way the existing 1D and linear barcode data has been read in since that has worked o.k.
I'll try testing some different things or maybe system calls to see if there is a work around for now.

thanks,
etjuseraskq

Hi etjuseraskq,

Interesting. :)

My suggestions:

1. Get 'getch' out of yor face. Replace it with standard C 'fread ( &InputChar, 1, 1, stdin )'.

I agree with the others, getch is a potential killer. That should also keep I08 and ER happy. ;-)

2. Start investigating upstream of the data.

What drivers/software is being used to receive the scanner data and pipe it into your stdin? Could any of them be old and need updating?

It sounds to me like something further up the line cant handle more than 512 characters in a single bite. Get the latest drivers or libraries.

Less likely, but possible, could be your use of ioctl. By doing this you will call getch a specific length of time after your ioctl call returns success. This may produce a race condition.

As an afterthought, have you tried setvbuf (if it is available) to increase the buffer size of stdin? 2000 would be a convenient size. :)

Paul

Yes, I can see now that the getch is not a standard C stdin retrieval. However, at this point in our project we cannot afford to change the retrieval process for 2D without impacting the current 1D barcode retreivals that have used it successfully over the years. Maybe we will need a phase 2 of this project where we can try the other stdin retrieval commands.
The RF device we use is a MC909x symbol hand held device. It runs Windows Mobile and the Telnet client on it. The device is able to connect into our system where the C programs reside and run them from the Linux side. I will talk more with the vendor to determine if there are any drivers or settings that could be involved in this issue. The ioctl command is executed further down in the code after the getch and I'm sure it never even makes it to the firs ioctl before the program hangs or terminates. The scenario is the program is never returned to from the getch when we encounter this problem so there should not be any other commands that are affecting it.
Yes, I have looked at the setvbuf and will attempt to try some things with it to see if there is a difference.
Thanks for your input,
etjuseraskq

etjuseraskq,

>>... used it successfully over the years. Maybe we will need a phase 2 of this project where we can try the other stdin retrieval commands.

Perhaps the others can confirm but I believe

InputChar = getch();

should be EXACTLY the same as

fread ( &InputChar, 1, 1, stdin );

The only difference will be that if 'fread ( &InputChar, 1, 1, stdin )' doesnt work you can blame someone else. :-)

>> ... I will talk more with the vendor to determine if there are any drivers or settings that could be involved in this issue.

If you have had this system for years then it is VERY likely that the tools cannot handle 2000 byte barcodes. Good idea.

>>The ioctl command is executed further down in the code after the getch ...
I thought this was an unlikely one.

>>The scenario is the program is never returned to from the getch when we encounter this problem...
Which implies that the roblem is upstream. What appens if you DONT call getch and scan a long barcode?

>>... setvbuf and will attempt to try some things with it to see if there is a difference.
I hope it helps. It would be the best way to avoid upstream issues.

>>Thanks for your input,
Happy to help. :)

Paul

>> The code that I08 suggested further up:
>> was a very good suggestion.

I'd like to think so too ;)

Have you tried it, etjuseraskq ? Just to see what the result is ?