Is there any stabdard limitation on size of a code line in C code?
I am interesting in UNIX limitation, particulary on SUN.
Thanks!
Why are you interested? I've never come across it as a practical limitation, and remember that macros all expand to a single line, so some of them will get pretty huge.
I think the C standard specifies a minimum limitation (i.e. that all valid C compilers must accept any line that's not longer than 'X' characters), but I'm not sure what it is. In gcc, there may well be no limit besides what memory it can get from the OS.
What problem are you encountering?
I have a source where some weird condition unstably produces the Segmentation Violation.
The error could disappeared or be moved into different place by adding/removing some line of code (some printf() and additional declaration/definitions.)
By 'dbx�, I see how some variable changed unexpectedly into impossible values.
I see the resulted change when the variable is used, but I can't catch when it is happening (the variable change itself!)
It still could be a logical error in code, but working on that problem already couple weeks (before last changes it works fine when I have removed all debug-statements) I start to think about some extreme situation, related to system (maybe our, maybe the standard one.)
I have reviewed today the code with expanded all macros (thanks to JohnGraham for advise how to do that!) and I see some line after that reach 4096 characters long and I am not sure by now if the line is braked in code or it is done by the editor (I use UltraEdit )
Just realized, that it is right - the lines are braked by the editor and actually, in code they are longer: the one I have reviewed now is 4096+1537 = 5633.
There are some code lines, consist of couple of 4096-chars lines.
Therefore, I've been thinking if a long code line in some situations comes across the processing memory, having the debug option is on...
(... Writing, I've thing that the memory for code and the processing memory used in different time... and debugging information does not include the '-E'-code lines, but just references to the original source file..., but ... not completely sure if the so long lines of code is not a reson of that error ...)
Therefore, I've asked this question trying to review any possibility for that error...
If you would have some idea or advise what else I could do to catch the error, I will appreciate to hear it very much!
Code lines don't even exist after the program is compiled, so it causing crashes during debugging doesn't make much sense. If you're exceeding some limit, the compiler should warn you.
What you're describing sounds more like a buffer overflow. Writing past the end of an array on the stack can mangle other local variables, causing behavior like you describe. Moving around lines of code may change what gets mangled or at least when, changing the behavior.
Yea, it sounds completely right!.. you take-off from me one more chance to find a problem 
- just kidding..
Appreciate you oppinion!
---------- Post updated at 12:32 PM ---------- Previous update was at 11:46 AM ----------
It is what I thinkling about from first time that problem appeared - writing over the line size or to some undeclared array's element, but, revuewing over and over again the processing flow could not catch anything like that!
You may have to trace it in a debugger with memory watch and see when it changes. Or an analyzer like valgrind.
Can u Post ur code if possible ?
I can put it here, but you will not read it, for sure: that is a program with more then 3200 lines of code that use couple system utilities (as a dynamic library) and my 'debugging' tools, that makes some primitive statements extended to kilobytes by preprocessor.
Also, the code is running the perl-script to indexing a huge data file and works with that produced index-files and data-extraction file.
Do you think it is any way to present it here and expect anybody would get understanding of that processing, even spend up to one hour? (sure it is over any logical limit)
And I am not able to separate any particular part of program do display it here as, on first, I have no idea where the problem exist and, on second, the complicity of processing makes it very unlikely possible.
---------- Post updated at 10:53 AM ---------- Previous update was at 10:17 AM ----------
Regarding the 'trace' - I am using 'dbx' (I believe we do not have here other debuger (we are on SUN Solaris (studio is not available)))
I did try to set the 'check', 'change' and 'cond', but not able to get it work:
(/opt/SUNWspro/WS6U2/bin/sparcv9/dbx) stop cond (cnr_totl > 3)
dbx: events requiring automatic single-stepping are unavailable for MT programs
(/opt/SUNWspro/WS6U2/bin/sparcv9/dbx) stop change cnr_totl
dbx: events requiring automatic single-stepping are unavailable for MT programs
I am not sure if I use it incorrect or it does not works in our system (other developers or did not try that or was not able to get it work here.)
About the MT - from my side the program is not multy-threaded, but maybe something done by library?!
Getting the 'threads' by 'dbx' it shows only one thread. I do not understand why 'dbx' complains like that!
But I was able to set 'check -all'.
It is pointed me on some places with warnings, but it is not obvious and the processing comes through those places without any problem and, finally stops on Segmentation signal.
I did not try to use 'trace', but now, on short try it shows the same:
(/opt/SUNWspro/WS6U2/bin/sparcv9/dbx) trace cnr_totl
dbx: events requiring automatic single-stepping are unavailable for MT programs
The 'valgrind' is a new word for me!
I appreciate you mentioned it. I will check it!
But, it is not available on our system, and, as you can guess, I have no way to install it here, unfortunately